dealing with exceptions in onExceptions definitions

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

dealing with exceptions in onExceptions definitions

dennisholu
Hello,

I have two onException definitions which catch exceptions and send
them to direct:logerrors endpoint. The second exception might throw an
exception which should be caught and handled by the first one. But
this doesn't work. The FatalFallbackErrorHandler kicks in and as the
result the exception is not logged by direct:logerrors, as I wish. Any
ideas how to safely implement this?

        from(direct:start)
            .onException(UpdateException.class) //retries and logs the error
                .handled(true)
                .maximumRedeliveries(5)
                .redeliveryDelay(1_000L)
                .to(direct:logerrors)
            .end()
            .onException(IgnoredException.class) //saves the POJO and
logs the error
                .handled(true)
                .process().body(Pojo.class, processor::update) //
throws UpdateException
                .to(direct:logerrors)
            .end()

Regards,
Dan
Reply | Threaded
Open this post in threaded view
|

Re: dealing with exceptions in onExceptions definitions

Claus Ibsen-2
Hi

This is by design, to avoid circular onException to trigger in endless.
So try to design your error handling in a more safe manner
On Tue, Nov 13, 2018 at 10:23 AM Dennis Holunder <[hidden email]> wrote:

>
> Hello,
>
> I have two onException definitions which catch exceptions and send
> them to direct:logerrors endpoint. The second exception might throw an
> exception which should be caught and handled by the first one. But
> this doesn't work. The FatalFallbackErrorHandler kicks in and as the
> result the exception is not logged by direct:logerrors, as I wish. Any
> ideas how to safely implement this?
>
>         from(direct:start)
>             .onException(UpdateException.class) //retries and logs the error
>                 .handled(true)
>                 .maximumRedeliveries(5)
>                 .redeliveryDelay(1_000L)
>                 .to(direct:logerrors)
>             .end()
>             .onException(IgnoredException.class) //saves the POJO and
> logs the error
>                 .handled(true)
>                 .process().body(Pojo.class, processor::update) //
> throws UpdateException
>                 .to(direct:logerrors)
>             .end()
>
> Regards,
> Dan



--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Reply | Threaded
Open this post in threaded view
|

Re: dealing with exceptions in onExceptions definitions

dennisholu
Hi Claus,

I was able to redesign the route, so that works as I want. In that
context however there is another issue with retrieving the exception
from exchange CamelExceptionCaught property.

The route catches CustomException exception and in that case saves the
body to database. While saving to database the PersistenceException
occurs, but is successfully retried. Then the CamelExceptionCaught
property contains PersistenceException instead of CustomException.

from("direct:start")
   .onException(CustomException.class)
    .handled(true)
    .to(persist)  // persist body (will fail, but successfully retry)
    .to(report)   // report custom exception

from(persist)
  .onException(PersistenceException.class)
    .retry(10)
    .log("could not persist body")

Is there a way to retrieve the original exception without looking
exception.getSuppressed() ? Obviously, the retried exception is not
interesting, but the failed one.

Thanks!
Dan

Am Mo., 3. Dez. 2018 um 19:05 Uhr schrieb Claus Ibsen-2 [via Camel]
<[hidden email]>:

