Le 26 Apr 2002 Didier Bretin a écrit :C'est l'approche que je préconise également. C'est aussi ce que suggère Bruce Eckel dans son livre "thinking in Java" au chapitre 9:
>
> Que pensez-vous de cette approche ? Est-elle 'logique' avec une
> conception Java ? Me trompe-je ? :o)
>
Je renvoie par un throw, sans autre forme de procés, toutes les
exceptions qui se produisent au sein des méthodes private et
protected. Je considère qu'elles font des traitements internes pour
d'autres traitements internes, et si quelque chose fontionne mal, ce
n'est pas à un niveau "interne interne" de s'en occuper. Il y a
quelques exceptions à ce principe, toutefois, mais c'est assez rare.
An exceptional condition is a problem that prevents the continuation of the method or scope that you’re in. It’s important to distinguish an exceptional condition from a normal problem, in which you have enough information in the current context to somehow cope with the difficulty. With an exceptional condition, you cannot continue processing because you don’t have the information necessary to deal with the problem in the current context. All you can do is jump out of the current context and relegate that problem to a higher context. This is what happens when you throw an exception.
Le traitement réel des exceptions a lieu au niveau des méthodesJe ne suis pas d'accord. Une exception indique une erreur grave qui implique un branchement vers d'autres instructions ou bien l'arrêt du logiciel afin d'informer l'utilisateur que l'opération a échoué. Tenter de corriger la provenance de l'exception (comme par exemple en incluant les "try/catch" dans un "while") s'avère difficile et peut aussi échouer. C'est en fait la problématique mieux connu sous le nom "termination vs resumption" et le choix fondamental que les concepteurs de Java ont fait est de supporter le premier. Voici d'ailleurs ce qu'a écrit Bruce Eckel à ce sujet:
publiques. En effet, à ce niveau, une entité extérieure attend un
service. Si ce service n'a pu se dérouler correctement, le
"prestataire" doit être en mesure d'expliquer pourquoi, et de se
remettre dans un état correct.
Deux fonctions existent donc : expliquer, et se remettre dans un état
correct.
Termination vs. resumption
There are two basic models in exception-handling theory. In termination (which is what Java and C++ support), you assume the error is so critical there's no way to get back to where the exception occurred. Whoever threw the exception decided that there was no way to salvage the situation, and they don't want to come back.
The alternative is called resumption. It means that the exception handler is expected to do something to rectify the situation, and then the faulting method is retried, presuming success the second time. If you want resumption, it means you still hope to continue execution after the exception is handled. In this case, your exception is more like a method call - which is how you should set up situations in Java in which you want resumption-like behavior. (That is, don't throw an exception; call a method that fixes the problem.) Alternatively, place your try block inside a while loop that keeps reentering the try block until the result is satisfactory.
Historically, programmers using operating systems that supported resumptive exception handling eventually ended up using termination-like code and skipping resumption. So although resumption sounds attractive at first, it seems it isn't quite so useful in practice. The dominant reason is probably the coupling that results: your handler must often be aware of where the exception is thrown from and contain non-generic code specific to the throwing location. This makes the code difficult to write and maintain, especially for large systems where the exception can be generated from many points.
Sylvain
