Re: Exception handling and encapsulation
On 2007-11-10 13:00, benben wrote:
[snip]
I don't quite understand: what do you mean with "know how to handle an
exception"? An exception is just that: an exceptional event which prevents
processing as usual. So it depends on what kind of application you're
designing: A GUI application would typically alert the user, a server
application would write an error message to the client and write a line to
the log-file and finally a CLI application would print an error to the
console and stop execution.
Thanks for you comment. But let me say a few words...
Alerting the user or logging the error is fine. However, in some
situations the software should do more than just that, in order to
recover from the exceptional event. For example, depending on the
situation, to handle a network connection error a program can resend a
packet or re-establish a new connection or what have you.
What I wanted to say in the original message, is that the exception that
can be thrown from a subsystem is part of the system's interface and
will too participate in the encapsulation process. Letting an exception
from much lower level to propagate to a high level function breaches the
encapsulation.
Yes, an exception should generally be handled at the lowest level
possible. Some exceptions can not be handled in the current subsystem
and then it might be a good idea to catch it in the subsystem and then
throw a new more generic error to the caller of the subsystem.
For example, you are going to an ATM machine and try to check your bank
account. Somewhere in the ATM software system a low level logging
function finds that the log file is full. It throws an exception and the
it is not caught until it hits the highest level--you as the exception
handler.
You are notified, "operation halt: log file full". You as a user must be
much puzzled, because the error message is too low level in abstraction,
and does not give you any useful information about what goes wrong.
Ideally you should only be exposed to an abstraction of the immediate
lower system where exceptions such as "wrong pin" or "card expired" are
raised occasionally.
What do you do? Perhaps try again? Or maybe you should use another ATM
machine, or just go to the bank counter and file a complaint. But then
your decision (to handle the exception) is not based on the nature of
the exception. You may have some idea what "log file full" means, but
others don't.
The user should just be informed that an unrecoverable error has
occurred, perhaps with the possibility to get more information.
So basically my answer would be to catch the exception at the highest
possible level.
In my opinion, though, an exception shall be handled at the lowest
possible level. This minimizes the system complexity as this piece of
implementation detail is abstracted away from the higher level systems.
Yes, an exception is an error that can not be handled at the current
level and should thus propagate up to a level where it can be handled.
At suitable places (such as subsystem boundaries) the exception might be
caught and a new more general exception can be thrown.
It is only when exception handling locally is impossible or unnecessary
the exception is to propagate upwards. This is exactly where my problem
comes in.
If it is unnecessary to handle the exception it should not have been
thrown to begin with.
Even if the exception is to propagate upwards, it does not mean it
should always go all the way to the highest level (e.g. main()). It
depends on the problem nature, IMO.
Only unrecoverable errors (or those that can be handled in main())
should ever reach main(), those that can not be handled should there be
caught and an error message be written and the application terminated
with as much clean-up as possible.
--
Erik Wikstr??m