commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Colebourne <>
Subject Re: [all][math] Help wanted with exceptions API design
Date Tue, 01 Feb 2011 14:39:06 GMT
On 1 February 2011 13:52,  <> wrote:
>> I have a small hierarchy of exceptions that attempts to capture some
>> key problems that may occur. The problem I found was that as I
>> refactored code, the exceptions listed in Javadoc quickly became
>> inaccurate. As a result, I've started converting many exceptions to
>> the parent CalendricalException. If a method returns a subclasses of
>> CalEx then thats fine and provides more info. But documenting it as
>> returning the subclass is way too much work for limited gain.
> So users who want to extract data put in their code statements along
> the line of : if (e instanceof subClassException)  { ... } ?

You can always catch a sub-exception even if the documentation only
says it throws the super-exception.

>> Info on failure simply needs a good message in English.
> No. Some people do not read English at all. In many systems a strong
> requirement is that every message users can see must be localizable.
> Localizing a message that has variable parts (numerical values,
> strings, booleans) after the message has been built on a top level layer
> is impossible.

I don't believe that the cost is worth it. But thats a project
decision. One impact of the cost is interminable exception

>> to diagnose the problem in a stack trace.
> No. End users are not always developers, or they may have no access to the
> source code, or they may not know the architecture of the applications,
> they may even not known Commons Math is used behind the scenes in a low
> level layer. Stack trace are not for users and we should not rely on them.

A good message was the point, and should be usable without the stack trace.

On 1 February 2011 13:47, Gilles Sadowski <> wrote:
> Here we (in CM) arrived to the consensus that it would be simpler to have
> all our exceptions rooted at "RuntimeException". Unfortunately, that makes
> us depart from the other standard exceptions. For example, we created a
> "MathIllegalArgumentException" that is not a subclass of the standard
> "IllegalArgumentException" although it is semantically equivalent.
> This decision was indeed partly due to the complication induced by the
> localization "framework" (to avoid code duplication).

I maintain that IllegalArgumentException should be used as is.
Anything else is rather confusing, and a "it avoids code duplication"
argument isn't good enough for me.


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

View raw message