Return-Path: 
 <camel-user-return-4313-apmail-activemq-camel-user-archive=activemq.apache.org@activemq.apache.org>
Delivered-To: apmail-activemq-camel-user-archive@locus.apache.org
Received: (qmail 85304 invoked from network); 19 Nov 2008 12:34:22 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 19 Nov 2008 12:34:22 -0000
Received: (qmail 56023 invoked by uid 500); 19 Nov 2008 12:34:30 -0000
Delivered-To: apmail-activemq-camel-user-archive@activemq.apache.org
Received: (qmail 56006 invoked by uid 500); 19 Nov 2008 12:34:30 -0000
Mailing-List: contact camel-user-help@activemq.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:camel-user-help@activemq.apache.org>
List-Unsubscribe: <mailto:camel-user-unsubscribe@activemq.apache.org>
List-Post: <mailto:camel-user@activemq.apache.org>
List-Id: <camel-user.activemq.apache.org>
Reply-To: camel-user@activemq.apache.org
Delivered-To: mailing list camel-user@activemq.apache.org
Received: (qmail 55995 invoked by uid 99); 19 Nov 2008 12:34:30 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 19 Nov 2008 04:34:30 -0800
X-ASF-Spam-Status: No, hits=2.6 required=10.0
	tests=DNS_FROM_OPENWHOIS,SPF_HELO_PASS,SPF_PASS,WHOIS_MYPRIVREG
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of lists@nabble.com designates
 216.139.236.158 as permitted sender)
Received: from [216.139.236.158] (HELO kuber.nabble.com) (216.139.236.158)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 19 Nov 2008 12:33:07 +0000
Received: from isper.nabble.com ([192.168.236.156])
	by kuber.nabble.com with esmtp (Exim 4.63)
	(envelope-from <lists@nabble.com>)
	id 1L2mFj-00043y-Gs
	for camel-user@activemq.apache.org; Wed, 19 Nov 2008 04:33:51 -0800
Message-ID: <20578887.post@talk.nabble.com>
Date: Wed, 19 Nov 2008 04:33:51 -0800 (PST)
From: Fush <rikard.eriksen@gmail.com>
To: camel-user@activemq.apache.org
Subject: Re: 1.5 error handling Spring config buggy/not complete?
In-Reply-To: <5380c69c0811190424mac24e36t8606c52452af71d8@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Nabble-From: rikard.eriksen@gmail.com
References: <20562554.post@talk.nabble.com>
 <5380c69c0811182318m46a0b17dsa43a4960d3f42e3d@mail.gmail.com>
 <20576291.post@talk.nabble.com>
 <5380c69c0811190143r48d5808ah2762436fe8643068@mail.gmail.com>
 <20578586.post@talk.nabble.com>
 <5380c69c0811190424mac24e36t8606c52452af71d8@mail.gmail.com>
X-Virus-Checked: Checked by ClamAV on apache.org


I was assuming that if an exception (any other than FunctionalException) was
thrown from within my <onException> clause, it would be handled by the
TransactionManager as for all other exceptions. But apparently not. :)

I have to expect exceptions from the myOwnErrorHandler bean, because it
calls a remote system. What are my options if I would like to write my own
implementation of the <onException> tag? Would that be feasible? Do you know
of any examples/tutorials for that?


Claus Ibsen-2 wrote:
> 
> Hi
> 
> Ha ha you have a catch-22 situation ;) You are doing the "handling" of
> the exception (kinda like a finally) but in that process you also have
> an exception being thrown.
> 
> What would be the ideal situation to do here?
> - Let Camel try to find a new onException that matches the new
> exception being thrown?
> - Or log it as a kind of WARN (this is the easiest to do)
> 
> We should beware that we don't push the it to far and it gets to
> complex to understand what happens.
> 
> Any thoughts?
> 
> 
> A workaround in your bean is to use
> try .. catch code style and handle the new exception your self.
> 
> 
> /Claus Ibsen
> Apache Camel Committer
> Blog: http://davsclaus.blogspot.com/
> 

-- 
View this message in context: http://www.nabble.com/1.5-error-handling-Spring-config-buggy-not-complete--tp20562554s22882p20578887.html
Sent from the Camel - Users mailing list archive at Nabble.com.