Lew wrote:

Rrr?

How do you derive an "objection" to unchecked exceptions, much less attribute
such to me?

Such an objection most emphatically is not valid.  Of course.

Most Java programmers are very junior in their craft.  Anyway, checked
exceptions are for when you don't "know for a fact it isn't"; unchecked
exceptions are for when you should have known better.  Checked exceptions are
more for runtime conditions that the API insists that the client handle.
Unchecked exceptions are for programming mistakes, mostly.  Errors are just to
let you log some desperate cry for maintenance before crashing.

It is up to the API designer to design the API.  Part of a method's design,
arguably the most important part, is its method signature.  If it is important
for a client of the method to handle an exception, Java provides the checked
exception as the way for the API designer to ensure it.  The irritation of
lazy, unenlightened programmers is not a consideration.

If a designer is too lax or too strict in their design, that is a designer's
error.  Designers are responsible for their errors, and indeed some of the
best APIs have design flaws.  For example, java.util.Date.

For an API designer to avoid designing checked exceptions is bad, bad.  With
every method you design you have a choice - throw no exceptions, throw one or
more unchecked exceptions, throw one or more checked exceptions, or a
combination of the latter two.  (There isn't much need to design Error into
the signature.  If I think I need to design an Error, I'm going to rethink the
situation.)

Your choice is determined by your intention for the API.  What invariants must
you maintain?  Must a client deal with exceptions, as, say, for IOExceptions
thrown by a Stream?  You certainly want to ensure that clients are aware of
the likelihood of an exception, and guarantee that they have code in place to
deal with it.  Could there be more than one exceptional condition so different
that they need different Exception types?  See Class.newInstance().  Might the
problem be actually uncatchable, but still so important that it belongs in the
signature?  That's an Error, folks, as from Class.forName().

Notice that checked exceptions are mostly responses to run-time conditions -
they do not represent programmer mistakes.  Unchecked exceptions tend to
happen for things the programmer can control, like whether a variable is null.
   (Assertions are to check algorithmic invariants.)

Some exceptions are fundamental and essentially controllable by the client
programmer.  Invoking 'new Integer("Snark")' or 'Integer.valueOf("Snark")'
throws a RuntimeException, to be caught by the programmer that they may fix
their own mistake.  Integer really should not throw a checked exception here.

Be careful about reading into people's comments things that not only they did
not say, but with which they disagree.

Remember how people used to complain about parity-checked ROM?

I was being glib, but there is some truth behind my statement.  The reason to
have assertions in code (as opposed to just comments, or non-assertion
conditions that throw exceptions, is to ensure that a mismatch between the
developer's expectations and reality causes an event that's very hard to
miss.

Yes.  It might be clearer to say that assertions turn logic bugs into crash
bugs.  That crash bugs are higher severity than more subtle misbehavior is
not universal.

Agreed.
--
Mark Rafn    dagon@dagon.net    <http://www.dagon.net/>