>
> Hi
>
> This is by design, to avoid circular onException to trigger in endless.
> So try to design your error handling in a more safe manner
> On Tue, Nov 13, 2018 at 10:23 AM Dennis Holunder <[hidden email]> wrote:
>
> >
> > Hello,
> >
> > I have two onException definitions which catch exceptions and send
> > them to direct:logerrors endpoint. The second exception might throw an
> > exception which should be caught and handled by the first one. But
> > this doesn't work. The FatalFallbackErrorHandler kicks in and as the
> > result the exception is not logged by direct:logerrors, as I wish. Any
> > ideas how to safely implement this?
> >
> >         from(direct:start)
> >             .onException(UpdateException.class) //retries and logs the error
> >                 .handled(true)
> >                 .maximumRedeliveries(5)
> >                 .redeliveryDelay(1_000L)
> >                 .to(direct:logerrors)
> >             .end()
> >             .onException(IgnoredException.class) //saves the POJO and
> > logs the error
> >                 .handled(true)
> >                 .process().body(Pojo.class, processor::update) //
> > throws UpdateException
> >                 .to(direct:logerrors)
> >             .end()
> >
> > Regards,
> > Dan
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>
>
> ________________________________
> If you reply to this email, your message will be added to the discussion below:
> http://camel.465427.n5.nabble.com/dealing-with-exceptions-in-onExceptions-definitions-tp5825721p5826402.html
> To unsubscribe from Camel, click here.
> NAML
Reply | Threaded
Open this post in threaded view
|

Re: dealing with exceptions in onExceptions definitions

Claus Ibsen-2
Hi

You can store the custom exception as an exchange property before the
persist, and then retrieve it afterwards when you do the persist.


On Fri, Feb 8, 2019 at 9:59 AM Dennis Holunder <[hidden email]> wrote:

>
> Hi Claus,
>
> I was able to redesign the route, so that works as I want. In that
> context however there is another issue with retrieving the exception
> from exchange CamelExceptionCaught property.
>
> The route catches CustomException exception and in that case saves the
> body to database. While saving to database the PersistenceException
> occurs, but is successfully retried. Then the CamelExceptionCaught
> property contains PersistenceException instead of CustomException.
>
> from("direct:start")
>    .onException(CustomException.class)
>     .handled(true)
>     .to(persist)  // persist body (will fail, but successfully retry)
>     .to(report)   // report custom exception
>
> from(persist)
>   .onException(PersistenceException.class)
>     .retry(10)
>     .log("could not persist body")
>
> Is there a way to retrieve the original exception without looking
> exception.getSuppressed() ? Obviously, the retried exception is not
> interesting, but the failed one.
>
> Thanks!
> Dan
>
> Am Mo., 3. Dez. 2018 um 19:05 Uhr schrieb Claus Ibsen-2 [via Camel]
> <[hidden email]>:
> >
> > Hi
> >
> > This is by design, to avoid circular onException to trigger in endless.
> > So try to design your error handling in a more safe manner
> > On Tue, Nov 13, 2018 at 10:23 AM Dennis Holunder <[hidden email]> wrote:
> >
> > >
> > > Hello,
> > >
> > > I have two onException definitions which catch exceptions and send
> > > them to direct:logerrors endpoint. The second exception might throw an
> > > exception which should be caught and handled by the first one. But
> > > this doesn't work. The FatalFallbackErrorHandler kicks in and as the
> > > result the exception is not logged by direct:logerrors, as I wish. Any
> > > ideas how to safely implement this?
> > >
> > >         from(direct:start)
> > >             .onException(UpdateException.class) //retries and logs the error
> > >                 .handled(true)
> > >                 .maximumRedeliveries(5)
> > >                 .redeliveryDelay(1_000L)
> > >                 .to(direct:logerrors)
> > >             .end()
> > >             .onException(IgnoredException.class) //saves the POJO and
> > > logs the error
> > >                 .handled(true)
> > >                 .process().body(Pojo.class, processor::update) //
> > > throws UpdateException
> > >                 .to(direct:logerrors)
> > >             .end()
> > >
> > > Regards,
> > > Dan
> >
> >
> >
> > --
> > Claus Ibsen
> > -----------------
> > http://davsclaus.com @davsclaus
> > Camel in Action 2: https://www.manning.com/ibsen2
> >
> >
> > ________________________________
> > If you reply to this email, your message will be added to the discussion below:
> > http://camel.465427.n5.nabble.com/dealing-with-exceptions-in-onExceptions-definitions-tp5825721p5826402.html
> > To unsubscribe from Camel, click here.
> > NAML



