Re: Exceptions

[Ray Blaak <rAYblaaK@STRIPCAPStelus.net>]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> The Java programmers who have been mentioned several times in this
> thread -- the ones who evilly stick in do-nothing handlers -- are doing
> so on purpose.  Any attempt to fix that problem via language design will
> backfire.  Fixing it via education OTOH has a good chance of success.

I used to "believe" in checked exception handling, my Ada experience being the
likely inspiration.

Long experience with Java code leads me to believe they cause more problems
then they solve, simply due to the fact that the majority of programmers are
coding at a junior or "naive" level.

So, when the compiler demands an exception handler, then by golly they provide
one -- one that simply swallows the exception with a log of the stack trace.

This is in fact far worse than not handling the exception at all, since
control flow is not aborted.

So, the junior programmer evilly stuck in a do-nothing handler, but they had
no clue they were being evil.

Note also that the theoretical correctness of whether or not checked
exceptions are better is not being disputed here -- the answer is
irrelevant. The *practical* effect of checked exceptions, at least with junior
programmers, tends, in Java at least, to cause worse results than not handling
the exception at all.

So, C#'s approach of not having checked exceptions is turning out to be a
better design decision in practice, in my experience.

Another point is to consider what one usually does with a handled
exception. Usually it is to ultimately report it or log it in some manner.
Primarily it needs to perculate up to a top level, where some sort of central
event loop can be reset. Sometimes some cleanup needs to be done, but that
cleanup often tends to be needed for any exception that is thrown, and the
exception should often be rethrown anyway so as to continue to abort the
control flow. My experience is that most code does not need to handle
exceptions at all except at well defined points in the top level.

Mind you, with the use of a non-garbage collected language like Ada, one would
need to do cleanups with exceptions more often, but that does not imply the
need to do specific exception handling.

The times I have seen the need for exception specific handling is usually to
do with error message generation. Some exceptions need to show stack traces,
some need to show different messages, some need to be shown to the user,
etc. This kind of thing is easier to centralize in a language where exceptions
are first class objects, since one can override exception behaviour
(e.g. anything extending from UserException will be shown to the user,
anything else will be logged with a stack trace, with only an "unexpected
error" shown to the user, paprticular error reasons are shown via overriding
the getMessage() method, etc.).

I note also that recent APIs for Java (e.g. XML DOM, Joda data/time, D4Bo
OODB) tend to use unchecked exceptions in their APIs, since it makes
development so much easier for writing and maintaining code against those
APIs.

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
rAYblaaK@STRIPCAPStelus.net                    The Rhythm has my soul.