commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Ersoy <ole.er...@gmail.com>
Subject Re: [math] Exception Design
Date Thu, 24 Dec 2015 23:14:42 GMT
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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
> .
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message