Re: NullPointerException, IllegalArgumentException, or AssertionError
for null constructor argument
On second thought, when construction with null is allowed, then
subsequent method calls *could* reasonably throw IllegalStateException
if the object is still null when they need them. Still, I like to call
a spade a spade, so when something fails because a pointer is null, it
makes sense to let NPE be thrown.
Checked exceptions are a good way to ensure that client code will handle the
exception thrown by a constructor or method.
As for your objection to non-checked exception here, it is valid of course.
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.
But most java [sic] programmers will probably frown at having to try-
catch around a method call just for the case that the object reference
they pass is null, when they know for a fact it isn't.
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
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.