Si votre programme crash le système n'en sera jamais informé
On parle de C#, y'a un système d'exception qui peut être intercepté par la VM : et un message d'exception est autrement plus complet, précis et enrichi qu'un simple numéro de retour .
La signature de votre fonction main() est fausse
Dans le cas où le programme généré est un exécutable Windows ou Unix oui, mais le code C# ou Java est censé être indépendant de ces considérations de "bootstrapping" visant à intégrer l'exécutable dans son environnement.
Les appels a des objets COM/COM+ ou autres bibliothèques depuis votre programme deviennent indébuggables (difficile de remonter une erreur jusqu'à sa source quand aucune erreur n'est levée) etc.
Pareil, C# a été conçu pour intégrer et utiliser facilement un composant COM/COM+, et réciproquement : alors tu penses bien que si celà avait posé un problème... Suffit de bien penser le passage d'un monde à l'autre, et de convertir les valeurs de retour d'erreur en exception.
Bref, même si à l'époque de bc1.0 pour DOS ce choix était vraiment discutable, cette argumentation ne tient plus du tout aujourd'hui puisque d'autres systèmes de message d'erreurs (exception) sont utilisées pour communiquer entre les applications.
Evidemment il y a des cas où celà peut être utile, notamment pour s'intégrer dans un environnement Unix, mais reste que ce cas de figure est de plus en plus rare, et il est normal que le langage n'impose plus ce genre de contrainte, tout en laissant le choix au programmeur d'utiliser cette possibilité s'il en a envie.
[^] # Re: On va encore dire que je suis un raleur mais...
Posté par TImaniac (site web personnel) . En réponse au journal Des nouvelles de Gnome. Évalué à 3.
On parle de C#, y'a un système d'exception qui peut être intercepté par la VM : et un message d'exception est autrement plus complet, précis et enrichi qu'un simple numéro de retour .
La signature de votre fonction main() est fausse
Dans le cas où le programme généré est un exécutable Windows ou Unix oui, mais le code C# ou Java est censé être indépendant de ces considérations de "bootstrapping" visant à intégrer l'exécutable dans son environnement.
Les appels a des objets COM/COM+ ou autres bibliothèques depuis votre programme deviennent indébuggables (difficile de remonter une erreur jusqu'à sa source quand aucune erreur n'est levée) etc.
Pareil, C# a été conçu pour intégrer et utiliser facilement un composant COM/COM+, et réciproquement : alors tu penses bien que si celà avait posé un problème... Suffit de bien penser le passage d'un monde à l'autre, et de convertir les valeurs de retour d'erreur en exception.
Bref, même si à l'époque de bc1.0 pour DOS ce choix était vraiment discutable, cette argumentation ne tient plus du tout aujourd'hui puisque d'autres systèmes de message d'erreurs (exception) sont utilisées pour communiquer entre les applications.
Evidemment il y a des cas où celà peut être utile, notamment pour s'intégrer dans un environnement Unix, mais reste que ce cas de figure est de plus en plus rare, et il est normal que le langage n'impose plus ce genre de contrainte, tout en laissant le choix au programmeur d'utiliser cette possibilité s'il en a envie.