Good morning,
We're using Undertow in a new web service at MLB, and I haven't been able to find
a solution for handling errors that occur in requests that have been dispatched to worker
threads. Here is a link to my SO question:
http://stackoverflow.com/questions/37753726/how-to-handle-exceptions-thro....
Ignoring worker threads, my model for error handling is to have an outer handler that
maintains a map of exception type -> {log level, http status code}. Then I allow
exceptions to propagate out from the actual API handlers, hitting the error handler which
logs the error and responds to the client with the correct status code based on the
exception type. When exceptions are thrown from worker threads, however, they break out
of the normal handler chain and never hit the error handler, resulting in a 500 response
every time. Here are options I've considered for handling this problem:
1. Inside my error handler, set a DefaultResponseListener
(
https://http2.undertow.io/documentation/core/error-handling.html) on the exchange that
contains my error handling logic. I hit a wall here after realizing the listener only has
access to the Exchange, not to the exception that will be thrown.
2. Set an UncaughtExceptionHandler on each handler that's on a worker thread. This
code would be added to my base handler class, do a !exchange.isInIoThread() check, set the
error handler, then call the handleRequest method. The caveat here is that I can only do
this for handlers that I have control over, not built-in handlers that dispatch to worker
threads such as the AuthenticationCallHandler.
3. Use an AspectJ-based approach where I create an @Around advice that executes for all
of my handlers that will wrap the execution in a try-catch, and take care of the error
handling.
Are there best practices for handling this?
Thanks,
Jared Wolinsky
Senior Software Engineer, MLB Advanced Media
**********************************************************
MLB.com <
http://mlb.com> - Where Baseball is Always On.