Apache Camel - Error Handling

Reading Time: 4 minutes

In the Apache Camel series, we have already reached the halfway mark. But, in this blog, you’ll tackle one of the most difficult aspects of integration: dealing with the unexpected.

When it comes to handling unforeseen occurrences, developing applications that integrate different systems is difficult. You can manage these occurrences and recover in a single system that you fully control. In the same way, network-connected systems face extra risks: the network connection may get lost, a remote system may fail to respond in a timely manner, or it may fail for no apparent reason. Unexpected events, such as the server’s disc filling up or running out of memory, can happen even on your local server. Regardless of the type of error that occurs, your program should be capable of handling it.

Log files are sometimes the only evidence of an unexpected incident in these cases, hence logging is critical. Camel provides strong logging and error handling features, ensuring that your application can continue to run.

Understanding how to deal with errors

Recoverable and Irrecoverable errors

No matter how many times you try to accomplish the same operation, an irrecoverable error remains an error. In the integrated world, this may imply trying to access a database table that doesn’t exist, resulting in a SQLException from the JDBC driver.
A recoverable error, on the other hand, is a one-time occurrence that may or may not result in a problem on subsequent attempts. Likewise, an excellent illustration of such an error is a difficulty with the network connection that results in a java.io.IOException. We can address the network issue on a later attempt, and your program may continue to function.

Let’s recap how do we represent recoverable and irrecoverable faults in Camel now that you’ve seen them in action:

We use Exceptions to express Recoverable errors.
Similarly, we use Fault messages to express unrecoverable errors.

Camel Error Handlers

Camel considers all the exceptions as recoverable exceptions. Also, these type of exceptions gets stored on the exchange using the setException(Throwable cause) method. This means that Camel’s error handlers will only respond to exceptions raised on the exchange. Camel error handlers are only triggered when there is an exchange, according to the rule of thumb. getException() is not equal to null.

Camel has a number of Error Handlers to choose from

Error Handler	Description
DefaultErrorHandler	If no other error handler has been defined, this is the default error handler that is automatically enabled.
DeadLetterChannel	The Dead Letter Channel EIP is implemented by this error handler.
TransactionErrorHandler	This is an extension of the default error handler that is transaction-aware.
NoErrorHandler	This handler is used to completely disable error handling.
LoggingErrorHandler	This error handler does nothing more than log the exception. This error handler is no longer recommended; instead, use the DeadLetterChannel error handler with a log endpoint as the destination.

Error Handlers

Although having five error handlers may appear daunting at first, you’ll find that the default error handler is the saving grace in most circumstances.
The first three error handlers extend the RedeliveryErrorHandler class. Major error-handling functionality is there in this class which is very useful for these three handlers. The last two error handlers don’t extend RedeliveryErrorHandler and have restricted functionality.

Error Handlers in Detail

Default Error Handler

Camel has DefaultErrorHandler, which covers the vast majority of scenarios. Also, we do not have to mention the default handler. These are the settings for the default error handler:

There is no redelivery.
The original caller gets the exceptions in return.
The log gets the reporting of the exception’s stack trace.
The log gets the printed history of the exchange’s routing.

When a routing exception occurs, the default behavior is to log a route history that tracks the steps back to where Camel routed the exchange. This allows you to immediately pinpoint where the error happened in the route. Camel also records information about the current exchange, such as the message text and headers.

Dead Letter Channel Error Handler

DeadLetterChannel is an error handler that implements the Dead Letter Channel EIP’s principles. According to this pattern, if a message is not processed or sent, the message should reach to dead letter queue.

The DeadLetterChannel error handler is comparable to the default error handler, with the following exceptions:

Unlike the usual error handler, the dead letter channel handles exceptions by default and moves unsuccessful messages to the dead letter queue.
The dead letter channel is set to not log any activity by default when handling exceptions.
When a message is moving to the dead letter queue, the dead letter channel supports using the original input message.
The dead letter channel is the only error handler that allows failed messages to move to a separate error queue, known as the dead letter queue.

Transaction Error Handler

The TransactionErrorHandler is a wrapper around the default error handler that provides the same functionality as the default error handler. The TransactionErrorHandler enables transactional routes with more optimization.

No Error Handler

We can also disable Error handling using NoErrorHandler as Camel’s current architecture supports that as well. If you want to disable error handling, you’ll have to provide an error handler that’s essentially an empty shell with no logic. That’s the NoErrorHandler class.

Logging Error Handler

We can log together with the unsuccessful message with the exception of LoggingErrorHandler. The logger uses log4j, commons logging, and the Java Util Logger as logging kits.
Camel will report the failure message and the exception by default using the org.apache.camel.processor log name.
At the ERROR level, there is a LoggingErrorHandler. You may, of course, make this your own.
When we use the dead letter channel error handler and a log endpoint as the destination, we can replace the logging error handler. As a result, the logging error handler gets staggered out in favor of this method.