[all][math] Help wanted with exceptions API design

classic Classic list List threaded Threaded
48 messages Options
123
Reply | Threaded
Open this post in threaded view
|

[all][math] Help wanted with exceptions API design

Phil Steitz
We are in process of redesigning our exceptions hierarchy in [math]
and we could use some input / perspective from other Commons
community members.  Thanks in advance for your feedback and perspective.

The most recent attempt at agreeing on design principles is [1] and
I have tried to document the points of agreement in a section that I
just added to the [math] Developer's Guide [2] (it will take a few
hours for this to make it to the live site.  The source xdoc is in
trunk/src/site/xdoc/developers.xml)

The JIRA issue [3] referenced in [1] calls out a specific point on
which we are trying to gain consensus in a specific example.

The currently defined exceptions in [math] can be found in the
top-level package and .exceptions.  Those in the top-level have at
this point been deprecated.

Thanks!

Phil

[1] http://markmail.org/message/csgdloie6uv33yua
[2] http://commons.apache.org/math/developers.html
[3] https://issues.apache.org/jira/browse/MATH-487

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all][math] Help wanted with exceptions API design

jodastephen
I can give some feedback based on JSR-310.

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.

For [math], simply documenting MathException is sufficient.
MathRuntimeException, is unecessary as a name when all exceptions are
runtime (the correct decision).

More generally, an obsession with having every piece of exception data
available via a variable is generally unhelpful. It simply leads to
large unmaintainable hierarchies and arguments like this one. It is
very rare to need the data. [math] is suffering because of localizing
exception, which IMO is a big mistake and the cause of a lot of the
issues.

In general, exceptions are for two purposes - info on failure and to
trap for retry.

Info on failure simply needs a good message in English. No data is
required, although important (certainly not all!) pieces might be
captured.

Trap for retry errors should be rare if present at all. I would much
prefer to see a proper result object which everyone is forced to check
to describe the success or failure of something that might be retried.

In general though, the main advice is to keep it simple. People rarely
use exception hierarchies. Mostly they want the message to be readable
to diagnose the problem in a stack trace.

Finally, use the standard exceptions and patterns. IllegalArgumentEx
for example (which won't extend from MathEx, so does require separate
documentation). As in the guide, IllArgEx is for preconditions
mentioned in Javadoc or reasonably related to them, not general
calculation issues.

Similarly, look at the standard JDK executor framework
(ExecutionException) to understand the necessity to wrap callbacks.

Stephen


On 1 February 2011 00:38, Phil Steitz <[hidden email]> wrote:

> We are in process of redesigning our exceptions hierarchy in [math]
> and we could use some input / perspective from other Commons
> community members.  Thanks in advance for your feedback and perspective.
>
> The most recent attempt at agreeing on design principles is [1] and
> I have tried to document the points of agreement in a section that I
> just added to the [math] Developer's Guide [2] (it will take a few
> hours for this to make it to the live site.  The source xdoc is in
> trunk/src/site/xdoc/developers.xml)
>
> The JIRA issue [3] referenced in [1] calls out a specific point on
> which we are trying to gain consensus in a specific example.
>
> The currently defined exceptions in [math] can be found in the
> top-level package and .exceptions.  Those in the top-level have at
> this point been deprecated.
>
> Thanks!
>
> Phil
>
> [1] http://markmail.org/message/csgdloie6uv33yua
> [2] http://commons.apache.org/math/developers.html
> [3] https://issues.apache.org/jira/browse/MATH-487
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all][math] Help wanted with exceptions API design

Gilles Sadowski
Hi.

On Tue, Feb 01, 2011 at 11:38:04AM +0000, Stephen Colebourne wrote:
> I can give some feedback based on JSR-310.

Thank you for sharing ideas.

> 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.
>
> For [math], simply documenting MathException is sufficient.
> MathRuntimeException, is unecessary as a name when all exceptions are
> runtime (the correct decision).

Agreed.

> More generally, an obsession with having every piece of exception data
> available via a variable is generally unhelpful. It simply leads to
> large unmaintainable hierarchies and arguments like this one. It is
> very rare to need the data. [math] is suffering because of localizing
> exception, which IMO is a big mistake and the cause of a lot of the
> issues.

There are 2 independent issues here. As a low-level component, CM cannot
assume how it's failure are going to be reported. Having exception data
programmatically acessible allows the application developers to format the
failure message as they wish.

On the localization issue, I was in agreement with your view. Unfortunately,
it seemed to have been a requirement from one of the big users of CM.

There was a long thread where we had been discussing all this:
  http://markmail.org/message/emh7nr5nuultgkx4

> In general, exceptions are for two purposes - info on failure and to
> trap for retry.
>
> Info on failure simply needs a good message in English. No data is
> required, although important (certainly not all!) pieces might be
> captured.
>
> Trap for retry errors should be rare if present at all. I would much
> prefer to see a proper result object which everyone is forced to check
> to describe the success or failure of something that might be retried.

