Hi Gilles, It sounds like we're starting to coalesce on this. Hopefully this is not going to come as too much of a shock :). [1] The exception patch will permeate every class that throws an exception. We will have to delete all the other exception and replace them with MathException. Here's an example from the ArithmeticUtils refactoring:
https://github.com/firefly-math/firefly-math-arithmetic/blob/master/src/main/java/com/fireflysemantics/math/arithmetic/Arithmetic.java#L582 Notice that the Javadoc has 2 throws declarations containing the same exception using different exception types. Luc - I think the localization design your created is as elegant as can be. As far as productivity goes the ExceptionFactory class utilization pattern remains unchanged. I feel like we just got done stacking 50 wine classes, and I'm not sure I want to move anything, unless I just throw a fork wrench at it in [1] above :). So suppose we include the MathException with localization. If anyone is a super purist (Like me) they can just remove the 6 lines of localization code. Reinstall. Done. So from a practical point of view it's about as trivial as it gets. So the only thing that bugs me about it is that others looking at CM might have the "Why is there localization code in the exception" reaction. And maybe there is a good reason for that, but having looked at the threads so far, it's not obvious to me that there is. For example say we have an application exists that throws at 10,000 different points in the App without catching. So I'm guessing either a server web app or just some app we run from the console. We get a stack trace. Most of it is in English right (Java vernacular)? So my gut reaction is that if someone gives me a technical manual in Greek, and it has one sentence in English, that's not so helpful. This is Java and Math combined. Anyone looking at it is probably very smart, very confused, or asleep. Also, the documentation will be updated to say that in order to get translated exception messages, before using CM, set this property on this class. Or it could say: ----------------------------------------------------------- In order to translate exception put the following try catch block at the root entry point to your application: try { Application.run() } catch(MathException e) { u.translate(e) } This has the same effect, but I think it's a better pattern for developers in general. The functionality for `u.translate(e)` can be provided in a separate module. You can do more than just translate the exception. Move it to a central logging server, etc. I also think makes CM look "Sharper" by advertising the above usage pattern, although everyone knows it's fairly amazing as is. Cheers, Ole On 12/24/2015 08:06 AM, Gilles wrote:
Hi Ole. At this point in time, there are still incompatible views on the purpose of an "exception framework" in the context of a library like CM. Perhaps you could restate your proposal (on another thread?), and ask explicitly if people agree with the principle. If in the affirmative, you should then open an issue on JIRA and prepare a patch for the master branch, in order to ensure that there is no hidden problem. Thanks, Gilles --------------------------------------------------------------------- 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
