Je ne visais pas spécialement le langage, mais je me pose quand même une question : pourquoi est-ce davantage en Java que l'on voit ce genre de choses ?
Je ne peux que partager ma théorie:
Java est un langage très prisé dans les écoles, mais on ne force pas les étudiants à traiter les erreurs correctement.
Comme Java impose d'avoir un try/catch dans chaque fonction dont une des fonctions fille peut lancer, on se retrouve avec des try/catch en cascade qui ne font que des rethrow.
J'imagine, n'étant pas un dev Java (ça m'est arrivé d'en faire, maintenance pour taf, mais j'ai toujours essayé d'esquivé) que quand on relance, ça ajoute automatiquement des infos?
Ou alors, c'est juste le comportement des outils standards, et comme les codes Java que j'ai vus ont toujours été faits par des gorets (du genre que tu peux diminuer de 15% la taille d'un fichier en 1ère lecture sur des fichiers de 4KLoc... véridique.) les exceptions sont juste balancées dans des messagesbox ou balancées sur stdout à l'arrache. Résultat: débuggable, mais galère.
Perso les exceptions, je commence à me dire qu'en fait, si je peux m'en passer, je le ferais quitte à faire des efforts ou à devoir fournir une interface un peu différente de l'habitude.
Je n'ai jamais été fan d'essayer de remettre le programme d'équerre en cas d'erreur (parfois il n'y a pas le choix, ok) je préfère un plantage propre (avec une sauvegarde des données si utile, et c'est bien là que les exceptions, utilisées correctement sont intéressantes).
Récemment, j'ai appris qu'en C++ une exception non récupérée est un UB. Je pensais que c'était un crash en standard, car c'est le comportement par défaut de VS, GCC et clang, mais non.
Du coup, ça veut dire que tous les codes que j'ai écrits jusqu'à ce que je m'aperçoive de ça, sont bugués, parce que j'utilisais les exceptions pour renvoyer des infos de débogage si elles ne sont pas attrapées, histoire qu'au moindre crash le dev ou l'admin sache exactement ce qui à causé l'exception (rade de RAM, IO foireuse, etc... ) sauf que vu que c'est un UB, si ça se trouve le programme ne balance pas les infos correctement, ou pire, oublie de nettoyer certains trucs.
J'ai aussi récemment appris que les appels à exit, par exemple, cassent les exceptions. Du coup, vu que j'aime beaucoup balancer mes codes réutilisables dans des bibliothèques, mon style de codage en à pris en coup: j'essaye d'éviter au maximum les exceptions quitte à risquer un segfault. Au moins un segfault, ça crash, c'est garantit.
Bref, les exceptions c'est l'un des aspects de l'OO sur lesquels je me pose aujourd'hui de vraies questions.
Et pour ce qui est de l'ADA... ça fait 4 ans que je me dis qu'il faudrait que je m'y mette... il y à Rust, aussi, qui m'intéresse beaucoup. Parce que moi, je veux que le compilo soit le plus chiant possible, histoire qu'au moins quand ça exécute, il y ait de grandes chances que ça marche. C++ est un peu léger de ce côté.
[^] # Re: BEURK !!!!
Posté par freem . En réponse au message apprendre java. Évalué à 3.
Je ne peux que partager ma théorie:
Java est un langage très prisé dans les écoles, mais on ne force pas les étudiants à traiter les erreurs correctement.
Comme Java impose d'avoir un try/catch dans chaque fonction dont une des fonctions fille peut lancer, on se retrouve avec des try/catch en cascade qui ne font que des rethrow.
J'imagine, n'étant pas un dev Java (ça m'est arrivé d'en faire, maintenance pour taf, mais j'ai toujours essayé d'esquivé) que quand on relance, ça ajoute automatiquement des infos?
Ou alors, c'est juste le comportement des outils standards, et comme les codes Java que j'ai vus ont toujours été faits par des gorets (du genre que tu peux diminuer de 15% la taille d'un fichier en 1ère lecture sur des fichiers de 4KLoc... véridique.) les exceptions sont juste balancées dans des messagesbox ou balancées sur stdout à l'arrache. Résultat: débuggable, mais galère.
Perso les exceptions, je commence à me dire qu'en fait, si je peux m'en passer, je le ferais quitte à faire des efforts ou à devoir fournir une interface un peu différente de l'habitude.
Je n'ai jamais été fan d'essayer de remettre le programme d'équerre en cas d'erreur (parfois il n'y a pas le choix, ok) je préfère un plantage propre (avec une sauvegarde des données si utile, et c'est bien là que les exceptions, utilisées correctement sont intéressantes).
Récemment, j'ai appris qu'en C++ une exception non récupérée est un UB. Je pensais que c'était un crash en standard, car c'est le comportement par défaut de VS, GCC et clang, mais non.
Du coup, ça veut dire que tous les codes que j'ai écrits jusqu'à ce que je m'aperçoive de ça, sont bugués, parce que j'utilisais les exceptions pour renvoyer des infos de débogage si elles ne sont pas attrapées, histoire qu'au moindre crash le dev ou l'admin sache exactement ce qui à causé l'exception (rade de RAM, IO foireuse, etc... ) sauf que vu que c'est un UB, si ça se trouve le programme ne balance pas les infos correctement, ou pire,
oubliede nettoyer certains trucs.J'ai aussi récemment appris que les appels à
exit, par exemple, cassent les exceptions. Du coup, vu que j'aime beaucoup balancer mes codes réutilisables dans des bibliothèques, mon style de codage en à pris en coup: j'essaye d'éviter au maximum les exceptions quitte à risquer un segfault. Au moins un segfault, ça crash, c'est garantit.Bref, les exceptions c'est l'un des aspects de l'OO sur lesquels je me pose aujourd'hui de vraies questions.
Et pour ce qui est de l'ADA... ça fait 4 ans que je me dis qu'il faudrait que je m'y mette... il y à Rust, aussi, qui m'intéresse beaucoup. Parce que moi, je veux que le compilo soit le plus chiant possible, histoire qu'au moins quand ça exécute, il y ait de grandes chances que ça marche. C++ est un peu léger de ce côté.