.
One of the point in having exceptions that extends our own root exception is that users at higher level can catch this top level. Currently, we don't even advertise properly what we throw. We even miss to forward upward some exceptions thrown at low level in the javadoc/signature of out upper level methods. So user may currently not know, only reading the javadoc/signature of one of our implementation that they may get a MIAE or something else. If we were using a single root,
Or just a single MathException.
they would at least be able to do a catch (MathRootException) that would prevent a runtime exception to bubble up too far. Currently, defensive programming to protect against this failure is to catch all of MathArithmeticException, MathIllegalArgumentException, MathIllegalNumberException, MathIllegalStateException, MathUnsupportedOperationException, and MathRuntimeException.
With the design I proposed, and the design I'm using, we only have to catch one. After it's caught the type code (Enum) indicates precisely what the issue is.
In a perfect world, we would be able to extend a regular IAE while implementing a MathRootException, but Throwable in Java is a class, not an interface. Too bad.
Luc - how do you feel about a single MathException that extends RuntimeException with an Enum that indicates what the root cause is and can be used as the key to look up the corresponding message template which can be resolved into a message using parameters attached to the MathException context? Here's an example from my refactoring of ArithmeticUtils: https://github.com/firefly-math/firefly-math-arithmetic/blob/master/src/main/java/com/fireflysemantics/math/arithmetic/Arithmetic.java /** * Add two integers, checking for overflow. * * @param x * an addend * @param y * an addend * @return the sum {@code x+y} * @throws MathException * Of type {@code MAE__OVERFLOW_IN_ADDITION} if the result can * not be represented as an {@code int}. */ public static int addAndCheck(int x, int y) throws MathException { long s = (long) x + (long) y; if (s < Integer.MIN_VALUE || s > Integer.MAX_VALUE) { throw new MathException(MAE__OVERFLOW_IN_ADDITION).put(X, x).put(Y, y); } return (int) s; } The toString() method of the exception is implemented like this and delivers the exception root cause (Enum) and parameter name and value pairs: @Override public String toString() { String parameters = context.entrySet().stream().map(e -> e.getKey() + "=" + e.getValue()).collect(Collectors.joining(", ")); return "Firefly math exception type " + this.type + ". Context [" + parameters + "]"; } So we get a pretty good indication of what the issue is by just using toString() to construct the message. Cheers, Ole --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
