commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <>
Subject Re: svn commit: r1164570 - in /commons/proper/math/trunk/src: main/java/org/apache/commons/math/exception/ main/java/org/apache/commons/math/exception/util/ site/xdoc/
Date Sat, 03 Sep 2011 08:43:13 GMT
Le 02/09/2011 22:46, Gilles Sadowski a écrit :
> Hi Luc.
>> Modified: commons/proper/math/trunk/src/main/java/org/apache/commons/math/exception/util/
>> URL:
>> ==============================================================================
>> --- commons/proper/math/trunk/src/main/java/org/apache/commons/math/exception/util/
>> +++ commons/proper/math/trunk/src/main/java/org/apache/commons/math/exception/util/
Fri Sep  2 15:07:16 2011
>> @@ -30,4 +30,10 @@ public interface ExceptionContextProvide
>>        * @return a reference to the exception context.
>>        */
>>       ExceptionContext getContext();
>> +
>> +    /** Get a reference to the exception to which the context relates.
>> +     * @return a reference to the exception to which the context relates
>> +     */
>> +    Throwable getException();
>> +
>>   }
> This new method does not seem to be used inside CM. For what do you need it?

I need it for a library that uses Apache Commons Math (it is for 
Orekit). In this library, some errors are directly at Orekit level, some 
are triggered when Orekit code is called by Apache Commons Math (root 
solvers, ODE ...) and some are triggered directly by Apache Commons Math 
(dimensions mismatch, preconditions ...).

In the first two case, there are some specific Orekit exceptions. In the 
third case, I have to wrap the Apache Commons Math exception and be able 
to recover it. In fact I need the two parts: the context and the 
exception. the context is used for building messages for end users, the 
exception is used to track stack path in debuggers for developers.

For a long time, I have used the common top level exceptions from our 
hierarchy MathException and MathRuntimeException and had for example 
constructors like:

   public OrekitException(MathException e) {
      pattern = e.getPattern();
      arguments = e.getArguments();

   public OrekitException(MathUserException e) {
      pattern = e.getPattern();
      arguments = e.getArguments();

We have removed these common parts and now all exceptions are different. 
Some extend IllegalArgumentException, some  extend IllegalStateException 
... It would be a nightmare to be forced to declare *all* these 
exceptions when I need to embed them. Fortunately, we have a common 
interface for them, which is ExceptionContextProvider.

So I basically replaced the two constructors above with:

   public OrekitException(ExceptionContextProvider p) {
      context = p.getContext();

> I'm asking because it does not seem to be a good fit there: Although the
> "ExceptionContextProvider" is implemented by exceptions, it is not strictly
> true that any implementation of "ExceptionContextProvider" would be able to
> refer to an exception...

I added this method precisely because the separate 
ExceptionContextProvider and Throwable hierarchies are fine. They do not 
represent the same notion, but are linked together. For now, the 
exception and the context provider *are* the exact same object, but I 
preferred not to use that and not to use a cast. One thing however that 
seemed logicl to me is that an exception context provider provides a 
context which is linked to an exception. An exception context without an 
exception seemed illogical.

If linking directly the provider with the exception is a too tight link, 
we could put the method getException() in the ExceptionContext itself 
rather than in the provider. This would still suit my needs as I could 
call getContext().getException() rather than directly getException. It 
is simple to implement since the context is built behind the scenes when 
the exception is built, so we can add a Throwable argument to the 
context constructor.

What do you think ?

> Moreover, if only exceptions can implement "ExceptionContextProvider", then
> this method:
> ---CUT---
> public Throwable getException() {
>     return this;
> }
> ---CUT---
> is pretty much redundant since it'll hand you the object which you already
> have.
> Or did I miss something?
> Best,
> Gilles
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message