commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <>
Subject Re: [Math - 403] Never propagate a "NullPointerException" resulting from bad usage of the API
Date Wed, 02 Mar 2011 11:37:17 GMT
> The recognised standard in the JDK is NPE on invalid null input.
> I have never overly liked this, but conform to it for JSR-310/ThreeTen.
> I use IAE in other projects which are higher up the stack. Whether
> [math] is low or high level may determine the choice you make.

I've always heard that CM is "low"-level; and this serves as the basis of
many arguments (e.g. the "no-dependency" one).
However I think that, in CM, the line between low- and high-level is blurred
when some features are concerned (e.g. IMO localization does not belong in a
low-level library).

> Personally, I don't use NullArgEx, as it is never an exception that
> the user should catch. The message of IAE is sufficiently good to
> remove the need for NullArgEx. Thus in my opinion, [math] would be
> better off without NullArgEx (as it adds no real value).

I guess that not everyone would agree with the "never". An application
requirement might be that only a certain kind of exception is expected.
Thus calls to CM are wrapped and every exception that comes out is turned
into one of the "allowed" exceptions.
I don't discuss whether it's good or bad programming style, I just mention
that it happens.

> However, with this, and other exception issues, the truth is that for
> [math] its mostly a matter of taste. The value in [math] is in the
> algorithms, not in whether the exceptions are any good or not. As
> such, I would advise worrying less about exceptions, and more about
> maths. If there is an exception decision, just try to follow the
> modern JDK examples where possible (as it reduces discussion here).

My viewpoint is that an exception is, in essence, a low-level object. It
should just remain a very convenient way to communicate failure from a lower
to upper layers of code. My revamping the CM's exceptions aimed at regaining
the straightforward usage of standard exceptions (i.e. a direct call to
"new" for constructing an exception that conveys the unadorned reason for
the failure).
The compromise we had reached was about keeping the localization feature,
which in turn implied a departure from the standard exceptions in order to
avoid code duplication. I consider this more important than using the
standard exceptions hierarchy because, in CM, most exceptions are not
recoverable anyway and they mainly serve by showing a failure message (i.e.
at that point, whether an object is an instance of this or that class does
not matter anymore).

The discussion flared up when we started arguing on semantical issues that
(IMHO) exceptions were not designed to handle and cannot enforce. I'm not
going to re-state all the arguments once again; I'll simply quote you:
  "The value in [math] is in the algorithms, not in whether the exceptions
   are any good or not."
I totally agree with the first statement, of course. The second part does
not add (nor subtract) any value to it; it's unrelated. In my view, the
exceptions are good if they allow to easily track down bugs (be they in CM
or in user code). Accordingly they must precisely point to the source of the
problem (in the code) and not try to outguess the user (as to what it
should mean for him).


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message