--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Reply | Threaded
Open this post in threaded view
|

Re: dealing with exceptions in onExceptions definitions

dennisholu
Yes. That does the trick. Thank you!

But shouldn't camel do that for us? Or at least save successfully
retried exceptions in another property?

Am Fr., 8. Feb. 2019 um 17:38 Uhr schrieb Claus Ibsen-2 [via Camel]
<[hidden email]>:

>
> Hi
>
> You can store the custom exception as an exchange property before the
> persist, and then retrieve it afterwards when you do the persist.
>
>
> On Fri, Feb 8, 2019 at 9:59 AM Dennis Holunder <[hidden email]> wrote:
>
> >
> > Hi Claus,
> >
> > I was able to redesign the route, so that works as I want. In that
> > context however there is another issue with retrieving the exception
> > from exchange CamelExceptionCaught property.
> >
> > The route catches CustomException exception and in that case saves the
> > body to database. While saving to database the PersistenceException
> > occurs, but is successfully retried. Then the CamelExceptionCaught
> > property contains PersistenceException instead of CustomException.
> >
> > from("direct:start")
> >    .onException(CustomException.class)
> >     .handled(true)
> >     .to(persist)  // persist body (will fail, but successfully retry)
> >     .to(report)   // report custom exception
> >
> > from(persist)
> >   .onException(PersistenceException.class)
> >     .retry(10)
> >     .log("could not persist body")
> >
> > Is there a way to retrieve the original exception without looking
> > exception.getSuppressed() ? Obviously, the retried exception is not
> > interesting, but the failed one.
> >
> > Thanks!
> > Dan
> >
> > Am Mo., 3. Dez. 2018 um 19:05 Uhr schrieb Claus Ibsen-2 [via Camel]
> > <[hidden email]>:
> > >
> > > Hi
> > >
> > > This is by design, to avoid circular onException to trigger in endless.
> > > So try to design your error handling in a more safe manner
> > > On Tue, Nov 13, 2018 at 10:23 AM Dennis Holunder <[hidden email]> wrote:
> > >
> > > >
> > > > Hello,
> > > >
> > > > I have two onException definitions which catch exceptions and send
> > > > them to direct:logerrors endpoint. The second exception might throw an
> > > > exception which should be caught and handled by the first one. But
> > > > this doesn't work. The FatalFallbackErrorHandler kicks in and as the
> > > > result the exception is not logged by direct:logerrors, as I wish. Any
> > > > ideas how to safely implement this?
> > > >
> > > >         from(direct:start)
> > > >             .onException(UpdateException.class) //retries and logs the error
> > > >                 .handled(true)
> > > >                 .maximumRedeliveries(5)
> > > >                 .redeliveryDelay(1_000L)
> > > >                 .to(direct:logerrors)
> > > >             .end()
> > > >             .onException(IgnoredException.class) //saves the POJO and
> > > > logs the error
> > > >                 .handled(true)
> > > >                 .process().body(Pojo.class, processor::update) //
> > > > throws UpdateException
> > > >                 .to(direct:logerrors)
> > > >             .end()
> > > >
> > > > Regards,
> > > > Dan
> > >
> > >
> > >
> > > --
> > > Claus Ibsen
> > > -----------------
> > > http://davsclaus.com @davsclaus
> > > Camel in Action 2: https://www.manning.com/ibsen2
> > >
> > >
> > > ________________________________
> > > If you reply to this email, your message will be added to the discussion below:
> > > http://camel.465427.n5.nabble.com/dealing-with-exceptions-in-onExceptions-definitions-tp5825721p5826402.html
> > > To unsubscribe from Camel, click here.
> > > NAML
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>
>
> ________________________________
> If you reply to this email, your message will be added to the discussion below:
> http://camel.465427.n5.nabble.com/dealing-with-exceptions-in-onExceptions-definitions-tp5825721p5829908.html
> To unsubscribe from Camel, click here.
> NAML