The Role of Exceptions in an Ideal World
I was truly thrilled when I first came across exceptions in C++ after using the clumsy error reporting style of C. It made my algorithms cleaner and, therefore, it made me happy. After several years, I tried Java and I found it interesting to impose the discipline of explicitly declaring the exceptions that may be raised in a routine.
Again, after a while, I found this obligation cumbersome and found myself relieved to see that C# did not impose this constraint. So much for my pre-Eiffel to exposure exceptions.
When I began programming in Eiffel, I noticed too aspect of the Eiffel attitude toward exceptions. First, in his coding guidelines, I saw that Eric Bezault suggested that we document in the routine's header the exceptions that could rise from an execution of the mentioned routine. On the other hand, in OOSC Meyer shows several design guideline to avoid using exceptions such as a priority validity checks (e.g. in preconditions) and a posteriori checks which are done by loosing a routine's postcondition by saying "X will be true if there was no errors" instead of "X will be true".
I then noticed that not many routines use exceptions handling and they seem to be divided in two categories. The first is the category of routines that interfaces with a non Eiffel and (let's say it) less reliable system. The second is category of routines which aim at factoring out the processing of uncaught exceptions (usually near the main).
So here is where the question comes up: what are exceptions good for when we have design by contract? Let's go to the extreme and say that we are able to formally prove the correctness of our Eiffel system. As I see it, the only cause for exception handling then would be for memory errors and interfacing with less well-behaved systems.
Having proven the validity of our system, we don't need to catch assertion violations or void calls and it seems that the error conditions in all Eiffel code could be handled by a priori or a posteriori checks.
My conclusion is therefore that we probably need to put exception declaration in the header of routines and design rules for the interaction with the inheritance mechanism. Furthermore, I would add that the convention is adopted by Java is not a bad one but the clumsy style it creates is only a sign that Java does no distinction between a contract violation and exceptional (unplanned) condition.
Adopting it in Eiffel would therefore give a precise criterion to the programmer as to where efforts has to be spent to make sure the invariant of a class must be reestablished after an exception.
I would be very interested in hearing about your opinions and experience on that topic.
Note: In what consider an ideal world, all Eiffel systems are ideal. In that respect, this entry is only concerned about ideal Eiffel systems which are systems for which the total correctness has been formally proved. I didn't include memory conditions in this correctness criteria so you can consider it a weak idealism on my part.