c'est que c'est normalement un cas qui ne doit JAMAIS arriver; si cela arrive, les unités de parse de log te remontent le machin directe chez le dev pour qu'il regarde le cas
Donc le cas qui ne doit JAMAIS arriver, tu mets quand même un système pour vérifier qu'il n'arrive jamais en fait.
Et quand ce qui n'arrive jamais arrive, le système va tout de même avoir un comportement et puisque que tu ne veux pas que ton système plante, offre 10M$ au client ou tue un petit chaton tu vas forcément avoir un chemin d'exécution qui prend le truc en compte tu ne peux pas juste continuer après ton serr comme si de rien n'était.
tiens un truc amusant pour chopper un constructor que l'on sait exister avec ensuite utilisation de ce constructor j'ai ça dans mon catch : InstantiationException | InvocationTargetException | NoSuchMethodException | IllegalAccessException
ça en fait pas mal pour rien...
[^] # Re: Mauvaise connaissance du c++
Posté par ckyl . En réponse au journal Gestion de l'erreur - C++ - std::optional. Évalué à 3.
Donc le cas qui ne doit JAMAIS arriver, tu mets quand même un système pour vérifier qu'il n'arrive jamais en fait.
Et quand ce qui n'arrive jamais arrive, le système va tout de même avoir un comportement et puisque que tu ne veux pas que ton système plante, offre 10M$ au client ou tue un petit chaton tu vas forcément avoir un chemin d'exécution qui prend le truc en compte tu ne peux pas juste continuer après ton serr comme si de rien n'était.
Effectivement =>
catch (ReflectiveOperationException e);)Après non, on ne va pas défendre la plupart des API du JDK non plus faut pas pousser.