My conviction is that a true "retry" will never happen in CM.

> In general though, the main advice is to keep it simple. People rarely
> use exception hierarchies.

Although you said that it saved your day to have a parent exception ;-).

> Mostly they want the message to be readable
> to diagnose the problem in a stack trace.

For me too, it's the most common use.

> Finally, use the standard exceptions and patterns. IllegalArgumentEx
> for example (which won't extend from MathEx, so does require separate
> documentation). As in the guide, IllArgEx is for preconditions
> mentioned in Javadoc or reasonably related to them, not general
> calculation issues.

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).

> Similarly, look at the standard JDK executor framework
> (ExecutionException) to understand the necessity to wrap callbacks.

Fortunately, we don't have to deal with such complex code flow.


Best regards,
Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all][math] Help wanted with exceptions API design

Luc Maisonobe
In reply to this post by Phil Steitz

----- "Stephen Colebourne" <[hidden email]> a écrit :

> I can give some feedback based on JSR-310.
>
> 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)  { ... } ?

>
> For [math], simply documenting MathException is sufficient.
> MathRuntimeException, is unecessary as a name when all exceptions are
> runtime (the correct decision).
>
> More generally, an obsession with having every piece of exception
> data
> available via a variable is generally unhelpful. It simply leads to
> large unmaintainable hierarchies and arguments like this one. It is
> very rare to need the data. [math] is suffering because of localizing
> exception, which IMO is a big mistake and the cause of a lot of the
> issues.

The localization part and the hierarchy are two completely different topics.

>
> In general, exceptions are for two purposes - info on failure and to
> trap for retry.

Yes.

>
> 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.

> No data is
> required, although important (certainly not all!) pieces might be
> captured.
>
> Trap for retry errors should be rare if present at all. I would much
> prefer to see a proper result object which everyone is forced to
> check
> to describe the success or failure of something that might be
> retried.

Agreed.

>
> In general though, the main advice is to keep it simple. People
> rarely
> use exception hierarchies. Mostly they want the message to be
> readable

Yes.

> 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.

>
> Finally, use the standard exceptions and patterns. IllegalArgumentEx
> for example (which won't extend from MathEx, so does require separate
> documentation). As in the guide, IllArgEx is for preconditions
> mentioned in Javadoc or reasonably related to them, not general
> calculation issues.

Yes.

>
> Similarly, look at the standard JDK executor framework
> (ExecutionException) to understand the necessity to wrap callbacks.

Thanks, we'll have a look at it.

Luc

>
> Stephen
>
>
> On 1 February 2011 00:38, Phil Steitz <[hidden email]> wrote:
> > We are in process of redesigning our exceptions hierarchy in [math]
> > and we could use some input / perspective from other Commons
> > community members.  Thanks in advance for your feedback and
> perspective.
> >
> > The most recent attempt at agreeing on design principles is [1] and
> > I have tried to document the points of agreement in a section that
> I
> > just added to the [math] Developer's Guide [2] (it will take a few
> > hours for this to make it to the live site.  The source xdoc is in
> > trunk/src/site/xdoc/developers.xml)
> >
> > The JIRA issue [3] referenced in [1] calls out a specific point on
> > which we are trying to gain consensus in a specific example.
> >
> > The currently defined exceptions in [math] can be found in the
> > top-level package and .exceptions.  Those in the top-level have at
> > this point been deprecated.
> >
> > Thanks!
> >
> > Phil
> >
> > [1] http://markmail.org/message/csgdloie6uv33yua
> > [2] http://commons.apache.org/math/developers.html
> > [3] https://issues.apache.org/jira/browse/MATH-487
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all][math] Help wanted with exceptions API design

jodastephen
On 1 February 2011 13:52,  <[hidden email]> 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 <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all][math] Help wanted with exceptions API design

Gilles Sadowski
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 <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [all][math] Help wanted with exceptions API design

Gary Gregory
In reply to this post by Luc Maisonobe
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]
> Sent: Tuesday, February 01, 2011 08:52
> To: Commons Developers List
> Subject: Re: [all][math] Help wanted with exceptions API design
>
>
<...>
> > > The currently defined exceptions in [math] can be found in the
> > > top-level package and .exceptions.  Those in the top-level have at
> > > this point been deprecated.

Don't package your exceptions in a package called ".exceptions". That is very odd. The exception should be defined where they are used.

As I and others have suggested: reuse existing stock exceptions. Only create exceptions classes if you must.

If you consider creating an exception, especially in a hierarchy, think: why would I want to CATCH this exception as opposed to a superclass?

Gary

> > >
> > > Thanks!
> > >
> > > Phil
> > >
> > > [1] http://markmail.org/message/csgdloie6uv33yua
> > > [2] http://commons.apache.org/math/developers.html
> > > [3] https://issues.apache.org/jira/browse/MATH-487
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all][math] Help wanted with exceptions API design

Ted Dunning
In reply to this post by Gilles Sadowski
Uhh...

What about IOException?  I was under the impression that people use that ALL
the time.  The specializations EOFException and FileNotFoundException are
very handy when you want the specific case and the general version is nice
when you want to trap and possibly wrap all of the exceptions in one go.

On Tue, Feb 1, 2011 at 5:47 AM, Gilles Sadowski <
[hidden email]> wrote:

> > In general though, the main advice is to keep it simple. People rarely
> > use exception hierarchies.
>
> Although you said that it saved your day to have a parent exception ;-).
>
Reply | Threaded
Open this post in threaded view
|

Re: [all][math] Help wanted with exceptions API design

Jörg Schaible
In reply to this post by Phil Steitz
Hi,

Phil Steitz wrote:

> We are in process of redesigning our exceptions hierarchy in [math]
> and we could use some input / perspective from other Commons
> community members.  Thanks in advance for your feedback and perspective.
>
> The most recent attempt at agreeing on design principles is [1] and
> I have tried to document the points of agreement in a section that I
> just added to the [math] Developer's Guide [2] (it will take a few
> hours for this to make it to the live site.  The source xdoc is in
> trunk/src/site/xdoc/developers.xml)
>
> The JIRA issue [3] referenced in [1] calls out a specific point on
> which we are trying to gain consensus in a specific example.
>
> The currently defined exceptions in [math] can be found in the
> top-level package and .exceptions.  Those in the top-level have at
> this point been deprecated.

Has anyone of you considered the usage of an exception context? We introduce
this with lang3 (http://commons.apache.org/lang/api-3.0-
beta/org/apache/commons/lang3/exception/ExceptionContext.html) and it
basically adds a map with key/value pairs to the exception itself.

This concept has worked out quite nicely especially in situations where code
can nest deeply in conjunction with user-provided code that make calls in
the core functionality again.

The nice part is that you can add information at each position that can
provide useful information (assuming MathException implements this
interface):

try {
  geneticAlg.evolve(pop, cond)
} catch (MathException ex) {
  ex.addValue("Initial Population Size", pop.getPopulationSize());
  throw ex;
}

Additionally this approach tends to shorten the prosa, because the algorithm
might throw:

if (population.getPopulationSize() ==  0) {
  MathException ex = new MathException("Population died");
  ex.addValue("Iterations", getGenerationsEvolved());
  throw ex;
}

instead of:

if (population.getPopulationSize() ==  0) {
  throw new MathException("Population died after " + getGenerationsEvolved()
+ " generations, starting with " + initialSizeKeptSomewhere + "
chromosomes");
}

Even if you keep i18n, it is easier to translate the short messages and the
param keys instead of the full text ;-)

... and remember, you can add the context interface to various exceptions,
you don't have to maintain a hierarchy.
... and your users can add values also that are interesting e.g. for their
stop condition without wrapping or inventing new exceptions.

- Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all][math] Help wanted with exceptions API design

Luc Maisonobe
Le 01/02/2011 18:22, Jörg Schaible a écrit :

> Hi,
>
> Phil Steitz wrote:
>
>> We are in process of redesigning our exceptions hierarchy in [math]
>> and we could use some input / perspective from other Commons
>> community members.  Thanks in advance for your feedback and perspective.
>>
>> The most recent attempt at agreeing on design principles is [1] and
>> I have tried to document the points of agreement in a section that I
>> just added to the [math] Developer's Guide [2] (it will take a few
>> hours for this to make it to the live site.  The source xdoc is in
>> trunk/src/site/xdoc/developers.xml)
>>
>> The JIRA issue [3] referenced in [1] calls out a specific point on
>> which we are trying to gain consensus in a specific example.
>>
>> The currently defined exceptions in [math] can be found in the
>> top-level package and .exceptions.  Those in the top-level have at
>> this point been deprecated.
>
> Has anyone of you considered the usage of an exception context? We introduce
> this with lang3 (http://commons.apache.org/lang/api-3.0-
> beta/org/apache/commons/lang3/exception/ExceptionContext.html) and it
> basically adds a map with key/value pairs to the exception itself.
>
> This concept has worked out quite nicely especially in situations where code
> can nest deeply in conjunction with user-provided code that make calls in
> the core functionality again.
>
> The nice part is that you can add information at each position that can
> provide useful information (assuming MathException implements this
> interface):

We didn't consider that :-(
It seems very interesting to me.

What do other think about it ?

Luc

>
> try {
>   geneticAlg.evolve(pop, cond)
> } catch (MathException ex) {
>   ex.addValue("Initial Population Size", pop.getPopulationSize());
>   throw ex;
> }
>
> Additionally this approach tends to shorten the prosa, because the algorithm
> might throw:
>
> if (population.getPopulationSize() ==  0) {
>   MathException ex = new MathException("Population died");
>   ex.addValue("Iterations", getGenerationsEvolved());
>   throw ex;
> }
>
> instead of:
>
> if (population.getPopulationSize() ==  0) {
>   throw new MathException("Population died after " + getGenerationsEvolved()
> + " generations, starting with " + initialSizeKeptSomewhere + "
> chromosomes");
> }
>
> Even if you keep i18n, it is easier to translate the short messages and the
> param keys instead of the full text ;-)
>
> ... and remember, you can add the context interface to various exceptions,
> you don't have to maintain a hierarchy.
> ... and your users can add values also that are interesting e.g. for their
> stop condition without wrapping or inventing new exceptions.
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [all][math] Help wanted with exceptions API design

Gary Gregory
> -----Original Message-----
> From: Luc Maisonobe [mailto:[hidden email]]
> Sent: Tuesday, February 01, 2011 14:07
> To: Commons Developers List
> Subject: Re: [all][math] Help wanted with exceptions API design
>
> Le 01/02/2011 18:22, Jörg Schaible a écrit :
> > Hi,
> >
> > Phil Steitz wrote:
> >
> >> We are in process of redesigning our exceptions hierarchy in [math]
> >> and we could use some input / perspective from other Commons
> >> community members.  Thanks in advance for your feedback and perspective.
> >>
> >> The most recent attempt at agreeing on design principles is [1] and
> >> I have tried to document the points of agreement in a section that I
> >> just added to the [math] Developer's Guide [2] (it will take a few
> >> hours for this to make it to the live site.  The source xdoc is in
> >> trunk/src/site/xdoc/developers.xml)
> >>
> >> The JIRA issue [3] referenced in [1] calls out a specific point on
> >> which we are trying to gain consensus in a specific example.
> >>
> >> The currently defined exceptions in [math] can be found in the
> >> top-level package and .exceptions.  Those in the top-level have at
> >> this point been deprecated.
> >
> > Has anyone of you considered the usage of an exception context? We
> introduce
> > this with lang3 (http://commons.apache.org/lang/api-3.0-
> > beta/org/apache/commons/lang3/exception/ExceptionContext.html) and it
> > basically adds a map with key/value pairs to the exception itself.
> >
> > This concept has worked out quite nicely especially in situations where
> code
> > can nest deeply in conjunction with user-provided code that make calls in
> > the core functionality again.
> >
> > The nice part is that you can add information at each position that can
> > provide useful information (assuming MathException implements this
> > interface):
>
> We didn't consider that :-(
> It seems very interesting to me.
>
> What do other think about it ?

It /does/ look interesting for sure.

Gary

>
> Luc
>
> >
> > try {
> >   geneticAlg.evolve(pop, cond)
> > } catch (MathException ex) {
> >   ex.addValue("Initial Population Size", pop.getPopulationSize());
> >   throw ex;
> > }
> >
> > Additionally this approach tends to shorten the prosa, because the
> algorithm
> > might throw:
> >
> > if (population.getPopulationSize() ==  0) {
> >   MathException ex = new MathException("Population died");
> >   ex.addValue("Iterations", getGenerationsEvolved());
> >   throw ex;
> > }
> >
> > instead of:
> >
> > if (population.getPopulationSize() ==  0) {
> >   throw new MathException("Population died after " +
> getGenerationsEvolved()
> > + " generations, starting with " + initialSizeKeptSomewhere + "
> > chromosomes");
> > }
> >
> > Even if you keep i18n, it is easier to translate the short messages and
> the
> > param keys instead of the full text ;-)
> >
> > ... and remember, you can add the context interface to various
> exceptions,
> > you don't have to maintain a hierarchy.
> > ... and your users can add values also that are interesting e.g. for
> their
> > stop condition without wrapping or inventing new exceptions.
> >
> > - Jörg
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all][math] Help wanted with exceptions API design

Gilles Sadowski
In reply to this post by Gary Gregory
> > > > The currently defined exceptions in [math] can be found in the
> > > > top-level package and .exceptions.  Those in the top-level have at
> > > > this point been deprecated.
>
> Don't package your exceptions in a package called ".exceptions". That is very odd.

Why?

> The exception should be defined where they are used.

What do you do for exceptions that are used in several classes and several
packages?

> As I and others have suggested: reuse existing stock exceptions. Only create exceptions classes if you must.

Depending on the requirements, the exceptions we created may be more
convenient.

> If you consider creating an exception, especially in a hierarchy, think: why would I want to CATCH this exception as opposed to a superclass?

I don't agree because I don't consider from that stand-point. IMHO, the
exception is useful if it conveys a problem as specifically as possible.
The caller is free to catch, or not, whatever he likes.


Best,
Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [all][math] Help wanted with exceptions API design

Gary Gregory
> -----Original Message-----
> From: Gilles Sadowski [mailto:[hidden email]]
> Sent: Tuesday, February 01, 2011 18:16
> To: [hidden email]
> Subject: Re: [all][math] Help wanted with exceptions API design
>
> > > > > The currently defined exceptions in [math] can be found in the
> > > > > top-level package and .exceptions.  Those in the top-level have at
> > > > > this point been deprecated.
> >
> > Don't package your exceptions in a package called ".exceptions". That is
> very odd.
>
> Why?
>
> > The exception should be defined where they are used.
>
> What do you do for exceptions that are used in several classes and several
> packages?

Here is a probably too simple example:

com.example defines IOException
com.example.input uses IOException
com.example.output uses IOException

>
> > As I and others have suggested: reuse existing stock exceptions. Only
> create exceptions classes if you must.
>
> Depending on the requirements, the exceptions we created may be more
> convenient.
>
> > If you consider creating an exception, especially in a hierarchy, think:
> why would I want to CATCH this exception as opposed to a superclass?
>
> I don't agree because I don't consider from that stand-point. IMHO, the
> exception is useful if it conveys a problem as specifically as possible.
> The caller is free to catch, or not, whatever he likes.
>
>
> Best,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all][math] Help wanted with exceptions API design

Gilles Sadowski
In reply to this post by Luc Maisonobe
> > [...]
> >
> > Has anyone of you considered the usage of an exception context? We introduce
> > this with lang3 (http://commons.apache.org/lang/api-3.0-
> > beta/org/apache/commons/lang3/exception/ExceptionContext.html) and it
> > basically adds a map with key/value pairs to the exception itself.
> >
> > This concept has worked out quite nicely especially in situations where code
> > can nest deeply in conjunction with user-provided code that make calls in
> > the core functionality again.
> >
> > The nice part is that you can add information at each position that can
> > provide useful information (assuming MathException implements this
> > interface):
>
> We didn't consider that :-(
> It seems very interesting to me.
>
> What do other think about it ?

I'm not so enthusiastic: Right now I don't see how it will improve the
current situation in CM. An example might help me understand the advantages.
However I'm not really happy with the current localization scheme, so I
would not be against trying something else if it can be improve that way.
[One nice thing might be that we would not be limited to one "general" and
one "specific" problem description.
One not so nice thing is that we wouldn't have different exception types,
each with a specific interface.]

> > [...]

> >
> > ... and remember, you can add the context interface to various exceptions,
> > you don't have to maintain a hierarchy.
> > ... and your users can add values also that are interesting e.g. for their
> > stop condition without wrapping or inventing new exceptions.

Do I understand correctly that, if we go down that road, there would only be
a single exception (every failure will raise the same exception)?
If the aim is only for printing the whole context, it is indeed very
flexible (adding a lot of info is easy). But if the caller wants to trap and
act on a particular condition (a part of the context), isn't it more
difficult than catching a specific exception?
Examples are really needed to figure out the actual use-cases for CM and
users of CM.


Regards,
Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all][math] Help wanted with exceptions API design

Gilles Sadowski
In reply to this post by Gary Gregory
On Tue, Feb 01, 2011 at 11:27:26PM +0000, Gary Gregory wrote:

> > -----Original Message-----
> > From: Gilles Sadowski [mailto:[hidden email]]
> > Sent: Tuesday, February 01, 2011 18:16
> > To: [hidden email]
> > Subject: Re: [all][math] Help wanted with exceptions API design
> >
> > > > > > The currently defined exceptions in [math] can be found in the
> > > > > > top-level package and .exceptions.  Those in the top-level have at
> > > > > > this point been deprecated.
> > >
> > > Don't package your exceptions in a package called ".exceptions". That is
> > very odd.
> >
> > Why?
> >
> > > The exception should be defined where they are used.
> >
> > What do you do for exceptions that are used in several classes and several
> > packages?
>
> Here is a probably too simple example:
>
> com.example defines IOException
> com.example.input uses IOException
> com.example.output uses IOException

Well, I don't see that as obviously better than storing all exceptions in an
"exception" package. I find the latter tidier.

The problems arises when one thinks that some exception is only needed in
one package:
  com.example.foo uses and defines FooException
Then one discovers
  com.example.bar also uses FooException

Add a few more exceptions and soon people are searching the exceptions
definitions all over the place, or create new ones that duplicate
functionality that already exists in some other package.


Regards,
Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all][math] Help wanted with exceptions API design

Stephen Williams
In reply to this post by Gary Gregory
On 2/1/11 4:31 PM, Stephen Williams wrote:

> I know I've recently seen a great example of a library that started with generic exception classes then later changed to a
> specific hierarchy.  But I can't remember off hand which library it was...
>
> There is some low level where you just want to get back the raw exception, null pointers etc. when they are unexpected.  For
> debugging, even for an app running in the field, you want code that can capture the problem to get the actual exception, be able
> to get a stack trace, etc.  When an exception is expected, as in a parameter that is null to signal that it is not wanted for
> instance, that should be caught, interpreted, and turned into an exception that has a specific meaning.  In a lot of ways, it
> seems like the arguments for semantic web ontologies apply here in terms of assigning meaning to events.
>
> In larger apps, what I've found is that a hierarchy of exceptions is useful to A) simply code that needs to make decisions (IO
> error? Network?  Math?  Out of memory?) while B) other code needs details (exact exception, stack trace, transaction#s, etc.) to
> give detailed messages, support debugging, etc.
>
> If exceptions are generic to everything at a certain level, then it should be shared.  If it is specific because something
> relevant needs to be returned, say a particular line item in a transaction, it should be specific to the application rather than
> the error.  It can carry the more specific to the failure exception.
>
> Here are my rules, so far.  Please comment as I plan to write up a summary for myself later.
>
>     * Don't hide or lose information potentially important for debugging or application decisions.
>     * At key API layer boundaries, map all internal / low level exceptions to classes of exceptions: memory, math, bad parameters,
>       ...  Except that truly unexpected exceptions can be left to be caught in many cases.  Catching and converting all of those
>       can make debugging much harder unless stack traces are kept.
>     * Use exception hierarchies to group types when possible.
>     * Think carefully about checked vs. unchecked exceptions.  There is a particular idiom I like that makes using checked
>       exceptions ugly: In some cases, say a map/xml get method, you can simply code by passing in what to do if the value is not
>       found.  Ideally, you want to pass alternatives like: null, "", "empty", or MyException.  Unfortunately, if a method could
>       return a checked exception, it must always be caught, even if a particular call will never do so.  In this case, an
>       unchecked (i.e. not required to be caught) exception should be used, always checked by convention.
>     * High-level concept exceptions should be defined and used to improve documentation.  For example, "OutOfStock" would be a
>       reasonable exception for a 'purchase("chair")' method.
>     * Class-specific, high-level exceptions should be declared as inner classes of the class that throws them.  This is an
>       application of a more general rule on when to use inner classes to avoid class space pollution, aka "class diarrhea".
>       Defining compound or special return types, or alternatively callback signatures, as inner classes is often better also.  I
>       think of it as being object oriented at the next level up of granularity.
>
>
> Stephen
>
> On 2/1/11 3:27 PM, Gary Gregory wrote:
>>> -----Original Message-----
>>> From: Gilles Sadowski [mailto:[hidden email]]
>>> Sent: Tuesday, February 01, 2011 18:16
>>> To:[hidden email]
>>> Subject: Re: [all][math] Help wanted with exceptions API design
>>>
>>>>>>> The currently defined exceptions in [math] can be found in the
>>>>>>> top-level package and .exceptions.  Those in the top-level have at
>>>>>>> this point been deprecated.
>>>> Don't package your exceptions in a package called ".exceptions". That is
>>> very odd.
>>>
>>> Why?
>>>
>>>> The exception should be defined where they are used.
>>> What do you do for exceptions that are used in several classes and several
>>> packages?
>> Here is a probably too simple example:
>>
>> com.example defines IOException
>> com.example.input uses IOException
>> com.example.output uses IOException
>>
>>>> As I and others have suggested: reuse existing stock exceptions. Only
>>> create exceptions classes if you must.
>>>
>>> Depending on the requirements, the exceptions we created may be more
>>> convenient.
>>>
>>>> If you consider creating an exception, especially in a hierarchy, think:
>>> why would I want to CATCH this exception as opposed to a superclass?
>>>
>>> I don't agree because I don't consider from that stand-point. IMHO, the
>>> exception is useful if it conveys a problem as specifically as possible.
>>> The caller is free to catch, or not, whatever he likes.
>>>
>>>
>>> Best,
>>> Gilles
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:[hidden email]
>>> For additional commands, e-mail:[hidden email]
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:[hidden email]
>> For additional commands, e-mail:[hidden email]
>
>
> --
> Stephen D. Williams [hidden email] [hidden email] LinkedIn: http://sdw.st/in V:650-450-UNIX (8649) V:866.SDW.UNIX
> V:703.371.9362 F:703.995.0407 AIM:sdw Skype:StephenDWilliams Yahoo:sdwlignet Resume: http://sdw.st/gres Personal: http://sdw.st 
> facebook.com/sdwlig twitter.com/scienteer


--
Stephen D. Williams [hidden email] [hidden email] LinkedIn: http://sdw.st/in V:650-450-UNIX (8649) V:866.SDW.UNIX
V:703.371.9362 F:703.995.0407 AIM:sdw Skype:StephenDWilliams Yahoo:sdwlignet Resume: http://sdw.st/gres Personal: http://sdw.st 
facebook.com/sdwlig twitter.com/scienteer
Reply | Threaded
Open this post in threaded view
|

Re: [all][math] Help wanted with exceptions API design

Phil Steitz
In reply to this post by Luc Maisonobe
On 2/1/11 2:06 PM, Luc Maisonobe wrote:

> Le 01/02/2011 18:22, Jörg Schaible a écrit :
>> Hi,
>>
>> Phil Steitz wrote:
>>
>>> We are in process of redesigning our exceptions hierarchy in [math]
>>> and we could use some input / perspective from other Commons
>>> community members.  Thanks in advance for your feedback and perspective.
>>>
>>> The most recent attempt at agreeing on design principles is [1] and
>>> I have tried to document the points of agreement in a section that I
>>> just added to the [math] Developer's Guide [2] (it will take a few
>>> hours for this to make it to the live site.  The source xdoc is in
>>> trunk/src/site/xdoc/developers.xml)
>>>
>>> The JIRA issue [3] referenced in [1] calls out a specific point on
>>> which we are trying to gain consensus in a specific example.
>>>
>>> The currently defined exceptions in [math] can be found in the
>>> top-level package and .exceptions.  Those in the top-level have at
>>> this point been deprecated.
>> Has anyone of you considered the usage of an exception context? We introduce
>> this with lang3 (http://commons.apache.org/lang/api-3.0-
>> beta/org/apache/commons/lang3/exception/ExceptionContext.html) and it
>> basically adds a map with key/value pairs to the exception itself.
>>
>> This concept has worked out quite nicely especially in situations where code
>> can nest deeply in conjunction with user-provided code that make calls in
>> the core functionality again.
>>
>> The nice part is that you can add information at each position that can
>> provide useful information (assuming MathException implements this
>> interface):
> We didn't consider that :-(
> It seems very interesting to me.
>
> What do other think about it ?
>
Thanks,  Jörg!

