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/ExceptionContextProvider.java
URL:
http://svn.apache.org/viewvc/commons/proper/math/trunk/src/main/java/org/apache/commons/math/exception/util/ExceptionContextProvider.java?rev=1164570&r1=1164569&r2=1164570&view=diff
==============================================================================
---
commons/proper/math/trunk/src/main/java/org/apache/commons/math/exception/util/ExceptionContextProvider.java
(original)
+++
commons/proper/math/trunk/src/main/java/org/apache/commons/math/exception/util/ExceptionContextProvider.java
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) {
super(e);
pattern = e.getPattern();
arguments = e.getArguments();
}
public OrekitException(MathUserException e) {
super(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) {
super(p.getException());
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 ?
Luc
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: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
