Re: Irrecoverable faults
I saw a StackOverflow question asking the difference between errorHandler and onException. I believe the answer given was that errorHandler handles exceptions not otherwise trapped by onException. If this is true (and the complete answer) it may be wise to add this line to the documentation..? On 10 January 2015 at 07:20, Willem Jiang wrote: > Current Camel ErrorHandler just provides a way to let you handle the > error. Even it provides retry mechanism, you still can do some work for the > Irrecoverable error. > > With the ControlBus[1], you can stop the route which has the irrecoverable > faults. > If you want to stop the message, you can setup the exchange stop header to > be true just like this: > exchange.setProperty(Exchange.ROUTE_STOP, Boolean.TRUE); > > [1]https://camel.apache.org/controlbus.html > > > -- > Willem Jiang > > Red Hat, Inc. > Web: http://www.redhat.com > Blog: http://willemjiang.blogspot.com (English) > http://jnn.iteye.com (Chinese) > Twitter: willemjiang > Weibo: 姜宁willem > > > > On January 9, 2015 at 5:53:32 PM, James Green (james.mk.gr...@gmail.com) > wrote: > > Should we avoid issuing these? > > > > We are implementing some checks that ask, for example, "Is the customer > > allowed to do this?" And if the answer is no we're treating this as > > irrecoverable. > > > > Map this to irrecoverable according to Camel in Action Ch 5, Error > > Handling. Yet this chapter barely touches irrecoverable errors, focusing > > almost entirely on recoverable errors which are Throwables from the > route. > > The web site also seems to have the same focus. > > > > Am I modelling this in my mind? When Camel thinks of irrecoverable, does > it > > consider this as a "stop the runtime" type of error or "stop the message" > > type of error? And am I barking up the wrong tree entirely - should all > > business logic checks that "fail" actually be considered recoverable > > according to Camel? > > > > N.B. I noticed Google has reference to a years-old discussion suggesting > to > > remove Fault, which has raised alarm bells in my thinking too. > > > > Thanks, > > > > James > > > >
Re: Irrecoverable faults
Current Camel ErrorHandler just provides a way to let you handle the error. Even it provides retry mechanism, you still can do some work for the Irrecoverable error. With the ControlBus[1], you can stop the route which has the irrecoverable faults. If you want to stop the message, you can setup the exchange stop header to be true just like this: exchange.setProperty(Exchange.ROUTE_STOP, Boolean.TRUE); [1]https://camel.apache.org/controlbus.html -- Willem Jiang Red Hat, Inc. Web: http://www.redhat.com Blog: http://willemjiang.blogspot.com (English) http://jnn.iteye.com (Chinese) Twitter: willemjiang Weibo: 姜宁willem On January 9, 2015 at 5:53:32 PM, James Green (james.mk.gr...@gmail.com) wrote: > Should we avoid issuing these? > > We are implementing some checks that ask, for example, "Is the customer > allowed to do this?" And if the answer is no we're treating this as > irrecoverable. > > Map this to irrecoverable according to Camel in Action Ch 5, Error > Handling. Yet this chapter barely touches irrecoverable errors, focusing > almost entirely on recoverable errors which are Throwables from the route. > The web site also seems to have the same focus. > > Am I modelling this in my mind? When Camel thinks of irrecoverable, does it > consider this as a "stop the runtime" type of error or "stop the message" > type of error? And am I barking up the wrong tree entirely - should all > business logic checks that "fail" actually be considered recoverable > according to Camel? > > N.B. I noticed Google has reference to a years-old discussion suggesting to > remove Fault, which has raised alarm bells in my thinking too. > > Thanks, > > James >
Irrecoverable faults
Should we avoid issuing these? We are implementing some checks that ask, for example, "Is the customer allowed to do this?" And if the answer is no we're treating this as irrecoverable. Map this to irrecoverable according to Camel in Action Ch 5, Error Handling. Yet this chapter barely touches irrecoverable errors, focusing almost entirely on recoverable errors which are Throwables from the route. The web site also seems to have the same focus. Am I modelling this in my mind? When Camel thinks of irrecoverable, does it consider this as a "stop the runtime" type of error or "stop the message" type of error? And am I barking up the wrong tree entirely - should all business logic checks that "fail" actually be considered recoverable according to Camel? N.B. I noticed Google has reference to a years-old discussion suggesting to remove Fault, which has raised alarm bells in my thinking too. Thanks, James
