handling exceptions correctly

[Chris P.]

Do you agree or disagree about whether a compiler forces you to catch exceptions,
and that most developers (especially beginners) don't know how to handle
them correctly? What has been your experience in this?

Chris P.

[Roopak]

"Chris P." <cpreimesberger@devx.com> wrote:
>
>Do you agree or disagree about whether a compiler forces you to catch exceptions,
>and that most developers (especially beginners) don't know how to handle
>them correctly? What has been your experience in this?
>
>Chris P.
"Chris P." <cpreimesberger@devx.com> wrote:
>
>Do you agree or disagree about whether a compiler forces you to catch exceptions,
>and that most developers (especially beginners) don't know how to handle
>them correctly? What has been your experience in this?
>
>Chris P.

I totally agree with this observation. I have been a C++/java developer for
past 4 years, I have the same experience particular with new/beginners, I
have used the approach outlined by Dr. Heinz Kabutz about exception converter
in many places. I would like to point out something more :
a call to super. printStackTrace(java.io.PrintStream s) and
super.printStackTrace(java.io.PrintWriter w) should be added in the
printStackTrace(java.io.PrintStream s) and printStackTrace(java.io.PrintWriter
w) of class ExceptionConverter after you print the stack trace of the embedded
exception. This will correctly tell you the stack trace if an error occurs.

[Doug Bell]

The basis of this article is that checked exceptions are a bad idea because
it is possible to write code that satisfies the compiler requirement to catch
the exception without providing useful handling of the exception. The solution
apparently is to convert checked exceptions into (potentially) unrelated
generic unchecked exceptions so that it is easier for beginning programmers
to omit proper exception handling code. The article even goes so far as
using this reasoning to question the decision to include checked exceptions
in the Java language.

This line of reasoning is so fundamentally flawed that I'm not sure where
to start. The entire point of checked exceptions is to, at a minimum, force
the programmer to acknowledge and handle failures and exceptional conditions
that can be reasonably expected to happen and reasonably handled. That many
programmers continue to write "optimistic" code in Java that does not handle
all execution paths is an unfortunate reality. C and C++ went down this
road at the expense of robustness and predictability.

Methods should throw exceptions that are appropriate for the level of abstraction
of the operation. This is the rationale under which an exception can be
converted from one type to a new type that is more appropriate to the abstraction.
In some cases the circumstances under which a checked exception can occur
may dictate that converting a checked exception to an unchecked exception
is appropriate for the level of abstraction of the method performing the
conversion. However, this is not something to be applied in a blanket manner
and solely for the purpose of making it easier to omit proper exception handle
code--exception translation should not be overused.

In addition to the above, Dr. Kabutz makes no mention of exception chaining,
which is a more general approach to converting exception types while preserving
the original exception information. This is a particularly glaring omission
since exception chaining has been added to the Throwable class in J2SE 1.4.