Irrecoverable faults

[James Green <ja...@gmail.com>]

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

[James Green <ja...@gmail.com>]

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 <wi...@gmail.com> 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.green@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

[Willem Jiang <wi...@gmail.com>]

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.green@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
>