C'est pour cela que j'ai tendance à préférer le stacktrace qu'on retrouvera dans les logs; ça évite de planter toute l'appli et de déconnecter sauvagement tous les utilisateurs du serveur métier.
Le stacktrace local n'est pas une solution. Ce que tu veux c'est que la fault remonte vers le fault handler adéquat qui fera alors la reprise sur erreur attendu pour l'unité en cours d'exécution (fonctionnel et non fonctionnel):
Logguer / publier des métriques / créer une entrée dans le ticketing
Re-essayer l'unité logique
Planter le processus / Servir un message
Etc.
Souvent quand tu as une base de code ou 90% des catch sont printstacktrace() / serr / log, tu vas aussi trouver des choses comme ça:
long value;
try {
value = Long.parseLong(str);
} catch (NumberFormatException e) {
e.printStackTrace();
}
return value + 2;
[^] # Re: Mauvaise connaissance du c++
Posté par ckyl . En réponse au journal Gestion de l'erreur - C++ - std::optional. Évalué à 2.
Le stacktrace local n'est pas une solution. Ce que tu veux c'est que la fault remonte vers le fault handler adéquat qui fera alors la reprise sur erreur attendu pour l'unité en cours d'exécution (fonctionnel et non fonctionnel):
Souvent quand tu as une base de code ou 90% des catch sont
printstacktrace()/ serr / log, tu vas aussi trouver des choses comme ça: