Talend Studio cErrorHandler vs Camel ErrorHandlers

[n999]

Hi

Quick question I hope.

I'm seeing some inconsistency between Camel docs and Talend Routes around the DefaultErrorHandler...

Camel docs https://camel.apache.org/manual/latest/defaulterrorhandler.html say that the DefaultHandler does not do redelivery.

However when you choose "Default Handler" on the cErrorHandler component, there are options to configure Redelivery?

Cheers

[Anonymous]

You can use anything you like from Apache Camel within Talend ESB. However, the documentation does not necessarily apply to components named similarly within the Talend toolset. If you are using Apache Camel's DefaultErrorHandler in code, then you would refer to the Camel docs. The cErrorHandler is a Talend component. This may be loosely based on the DefaultErrorHandler, but will have been extended to facilitate a particular way of working. It is absolutely fine to "cross the streams" (use Camel and Talend components), but be careful to take note of which documentation you are referring to.

[n999]

hi

many thanks for that!

Another contention between Camel and Talend I am now wrestling with, is the good practice as recommended here of 

"Using Error Handler combined with Exception Clause is a very powerful combination. We encourage end-users to use this combination in your error handling strategies." 

I'm using cTalendJob to call DI jobs in my Routes. I use a tRouteFault to mark a fault and then use handleFault() in a cJavaDSLProcessor as recommended here .

I can use a cOnException to catch the thrown org.apache.camel.CamelException but this is not very fine grained.

If I want to have different cOnException handlers with different behaviour I'm not sure how this is done. I can't find anything that allows you to throw a declared exception through a tRoutefault?

Apologies for all the questions - Feel like I'm almost there with what best practise is recommending...

[Anonymous]

I see your issue here. I'm NOT an expert at this, but can offer a suggestion. I think you are limited to the org.apache.camel.CamelException exception with the tRouteFault. What you can do is filter your type by using the description you give for the error when configuring the tRouteFault component. For example, you can set Headers, the Body, Exchange Properties and System Properties with the tRouteFault component. When I have done this in the past, I have set an "ErrorType" header. I have then used this, once the error is caught, to identify what I want to do with it.

[Anonymous]

@n999 I'm quite interested to know whether this approach worked for you. When you get some time, it would be great if you could let me know what you decided.

[n999]

Of course. V Happy to do so.

I'm having a chat with talend next week, and will then have to decide what approach to take after their response, basically what you suggest or design routes to cope only with the one flavour wrapped camel exception...)...will respond then. Please feel free to chase in a couple of weeks or so if no response

cheers

[Anonymous]

Thanks for giving back to the community. The more people do this, the better it is for everyone 🙂

[n999]

Hi

Talend has confirmed that a DI job exception can only be caught in a Talend Route at the CamelException level. 

So as you said, you can't have different behaviour in your Route based on different errors in (different) DI jobs.

Your suggestion of setting some headers on a tRouteFault and inspecting them in the route seems the only way to go. 

Or have the route deal with every DI job error the same way, which is what I've ended up doing....by sending to a Error Queue.

Cheers

Nomit