Very nice idea.  I can see added value implementing the interface;
but unfortunately I don't see it replacing either the localization /
message framework or the hierarchy.   For reasons that others have
stated, I think that we do need a simple hierarchy.   We also need
messages that convey more than data values and I am concerned that
making sense out of key/value pairs in messages would require
brittle convention-maintaining.  Have a look at the messages that we
maintain today:
http://s.apache.org/NNd
It could be, though, that the embedded machinery might be useful and
allowing users to add data to exception messages is a powerful feature.

Phil

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all][math] Help wanted with exceptions API design

Phil Steitz
In reply to this post by jodastephen
On 2/1/11 6:38 AM, Stephen Colebourne wrote:

> I can give some feedback based on JSR-310.
>
> 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.
>
> For [math], simply documenting MathException is sufficient.
> MathRuntimeException, is unecessary as a name when all exceptions are
> runtime (the correct decision).
>
> More generally, an obsession with having every piece of exception data
> available via a variable is generally unhelpful. It simply leads to
> large unmaintainable hierarchies and arguments like this one. It is
> very rare to need the data. [math] is suffering because of localizing
> exception, which IMO is a big mistake and the cause of a lot of the
> issues.
I am not sure really that the localization framework is the cause of
significant issues for us.  It does force us to maintain the
messages and to maintain a top-level exception;  but the problems we
are having getting to consensus on design really have more to do
with a) high-level vs low-level exception concepts and b) how much
we can depend on messages (localized or not) to convey exception
context and specialization information.  We have been maintaining
the messages for 2+ years now and this has not been a big deal, IMO.
> In general, exceptions are for two purposes - info on failure and to
> trap for retry.
>
> Info on failure simply needs a good message in English. No data is
> required, although important (certainly not all!) pieces might be
> captured.
I agree with this; though the right data needs to be there.  A
canonical example is ArrayIndexOutOfBoundsException reporting the
bad index in the message.  The message should include a full
statement of the failure *at the level of abstraction appropriate to
the exception itself*
> Trap for retry errors should be rare if present at all. I would much
> prefer to see a proper result object which everyone is forced to check
> to describe the success or failure of something that might be retried.
"Retry" is not in general meaningful for our stuff, though in a
small number of cases, "try a different algorithm" or "try a
different starting point" , "adjust parameters and retry"  or
"return a special value"  (all of which [math] code does internally
at different places) can be reasonable.

What we report back to the application using [math] is that one of
the following kinds of bad things has happened

a) they have violated preconditions - they get
MathIllegalArgumentException (same semantics as anywhere else)
b) they have not violated preconditions, but a numerical problem has
occurred (while not violating stated preconditions, their problem is
not in the effective domain of the algorithm they asked [math] to
execute)
c) they have hit a bug in [math]

Of course, we have no way of distinguishing b) and c) and a fair
amount of our JIRA work really comes down to viewing b) problems as
c) problems (increasing the effective domains of our implementations).
> In general though, the main advice is to keep it simple. People rarely
> use exception hierarchies. Mostly they want the message to be readable
> to diagnose the problem in a stack trace.
Agreed.  This is why we had a very flat hierarchy through version
2.0 of [math].  Where we are having trouble gaining consensus is how
to represent specializing context information in our exceptions and
what abstractions to use to represent the shallow hierarchy that we
aim to build.  For example, in 2.0, we have a ConvergenceException,
representing the commonly occurring scenario of type b) above where
an iterative algorithm has failed to converge.  This exception is
often caught and wrapped or recovered from internally in [math].  It
has a subclass, MaxEvaluationsExceededException to represent the
common convergence failure suggested by its name.  I personally
think we should keep this exception in 3.0.  Gilles thinks that we
should replace it by more granular exceptions like
"MaxCountExceeded" or "NotFiniteNumberException" (another reason
that a sequence can fail to converge) that have nothing to do with
convergence.  We are similarly at odds regarding
"FunctionEvaluationException" a top-level exception indicating that
an error has occurred evaluating a function.
> Finally, use the standard exceptions and patterns. IllegalArgumentEx
> for example (which won't extend from MathEx, so does require separate
> documentation). As in the guide, IllArgEx is for preconditions
> mentioned in Javadoc or reasonably related to them, not general
> calculation issues.
>
> Similarly, look at the standard JDK executor framework
> (ExecutionException) to understand the necessity to wrap callbacks.
>
Thanks, Stephen!

