commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <>
Subject Re: [math] UnexpectedNegativeIntegerException
Date Wed, 05 Sep 2012 22:38:53 GMT
On Wed, Sep 05, 2012 at 08:16:34PM +0200, Luc Maisonobe wrote:
> Le 05/09/2012 19:09, Ole Ersoy a écrit :
> > Hi Gilles,
> > 
> > On 09/04/2012 06:48 PM, Gilles Sadowski wrote:
> >> Hello.
> >>
> >> There are ideas that sound good we experiment with them within a limited
> >> framework (like a course on programming, for example); and then become a
> >> nightmare when you find yourself constantly trying to get around them.
> >> I mean that a design idea might look nice, and only when you are long way
> >> into implementing the consequences of that idea, you discover that it was
> >> not such a good one after all.
> > 
> > Been there :)
> > 
> >>> As a user of commons math I think it would be great if a each exception
> >>> mapped to a "One of a kind problem". So instead of having a
> >>> NegativeIntegerException, which is generic and could be used in a lot
> >>> of places, have SuperDuperOptimizerNegativeIntegerException, which is
> >>> only thrown in one place.
> >>>
> >>> Is this possible?
> >>
> >> Possible, it is. But have you imagined how many different exceptions that
> >> would entail?
> > 
> > I really did and thought maybe this is just crazy.
> > 
> >> Currently, there are more than 1000 "throw" statements in CM.
> >>
> >> My position is to have a mapping between "exception type" and "problem
> >> kind"; your suggestion looks like a mapping between "exception type" and
> >> "problem location".
> > 
> > I would rephrase my suggestion as a mapping between "exception type" and
> > "solution".  So if you know the exception type, you immediately know how
> > to provide options to the person responsible for the operation.
> >  
> >> Besides the drawback of an enormous increase of the number of classes,
> >> tying
> >> the exception to its place of use is redundant with the information
> >> already
> >> provided in the stack trace.
> > 
> > I agree.  I really meant "Solution".  It seems that we are already at
> > the point where exceptions should provide parameters from the instance
> > that threw the exception for the purpose of UI display, logging, etc.,
> > so if it's going to be that specific, then why not make it so specific
> > that it can only have one possible message and one set of solutions
> > specific to the context.
> > 
> >>
> >> [One of the most useful rules in programming is code reuse; it would be a
> >> waste of a programmer's time to create a new exception class just because
> >> it is intended to be thrown from a different place.]
> > 
> > I agree.
> > 
> > The main reason I threw my 2 cents in is because it seem like the design
> > of the exceptions was getting very complicated with the inclusion of
> > localization, unrolling of diagnostic contexts (Not sure if I said that
> > right...), etc. and there has to be a simpler way.
> > 
> > For example it seems like localization should be worried about after you
> > catch the exception and you know what to do with it.  I like that
> > localization is part of commons math, but to me it seems that it should
> > be a utility that can be used for message display once an action has
> > been decided upon post catching the exception.  Right now it seems that
> > localization has become a constraint on exception design.
> Looking at localization after the exception has been caught is possible
> only once you are sure all exceptions are unique (which is the core of
> your proposal). As our use and reuse exceptions everywhere, this is
> simply not possible.

I'm not so sure that every exception must have a single use. In fact, it
may be a quite appropriate usage of your request: Assuming that the
"getPatterns" and "getArguments" methods are available, what we do now
(formatting of the exception message) inside the "getMessage" of
"ExceptionContext" can be done after catching the exception:

 try {
   // Computations that can throw CM exceptions.
 } catch (MathRuntimeException e) {
   if (allIsLost) {
     // Build a localized message.
     final List<LocalizedFormats> patterns = e.getContext().getPatterns();
     final List<Object[]> args = e.getContext().getArguments;
     final String msg = TranslatorService.buildMessage(patterns,

     // Rethrow.
     throw new UserException(msg);

   // Handle the exception at this level.

[The "TranslatorService" would not be part of CM, but a side project
only depending on a "MessagePattern" enum provided by CM.]

Did I overlook something obvious (e.g. a "nice idea that is not so"...)?

What I find nice (caveat notwithstanding) is that it would take the load of
localization off CM. ["LocalizedFormats" just needs to be a "MessagePattern"
without being "Localizable"]. We'd just keep the formatting of the default
(English) message.


P.S. This is _not_ a proposal. ;-)

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message