cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Curran <>
Subject Re: Return Error Code Based on Pipeline Content
Date Thu, 13 Apr 2006 21:45:21 GMT
I have put another 4 hours into looking at this.

I believe that I should be using unroll="true" on the exceptions in 
order to dig down to the appropriate exception.

When I generate="notifying" my exception looks as such -

org.apache.cocoon.ProcessingException: Exception in 
StreamGenerator.generate(): java.lang.RuntimeException: 
java.lang.RuntimeException: com.dotech.util.StatusCode501Exception: 501

In this case I want access to com.dotech.util.StatusCode501Exception. My 
selectors section in components has the following.

<map:selector name="exception" 
    <exception name="process" 
class="org.apache.cocoon.ProcessingException" unroll="true"/>
    <exception name="runtime" class="java.lang.RuntimeException" 
    <exception name="e501" class="com.dotech.util.StatusCode501Exception"/>

I have my handle-errors section setup to select on these exceptions, and 
a transform outputs an indication of which <map:when> path was taken.

The expected behavior is that <map:when test="e501"> is going to be the 
chosen path, but the selected path is <map:when test="runtime"/>

I have inspected and the recursive function 
find(Throwable thr) looks like it should be digging down through 
RuntimeException to expose StatusCode501Exception.

My idea now is that in order to unroll an exception the exception must 
at some point extend 
org.apache.commons.lang.exception.NestableException, and that 
java.lang.RuntimeException obviously does not extend this exception.

I might be off base with this estimate as I haven't had the time to dig 
deeper into the source code. If anyone knows anything about this bit of 
code I would be interested in more information on it. If this is the 
case is there anyway that I could get around the RuntimeException problem?


Daniel Curran wrote:
> It turns out that my transform was setup incorrectly.
> Instead of throwing an exception for a status code of 200, I was 
> getting the default status code of 200 back as I was returning well 
> formatted XML.
> I am now running up against a problem of correctly catching my thrown 
> exception. When an exception is thrown at runtime via XSLT it is 
> caught as an org.apache.cocoon.ProcessingException.
> What this does is cause all of the different exceptions I am throwing 
> to be treated as a ProcessingException by the sitemap.
> <map:selector name="exception" 
> src="org.apache.cocoon.selection.XPathExceptionSelector">
>          <exception name="200" 
> class="com.dotech.util.StatusCode200Exception"/>
>          <exception name="201" 
> class="com.dotech.util.StatusCode201Exception"/>
>          <exception name="202" 
> class="com.dotech.util.StatusCode202Exception"/>
>          <exception name="404" 
> class="com.dotech.util.StatusCode404Exception"/>
>          <exception name="405" 
> class="com.dotech.util.StatusCode405Exception"/>
>          <exception name="406" 
> class="com.dotech.util.StatusCode406Exception"/>
>          <exception name="500" 
> class="com.dotech.util.StatusCode500Exception"/>
>          <exception name="501" 
> class="com.dotech.util.StatusCode501Exception"/>
> </map:selector>
> None of the above selections end up matching.
> I have been attemping to use the the java code for the exception I am 
> throwing is -
> public class ThrowException{
>    public static void statusCode200() throws StatusCode200Exception {
>       throw new  StatusCode200Exception("200");
>    }
>    ... other methods for the different status codes in the same 
> pattern ...
> }
> class StatusCode200Exception extends Exception {
>     public StatusCode200Exception(String error){
>       super(error);
>    }
>    ... other status types in same pattern ...
> }
> My question now becomes how would I go about trapping the portion of 
> the processing exception with a xpath expression.
> I have tried something like -
> <map:selector name="exception" 
> src="org.apache.cocoon.selection.XPathExceptionSelector">
>    <exception name="process" 
> class="org.apache.cocoon.ProcessingException">
>       <xpath name="200" test="getMessage=200"/>
>    </exception>
> </map:selector>
> But I the test is not matching correctly. I must be doing something 
> wrong with my xpath test. Any ideas?
> Thanks,
> Dan
> Daniel Curran wrote:
>> Since I need to make a choice between a number of different 
>> exceptions to throw I used a xalan java extension, and then an 
>> exception selector in the handle-errors section.
>> This did the trick. In the transform I have defined 
>> <exception:statusCode200/> which will cause Java to throw a 
>> StatusCode200Exception which I can pick up in the handle-errors 
>> section and return <map:serialize type="xml" status-code="200"/>
>> Using the java extension allows me to easily define which error code 
>> that I wish to throw and to pick based on an xsl:if or xsl:choose.
>> Thanks for the advice, it worked out great,
>> Dan
>> Joerg Heinicke wrote:
>>> On 10.04.2006 08:34, Bertrand Delacretaz wrote:
>>>> I don't think there is a standard way of throwing Exceptions from 
>>>> XSLT code, but calling a small Java extension class from XSLT to 
>>>> throw the Exception should do the trick, if you need to do this 
>>>> from XSLT.
>>> I could not read from his message that he needs exceptions from 
>>> XSLT, but there is an easy solution for it: <xsl:message 
>>> terminate="yes"/>.
>>> Regards,
>>> Jörg
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message