Re: can't throw

From:

=?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk>

Newsgroups:

comp.lang.java.programmer

Date:

Wed, 12 Sep 2012 21:37:15 -0400

Message-ID:

<505138ce$0$295$14726298@news.sunsite.dk>

On 9/12/2012 9:29 PM, Gene Wirchenko wrote:

On Wed, 12 Sep 2012 18:36:41 -0400, Arne Vajh?j <arne@vajhoej.dk>
wrote:

On 9/12/2012 12:18 PM, Gene Wirchenko wrote:

On Tue, 11 Sep 2012 21:59:16 -0700, Peter Duniho
<NpOeStPeAdM@NnOwSlPiAnMk.com> wrote:

For whatever reason, I've never found checked exceptions a compelling
feature. It's absolutely in the right spirit, one which I agree
wholeheartedly with. And yet I find that at least in the Java
implementation, it seems to create more headaches than it prevents.

To me, it also seems as if it would be a good idea, but using it
is awkward. In some coursework, I used a Java cryptographic system.
It had a lot of exceptions to handle so my code had a lot of catches.
Because I did not know what was thrown, I wrote my code without them
and then added whatever the compiler stated was missing. In those
catches, there really was not anything that I could do other than
reporting the error.

Sounds more like a design problem.

I did not write the crypto package.

No.

But I assume you wrote the code where yous ay you put in all
those catch.

You should catch exceptions at the level where it can be handled
(either where a method can do something that will allow the program
to continue to run or at the outer level where the program can be
terminated).

Well, the level I caught the exception at was the individual
calls to the package. There were so many exceptions, and it was
really irrelevant what the exception was. Whatever it was, it meant
that my program had failed. Writing the glue code to catch each of
these exceptions was simply make-work.

Definitely sounds as if it was a big mistake to catch the exceptions
where they happened.

There is just one thing that is worse than catch everything possible,
report it and continue without doing anything or terminating everywhere
in the code - and that is doing the same thing except not reporting it.

Way too many exceptions is typical a sign of code not properly divided
in layers/components. Such throw layer/component specific exceptions but
hides all the implementation specific exceptions.

I prefer reading the main flow of execution as a high-level
story. Catches interrupt this. When there are a lot of catches, they
make the main code harder to find.

You should not really have more catches due to checked exceptions.

You should only catch exceptions that you can do something useful
about it. That an exception is checked does not change whether you can
so something useful about it. It just reminds you of its existence.

I had to catch the exceptions or get a compilation error for each
one I missed.

No.

You has to catch them *or* pass them back the caller by adding throws to
the method signature.

If the method can not really do anything about the exception then
the last option is what should be used.

Arne