On Nov 29, 2007 7:58 PM, Paul J. Lucas <[EMAIL PROTECTED]> wrote:
> On Nov 29, 2007, at 4:52 PM, Tim Peierls wrote:
> > Abstractly, though, would you rather see ReferenceBuilderException
> checked or unchecked in the following:
> >
> > try {
> > Reference ref = ReferenceBuilder.appendBar
> ("myBar").appendFoo("myFoo");
> > // do something with ref
> > } catch (ReferenceBuilderException e) {
> > // myBad: foo must come before bar
> > // clean up
> > // ? throw e;
> > }
> >
> > Programmer was wrong -- this should be unchecked, right?
>
> How do you know the programmer was wrong? How does the implementor of
> ReferenceBuilder know whether the data was supplied by the programmer or the
> user of the program? If the latter, it's the user who is wrong in which
> case the programmer must deal with that. Therefore: checked exception.
Yes -- sorry, got it backwards in my example.
Unchecked exceptions are appropriate when the programmer can't reasonably be
expected to handle the exception completely. Canonical example: If I'm out
of memory, the best I can hope for is to flush file handles and try to clean
up in a finally block. For some specific unchecked exceptions with special
clean-up needs, *maybe* I'd catch and rethrow. But I can't think of a case
where you would swallow an unchecked exception.
I stick to the claim that verbs implying order in a Builder-style API may be
appropriate in some settings.
> In general, IMHO, you've got to have a really, really good reason to make
> an exception unchecked. "Because it's easier" isn't a good reason.
>
Pretty much the point I was making on the "Exceptions in general" thread.
But the "Because it's easier" argument is stronger you might think: I've
come to regret the fact that Callable.call throws Exception. When the JSR
166 EG was designing Callable and friends, we had trouble deciding which way
to go on this; we ended up with a conservative approach that in my
(subsequent) experience tends to make things harder for the programmer with
no real benefit.
--tim
