Path: csiph.com!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail
From: Eric Sosman <esosman@comcast-dot-net.invalid>
Newsgroups: comp.lang.java.programmer
Subject: Re: Java Checked Exception is BAD!
Date: Sat, 6 Feb 2016 09:43:46 -0500
Organization: A noiseless patient Spider
Lines: 70
Message-ID: <n950m6$ad9$1@dont-email.me>
References: <00ab9f4e-0f06-48ec-9a65-1a150c129a39@googlegroups.com> <8565ac8a-e4e2-4178-b4da-7f3a8ef8069d@googlegroups.com> <n927ep$3j2$1@dont-email.me> <c1b3b4c8-2481-48fa-b4ad-9fcde6333811@googlegroups.com> <4deef389-ea5b-483a-bff5-4e1bdd45de2e@googlegroups.com> <2b736fcd-b72c-49b5-b4b8-9657ecebd51e@googlegroups.com> <n94sri$run$1@dont-email.me> <n94v2i$2b3$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 6 Feb 2016 14:41:10 -0000 (UTC)
Injection-Info: mx02.eternal-september.org; posting-host="2d081e2f7155c28005d4472f67c2f43d"; logging-data="10665"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX185u2jdJCM1ihR28Ia62PfQ"
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
In-Reply-To: <n94v2i$2b3$1@dont-email.me>
Cancel-Lock: sha1:XjP1HhE0fEQGsO/2jO8TgHL2jk4=
Xref: csiph.com comp.lang.java.programmer:33627

On 2/6/2016 9:13 AM, Martin Gregorie wrote:
> On Sat, 06 Feb 2016 08:38:23 -0500, Eric Sosman wrote:
>
>>       Read the Javadoc?  Well, no: You've already told us that listing
>> nine things in the throws clause is too much clutter to be considered
>> acceptable, so writing nine entire @throws paragraphs in the Javadoc
>> would be even more clutter, even less acceptable.  So, again: How many
>> of these nine exceptions should be Deep Dark Secrets from anyone who
>> might want to call method3()?
>>
> I have a tendency to write classes that trap the checked exceptions
> thrown by classes they call, deal with the non-fatal exceptions and use
> the remainder, along with any events my code generated and can't handle,
> to generate instances of the one or two exception types (one for fatals,
> the other for non-fatals, that my class's methods can throw. Those thrown
> as the result of lower lever fatals will contain the message etc from the
> inner exception, so they're effectively wrappers for them.
>
> This works for me and has the benefit of leaving only one or two
> exception types for outer classes to deal with, but is it generally
> considered to be a good or a bad approach?

     "Good or bad?"  Meh.  You pays your money and you takes your choice.

     Wrapping a multitude of causes into a few exception types has the
advantage of parsimony, but may impose a greater burden on the caller
who needs more detailed information.  Instead of writing separate catch
blocks for NoGoodException and FubarException and ThisSucksException,
he has to catch SomethingWentWrongException, use getCause(), and hope he
finds something recognizable.

     On the other hand, if all he's going to do is clean up and rethrow,
SomethingWentWrongException may be all the precision he needs.

     I'll also note that multi-catch

	try {
	   ...
	} catch (ThisException | ThatException | TotherException ex) {
	   ...
	}

can be an effective clutter-reducer.  And, of course, there's always
the strategy of

	class SomethingWentWrongException extends Exception {...}

	class NoGoodException extends SomethingWentWrongException {...}

	class FubarException extends SomethingWentWrongException {...}

	class ThisSucksException extends FubarException {...}

(when applicable).

     There are, of course, places where the entire exception mechanism --
checked or not -- becomes awkward.  Somebody's already mentioned how
poorly stream operations interact with exceptions; I guess the problem
of catching a whole cascade of exceptions thrown by different pipeline
stages in an asynchronous parallel stream is sort of, er, daunting.  And
I'll admit that checked exceptions cause problems of their own in some
situations: Every time I'm forced to wrap a checked exception in a
RuntimeException just because some interface's method doesn't have a
throws clause, I feel slightly dirty.  But IMO (not "proof"), checked
exceptions offer a useful prompt to coders, a reminder not to ignore
the corner cases.

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM