[
https://issues.apache.org/jira/browse/CAMEL-13706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stig Rohde Døssing updated CAMEL-13706:
---------------------------------------
Description:
Exception propagation between RouteBuilders is currently only possible with the
NoErrorHandler. It would be great if the DefaultErrorHandler could be
configured to propagate exceptions it is not configured to handle. This would
allow more Java-like exception handling for pipelines that cross RouteBuilders.
Basically the behavior I'd like from the DefaultErrorHandler is that exceptions
thrown from a route that are not handled, and exceptions thrown from
onException clauses, are handled the same way they would if the NoErrorHandler
were configured. This would cause them to propagate to handlers in the parent.
An example of how this could look:
{code:java}
class RestRouteBuilder extends RouteBuilder {
onException(Exception.class)
.handled(true)
.process(return a 500-series code)
onException(JsonProcessingException.class)
.handled(true)
.process(return a 400-series code)
from(rest)
.choice()
.when(the request is type A)
.to(type A route)
.otherwise()
.to(type B route)
}
class TypeARouteBuilder extends RouteBuilder {
setErrorHandlerBuilder(defaultErrorHandler().propagateUncaughtExceptions());
onException(SomeRouteSpecificException.class)
.handled(true)
//Any exception thrown here is propagated to the RestRouteBuilder's
onException clauses
from(type A route)
//SomeRouteSpecificException gets handled by the onException clause above
//Anything else is propagated to the RestRouteBuilder's onException clauses
.to(write to DB route)
}
class TypeBRouteBuilder extends RouteBuilder {
setErrorHandlerBuilder(defaultErrorHandler().propagateUncaughtExceptions());
onException(SomeOtherRouteSpecificException.class)
.handled(true)
//Any exception thrown here is propagated to the RestRouteBuilder's
onException clauses
from(type B route)
//SomeOtherRouteSpecificException gets handled by the onException clause
above
//Anything else is propagated to the RestRouteBuilder's onException clauses
.to(write to DB route)
}
class DBRouteBuilder extends RouteBuilder {
setErrorHandlerBuilder(defaultErrorHandler().propagateUncaughtExceptions());
onException(AuthenticationException.class)
.redeliveryPolicy(new RedeliveryPolicy().maximumRedeliveries(10))
from(type A route)
//AuthenticationException gets handled by the onException clause above
//Anything else is propagated to either TypeA or TypeB onException
clauses, and possibly on to RestRouteBuilder's clauses
.to(the DB endpoint)
}
{code}
I'd be happy to work on implementing this option, assuming there isn't
opposition to creating a feature like this.
was:
Exception propagation between RouteBuilders is currently only possible with the
NoErrorHandler. It would be great if the DefaultErrorHandler could be
configured to propagate exceptions it is not configured to handle. This would
allow more Java-like exception handling for pipelines that cross RouteBuilders.
Basically the behavior I'd like from the DefaultErrorHandler is that exceptions
thrown from a route that are not handled, and exceptions thrown from
onException clauses, are handled the same way they would if the NoErrorHandler
were configured. This would cause them to propagate to handlers in the parent.
An example of how this could look:
{code}
class RestRouteBuilder extends RouteBuilder {
onException(Exception.class)
.handled(true)
.process(return a 500-series code)
onException(JsonProcessingException.class)
.handled(true)
.process(return a 400-series code)
from(rest)
.choice()
.when(the request is type A)
.to(type A route)
.otherwise()
.to(type B route)
}
class TypeARouteBuilder extends RouteBuilder {
setErrorHandlerBuilder(defaultErrorHandler().propagateUnknownExceptions());
onException(SomeRouteSpecificException.class)
.handled(true)
//Any exception thrown here is propagated to the RestRouteBuilder's
onException clauses
from(type A route)
//SomeRouteSpecificException gets handled by the onException clause above
//Anything else is propagated to the RestRouteBuilder's onException clauses
.to(write to DB route)
}
class TypeBRouteBuilder extends RouteBuilder {
setErrorHandlerBuilder(defaultErrorHandler().propagateUnknownExceptions());
onException(SomeOtherRouteSpecificException.class)
.handled(true)
//Any exception thrown here is propagated to the RestRouteBuilder's
onException clauses
from(type B route)
//SomeOtherRouteSpecificException gets handled by the onException clause
above
//Anything else is propagated to the RestRouteBuilder's onException clauses
.to(write to DB route)
}
class DBRouteBuilder extends RouteBuilder {
setErrorHandlerBuilder(defaultErrorHandler().propagateUnknownExceptions());
onException(AuthenticationException.class)
.redeliveryPolicy(new RedeliveryPolicy().maximumRedeliveries(10))
from(type A route)
//AuthenticationException gets handled by the onException clause above
//Anything else is propagated to either TypeA or TypeB onException
clauses, and possibly on to RestRouteBuilder's clauses
.to(the DB endpoint)
}
{code}
I'd be happy to work on implementing this option, assuming there isn't
opposition to creating a feature like this.
> Allow conditional exception propagation to parent RouteBuilders from
> DefaultErrorHandler
> ----------------------------------------------------------------------------------------
>
> Key: CAMEL-13706
> URL: https://issues.apache.org/jira/browse/CAMEL-13706
> Project: Camel
> Issue Type: New Feature
> Reporter: Stig Rohde Døssing
> Priority: Major
>
> Exception propagation between RouteBuilders is currently only possible with
> the NoErrorHandler. It would be great if the DefaultErrorHandler could be
> configured to propagate exceptions it is not configured to handle. This would
> allow more Java-like exception handling for pipelines that cross
> RouteBuilders.
> Basically the behavior I'd like from the DefaultErrorHandler is that
> exceptions thrown from a route that are not handled, and exceptions thrown
> from onException clauses, are handled the same way they would if the
> NoErrorHandler were configured. This would cause them to propagate to
> handlers in the parent.
> An example of how this could look:
> {code:java}
> class RestRouteBuilder extends RouteBuilder {
> onException(Exception.class)
> .handled(true)
> .process(return a 500-series code)
> onException(JsonProcessingException.class)
> .handled(true)
> .process(return a 400-series code)
> from(rest)
> .choice()
> .when(the request is type A)
> .to(type A route)
> .otherwise()
> .to(type B route)
> }
> class TypeARouteBuilder extends RouteBuilder {
>
> setErrorHandlerBuilder(defaultErrorHandler().propagateUncaughtExceptions());
> onException(SomeRouteSpecificException.class)
> .handled(true)
> //Any exception thrown here is propagated to the RestRouteBuilder's
> onException clauses
> from(type A route)
> //SomeRouteSpecificException gets handled by the onException clause above
> //Anything else is propagated to the RestRouteBuilder's onException
> clauses
> .to(write to DB route)
> }
> class TypeBRouteBuilder extends RouteBuilder {
> setErrorHandlerBuilder(defaultErrorHandler().propagateUncaughtExceptions());
>
> onException(SomeOtherRouteSpecificException.class)
> .handled(true)
> //Any exception thrown here is propagated to the RestRouteBuilder's
> onException clauses
> from(type B route)
> //SomeOtherRouteSpecificException gets handled by the onException clause
> above
> //Anything else is propagated to the RestRouteBuilder's onException
> clauses
> .to(write to DB route)
> }
> class DBRouteBuilder extends RouteBuilder {
> setErrorHandlerBuilder(defaultErrorHandler().propagateUncaughtExceptions());
> onException(AuthenticationException.class)
> .redeliveryPolicy(new RedeliveryPolicy().maximumRedeliveries(10))
> from(type A route)
> //AuthenticationException gets handled by the onException clause above
> //Anything else is propagated to either TypeA or TypeB onException
> clauses, and possibly on to RestRouteBuilder's clauses
> .to(the DB endpoint)
> }
> {code}
> I'd be happy to work on implementing this option, assuming there isn't
> opposition to creating a feature like this.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