Phil
 

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all][math] Help wanted with exceptions API design

Stephen Williams
On 2/1/11 10:04 PM, Phil Steitz wrote:

> ...
> Agreed.  This is why we had a very flat hierarchy through version
> 2.0 of [math].  Where we are having trouble gaining consensus is how
> to represent specializing context information in our exceptions and
> what abstractions to use to represent the shallow hierarchy that we
> aim to build.  For example, in 2.0, we have a ConvergenceException,
> representing the commonly occurring scenario of type b) above where
> an iterative algorithm has failed to converge.  This exception is
> often caught and wrapped or recovered from internally in [math].  It
> has a subclass, MaxEvaluationsExceededException to represent the
> common convergence failure suggested by its name.  I personally
> think we should keep this exception in 3.0.  Gilles thinks that we
> should replace it by more granular exceptions like
> "MaxCountExceeded" or "NotFiniteNumberException" (another reason
> that a sequence can fail to converge) that have nothing to do with
> convergence.  We are similarly at odds regarding
> "FunctionEvaluationException" a top-level exception indicating that
> an error has occurred evaluating a function.

One pattern that can make a lot of sense is to nest exceptions.  Or, as I've seen in C++, to put errors in a queue to generalize and
extend the errno concept.  The idea is that sometimes you want to know what an exception meant at each level of the code or at each
conceptual level.  So you could 'throw new FailedToConverge(new MaxCountExceeded)' and have a standard way to follow the path like:
ex.why().  This should result in a lot less exceptions that provide more expressiveness, plus it takes less code to do simple
handling of failures: catching a single FailedToConverge for many possible causes for instance.

The two choices for composition exceptions like this are A) nesting or B) a stack or queue.  They both have good points.

> ...
> Phil
sdw


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all][math] Help wanted with exceptions API design

Jörg Schaible-3
In reply to this post by Gilles Sadowski
Hi Gilles,

Gilles Sadowski wrote:

>> > [...]
>> >
>> > Has anyone of you considered the usage of an exception context? We
>> > introduce this with lang3 (http://commons.apache.org/lang/api-3.0-
>> > beta/org/apache/commons/lang3/exception/ExceptionContext.html) and it
>> > basically adds a map with key/value pairs to the exception itself.
>> >
>> > This concept has worked out quite nicely especially in situations where
>> > code can nest deeply in conjunction with user-provided code that make
>> > calls in the core functionality again.
>> >
>> > The nice part is that you can add information at each position that can
>> > provide useful information (assuming MathException implements this
>> > interface):
>>
>> We didn't consider that :-(
>> It seems very interesting to me.
>>
>> What do other think about it ?
>
> I'm not so enthusiastic: Right now I don't see how it will improve the
> current situation in CM. An example might help me understand the
> advantages. However I'm not really happy with the current localization
> scheme, so I would not be against trying something else if it can be
> improve that way.
> [One nice thing might be that we would not be limited to one "general" and
> one "specific" problem description.
> One not so nice thing is that we wouldn't have different exception types,
> each with a specific interface.]
>
>> > [...]
>
>> >
>> > ... and remember, you can add the context interface to various
>> > exceptions, you don't have to maintain a hierarchy.
>> > ... and your users can add values also that are interesting e.g. for
>> > their stop condition without wrapping or inventing new exceptions.
>
> Do I understand correctly that, if we go down that road, there would only
> be a single exception (every failure will raise the same exception)?

No, not at all, but your exceptions would provide all the same mechanism to
add valuable information up the stack. Have a look at the implementation of
ContextException and ContextRuntimeException. It's quite hollow, the real
code is in DefaultExceptionContext i.e. you could easily create also a
IllegalArgumentContectException derived from IllegalArgumentException. And
since the ExceptionContext is only an interface you might even replace ther
DefaultExceptionContext with something like LOcalizedExceptionContext that
has additional language support.

> If the aim is only for printing the whole context, it is indeed very
> flexible (adding a lot of info is easy). But if the caller wants to trap
> and act on a particular condition (a part of the context), isn't it more
> difficult than catching a specific exception?

As I said, keep the hierarchy, but you might be able to trim it down more
easily, because you don't have to invent a new one simply because you want
to provide an additional information.

> Examples are really needed to figure out the actual use-cases for CM and
> users of CM.

Cheers,
Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

123