> 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). Regards, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
