Hi.
> >> 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.
I tend to agree because this is my use-case: Nothing should go wrong and if
something does, there is nothing to do to recover at runtime; it's a bug
which the stack trace should help locating.
But CM, as a low-level component, should not assume how it will be used, and
some use-cases may want to rely on precise documentation.
> >> 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...
One issue was whether localization should be done in a low-level component.
When I proposed that exceptions maintain a state (which you don't like
either), it was because so, it *is* possible to delegate formatting and
localization to a higher level of code (because the variable parts of the
message are encapsulated in the instance fields).
>
> >> 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.
Of course, this the logical decision, given your assumptions. But if you
take the CM requirements (localization), then it becomes a burden to keep in
sync with all the various standard exceptions. [In fact, those exceptions
expressing different type of failures (illegal argument, illegal state, null
pointer, ...) should have been interfaces.]
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
