Le code java est pollué par de la gestion de truc qui n'arrivent jamais, et le jour où ça arrive, c'est tellement ignoré que ça passe à la trappe; j'ai une préférence pour faire un printstacktrace, au cas où.
Hum ignoré ou printStracktrace(), dans les deux cas tu as merdé ton design quelque part. À priori même à deux endroits: définition de l'API et gestion des erreurs à l'utilisation.
Normalement au pire tu utilise une API qui utilise des checked exceptions pour signaler des cas que tu considères être des faults plutôt que des contingencies (ie. tu ne peux rien faire localement sinon remonter le problème à un fault handler de plus haut niveau qui lui décidera de l'action adéquat)
Ça reste verbeux mais il n'y a pas de miracle. Les gens qui utilisent des unchecked se plaignent du côté loterie, de la gestion de compatibilité impossible etc. mais ne sont pas embêtés pour écrire du code de porc. Et les gens qui utilisent des checked se plaignent d'avoir à gérer ce qui est a gérer. Comme la flemmardise et le vite fait mal fait sont la règle dans le métier, on a tendance à plus entendre les gens qui ne veulent gérer aucun cas d'erreur.
Et comme les faults des uns sont souvent les contingencies des autres, on arrivera rarement a faire une séparation propre des deux niveaux API.
c'est tellement ignoré que ça passe à la trappe; j'ai une préférence pour faire un printstacktrace, au cas où.
Et depuis la nuit des temps, ce genre de code bases sont des tas de boue.
Même quand le langage est pas coopératif, c'est pas bien difficile de mettre en place des principes simples qui empêche d'ignorer ce genre d'erreurs. Au minimum tu imposes que les trucs "impossibles" soient remontés au fault handler le plus proche ou racine, plutôt que de continuer son petit bonhomme de chemin.
A choisir, pouvoir raisonner sur une base de code est beaucoup plus important que sauver deux lignes de code.
[^] # Re: Mauvaise connaissance du c++
Posté par ckyl . En réponse au journal Gestion de l'erreur - C++ - std::optional. Évalué à 1.
Hum ignoré ou
printStracktrace(), dans les deux cas tu as merdé ton design quelque part. À priori même à deux endroits: définition de l'API et gestion des erreurs à l'utilisation.Normalement au pire tu utilise une API qui utilise des checked exceptions pour signaler des cas que tu considères être des faults plutôt que des contingencies (ie. tu ne peux rien faire localement sinon remonter le problème à un fault handler de plus haut niveau qui lui décidera de l'action adéquat)
Ça reste verbeux mais il n'y a pas de miracle. Les gens qui utilisent des unchecked se plaignent du côté loterie, de la gestion de compatibilité impossible etc. mais ne sont pas embêtés pour écrire du code de porc. Et les gens qui utilisent des checked se plaignent d'avoir à gérer ce qui est a gérer. Comme la flemmardise et le vite fait mal fait sont la règle dans le métier, on a tendance à plus entendre les gens qui ne veulent gérer aucun cas d'erreur.
Et comme les faults des uns sont souvent les contingencies des autres, on arrivera rarement a faire une séparation propre des deux niveaux API.
Rien de nouveau sous le soleil: http://www.oracle.com/technetwork/java/effective-exceptions-092345.html
Et depuis la nuit des temps, ce genre de code bases sont des tas de boue.
Même quand le langage est pas coopératif, c'est pas bien difficile de mettre en place des principes simples qui empêche d'ignorer ce genre d'erreurs. Au minimum tu imposes que les trucs "impossibles" soient remontés au fault handler le plus proche ou racine, plutôt que de continuer son petit bonhomme de chemin.
A choisir, pouvoir raisonner sur une base de code est beaucoup plus important que sauver deux lignes de code.