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
