commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Ersoy <>
Subject Re: [math] UnexpectedNegativeIntegerException
Date Wed, 05 Sep 2012 17:09:49 GMT
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.

- Ole

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

View raw message