Re: Exception handling and encapsulation
[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.
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.
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.
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.
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.
[...]
Furthermore, should the higher level system choose to handle exceptions
from multiple layers down, it risks to be turned invalid as soon as
changes are made to the lower level systems. This is very similar to
accessing a class member that is ought to be private.
Why would it? The exception should know how to produce a sensible error
message, therefore any change in the lower level would just affect the
exception itself, but not the higher level. All you need is a sane
interface for exceptions. Or am I missing something?
It gets complicated when the exception means more than just producing a
sensible error message.
Regards,
Ben