unroll behavior in the ExceptionSelector

[ju...@basf-it-services.com]

Hi,

we propose to change the possible values for attribute "unroll" in the
configuration entries of the new ExceptionSelector from "true" and "false"
to "no", "cause" and "rootcause". This would make it possible to not only
consider a nested exception, but to extract the root exception from
multi-wrapped exceptions.
In other words the decision would be to call method getCause() or
getRootCause() of class ExceptionUtils, that is used inside the selector
even yet.

Example:
Imagine we have wrapped exceptions ProcessingException ?
InvocationTargetException ? NullpointerException. Currently the
ExceptionSelector is only able to consider the ProcessingException and the
InvocationTargetException by:
<map:selector name="exception" class="...">
             <exception name="exc1" class="ProcessingException"/>
             <exception name="exc2" class="InvocationTargetException"
unroll="true"/>
</map:selector>
Our approach would also allow to extract the root cause by:
<map:selector name="exception" class="...">
             <exception name="exc1" class="ProcessingException"/>
             <exception name="exc2" class="InvocationTargetException"
unroll="cause"/>
             <exception name="exc2" class="NullpointerException" unroll
="rootcause"/>
</map:selector>

What do you think about such a change, does it make sense?

Regards, Bjoern (bluetkemeier@s-und-n.de)
and Jürgen.

Re: unroll behavior in the ExceptionSelector

[Sylvain Wallez <sy...@anyware-tech.com>]

juergen.seitz@basf-it-services.com wrote:

>Hi,
>
>we propose to change the possible values for attribute "unroll" in the
>configuration entries of the new ExceptionSelector from "true" and "false"
>to "no", "cause" and "rootcause". This would make it possible to not only
>consider a nested exception, but to extract the root exception from
>multi-wrapped exceptions.
>In other words the decision would be to call method getCause() or
>getRootCause() of class ExceptionUtils, that is used inside the selector
>even yet.
>
>Example:
>Imagine we have wrapped exceptions ProcessingException ?
>InvocationTargetException ? NullpointerException. Currently the
>ExceptionSelector is only able to consider the ProcessingException and the
>InvocationTargetException by:
><map:selector name="exception" class="...">
>             <exception name="exc1" class="ProcessingException"/>
>             <exception name="exc2" class="InvocationTargetException"
>unroll="true"/>
></map:selector>
>Our approach would also allow to extract the root cause by:
><map:selector name="exception" class="...">
>             <exception name="exc1" class="ProcessingException"/>
>             <exception name="exc2" class="InvocationTargetException"
>unroll="cause"/>
>             <exception name="exc2" class="NullpointerException" unroll
>="rootcause"/>
></map:selector>
>
>What do you think about such a change, does it make sense?
>

I don't like it much, as the root exception may not have an attached 
type definition. In the main Cocoon sitemap, the last configuration item 
is :
     <exception class="java.lang.Throwable" unroll="true"/>

This has the effect to unroll exceptions as much as possible until we 
find one that has an associated type. That way, you are sure you will 
get the type associated to one of the configured exceptions, whatever 
its position in the exception chain.

Does this fit your need ?

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }