Return-Path: 
 <dev-return-28571-apmail-camel-dev-archive=camel.apache.org@camel.apache.org>
X-Original-To: apmail-camel-dev-archive@www.apache.org
Delivered-To: apmail-camel-dev-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 9A1F74C09
	for <apmail-camel-dev-archive@www.apache.org>;
 Fri, 27 May 2011 13:58:31 +0000 (UTC)
Received: (qmail 65356 invoked by uid 500); 27 May 2011 13:58:31 -0000
Delivered-To: apmail-camel-dev-archive@camel.apache.org
Received: (qmail 65316 invoked by uid 500); 27 May 2011 13:58:31 -0000
Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@camel.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@camel.apache.org>
List-Post: <mailto:dev@camel.apache.org>
List-Id: <dev.camel.apache.org>
Reply-To: dev@camel.apache.org
Delivered-To: mailing list dev@camel.apache.org
Received: (qmail 65307 invoked by uid 99); 27 May 2011 13:58:31 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 27 May 2011 13:58:31 +0000
X-ASF-Spam-Status: No, hits=-2000.0 required=5.0
	tests=ALL_TRUSTED,T_RP_MATCHES_RCVD
X-Spam-Check-By: apache.org
Received: from [140.211.11.116] (HELO hel.zones.apache.org) (140.211.11.116)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 27 May 2011 13:58:28 +0000
Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116])
	by hel.zones.apache.org (Postfix) with ESMTP id 67DB6E221A
	for <dev@camel.apache.org>; Fri, 27 May 2011 13:57:47 +0000 (UTC)
Date: Fri, 27 May 2011 13:57:47 +0000 (UTC)
From: "Claus Ibsen (JIRA)" <jira@apache.org>
To: dev@camel.apache.org
Message-ID: 
 <1417332515.48683.1306504667422.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1831981016.48602.1306502928398.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Issue Comment Edited] (CAMEL-4022) Issue using
 errorBuilderRef with the xml dsl
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394
X-Virus-Checked: Checked by ClamAV on apache.org


    [ https://issues.apache.org/jira/browse/CAMEL-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13040237#comment-13040237 ] 

Claus Ibsen edited comment on CAMEL-4022 at 5/27/11 1:56 PM:
-------------------------------------------------------------

The behavior should be that no error handler should be used, when routing inside the <onException>.

For example as you say if another exception, or the same type of exception occurs, then the complexity gets hard. What if there is another onException that handles that exception, and then another exception is thrown and you go back to the first onException. And so on. Eg you have to be careful to not go in circles.

The onException is to allow end users to handle that exception in any custom way. For example to prepare some custom reply message (instead of the exception).

If you want to continue routing and have error handling, then send the message to a route:
onException(SomeException.class).handled(true).to("direct:someRoute");


      was (Author: davsclaus):
    The behavior should be that no error handler should be used, when routing inside the <onException>.

For example as you say if another exception, or the same type of exception occurs, then the complexity gets hard. What if there is another onException that handles that exception, and then another exception is thrown and you go back to the first onException. And so on. Eg you have to be careful to not go in circles.

The onException is to allow end users to handle that exception in any custom way. For example to prepare some custom reply message (instead of the exception).

If you want to continue routing and have error handling, then send the message to a route:
onException(x).handled(true).to("direct:someRoute");

  
> Issue using errorBuilderRef with the xml dsl
> --------------------------------------------
>
>                 Key: CAMEL-4022
>                 URL: https://issues.apache.org/jira/browse/CAMEL-4022
>             Project: Camel
>          Issue Type: Bug
>    Affects Versions: 2.7.1
>            Reporter: Hadrian Zbarcea
>            Assignee: Hadrian Zbarcea
>
> While fixing issues around the errorHandler I noticed that <onException> definitions defined in the camel context are ignored if a route specifies its own errorHandlerRef. The reason is that we set the onException definition on the default error handler. I have a fix for that, but I discovered a different issue (I think) for which I would like to discuss the solution.
> When we have an onException definition that looks kinda like this:
> {code}
> <onException>
>   <exception> java.lang.IllegalArgumentException</exception>
>   <to uri="mock:illegalArgumentException"/>
> </onException>
> {code}
> ... something happens, the IAE exception is caught, we do something, but in that process another exception is thrown. Currently, that would be caught by the default error handler, which may not be what we want.
> What error handler (if any) should handle exceptions thrown while in onException?
> [I will get back later today with the options I see, but comments are appreciated in the meantime]

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira