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
{{ message }}
This repository has been archived by the owner on Oct 27, 2021. It is now read-only.
Is your feature request related to a problem? Please describe.
I ran into a few scenarios where it would have been nearly impossible to debug the root cause for an error because we swallow the root target exception and only display the last message from the thrown exception which does not provide any indication or clues of what caused the error. An example of this occurs in LinuxForHealthRouteBuilder class within error handling route. The 'direct:error' route takes the message from the thrown exception and sets it in the body. Unfortunately, this message is a general error message that doesn't indicate the specific cause (HL7 message parse error, or JSON parse error).
Describe the solution you'd like
Consider iterating through the nested exception messages and appending those together and logging or returning those as the error. Depending on the type of request, the response error may actually require a protocol-specific format and therefore presents an additional challenge since it cannot be handled in a single place without context.
Describe alternatives you've considered
For debugging purposes, I logged the entire exception stack trace within the error route process method as a workaround.
Additional context
Here is an example of a nested exception message that is actually useful for understanding the cause of an error in the request:
Validation failed: Primitive value '201907261530 OBX' requires to be empty or a HL7 datetime string at OBX-14(0)"
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Is your feature request related to a problem? Please describe.
I ran into a few scenarios where it would have been nearly impossible to debug the root cause for an error because we swallow the root target exception and only display the last message from the thrown exception which does not provide any indication or clues of what caused the error. An example of this occurs in LinuxForHealthRouteBuilder class within error handling route. The 'direct:error' route takes the message from the thrown exception and sets it in the body. Unfortunately, this message is a general error message that doesn't indicate the specific cause (HL7 message parse error, or JSON parse error).
Describe the solution you'd like
Consider iterating through the nested exception messages and appending those together and logging or returning those as the error. Depending on the type of request, the response error may actually require a protocol-specific format and therefore presents an additional challenge since it cannot be handled in a single place without context.
Describe alternatives you've considered
For debugging purposes, I logged the entire exception stack trace within the error route process method as a workaround.
Additional context
Here is an example of a nested exception message that is actually useful for understanding the cause of an error in the request:
Validation failed: Primitive value '201907261530 OBX' requires to be empty or a HL7 datetime string at OBX-14(0)"
The text was updated successfully, but these errors were encountered: