Le 22/12/2015 17:44, Ole Ersoy a écrit : > > . > >> 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?
I am fine with this. I did not check your design yet, sorry I am overwhelmed with several issues to fix for 3.6 that I would like to release soon. best regards Luc > > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
