You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Considering the following two cases:
Case 1: An exception is thrown in the caller's thread (synchronous processes);
Case 2: An exception is thrown in a latter thread after the caller puts a message (asynchronous processes)
In Case 1, the exception will be thrown to the caller. Meanwhile In Case 2, the caller's thread will return immediately when it puts the message, and therefore it never knows what will happen further. So, the message will be routed to the default errorChannel or the channel defined by the errorChannel value in the message's header only in the case.
It is a little confusing that the document does not clarify the condition and there have been already many related questions.
The text was updated successfully, but these errors were encountered:
garyrussell
changed the title
Documentation Enhancemen: clarify the case which "error-channel" works
Documentation Enhancement: clarify the case which "error-channel" works
Aug 9, 2019
Fixesspring-projects#3024
To avoid confusing about `errorChannel` header behavior and make it more
clear how to handle errors in Spring Integration flows, it would be
better to present an `Error Handling` chapter on the top level.
So, now it is a first chapter of the `Appendices` section
Fixes#3024
To avoid confusing about `errorChannel` header behavior and make it more
clear how to handle errors in Spring Integration flows, it would be
better to present an `Error Handling` chapter on the top level.
So, now it is a first chapter of the `Appendices` section
Considering the following two cases:
Case 1: An exception is thrown in the caller's thread (synchronous processes);
Case 2: An exception is thrown in a latter thread after the caller puts a message (asynchronous processes)
In Case 1, the exception will be thrown to the caller. Meanwhile In Case 2, the caller's thread will return immediately when it puts the message, and therefore it never knows what will happen further. So, the message will be routed to the default
errorChannel
or the channel defined by theerrorChannel
value in the message's header only in the case.It is a little confusing that the document does not clarify the condition and there have been already many related questions.
The text was updated successfully, but these errors were encountered: