On 1 February 2011 13:52, <luc.maison...@free.fr> 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
discussions...
>> 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 <gil...@harfang.homelinux.org> 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.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
