<div dir="ltr">There is something similar here. <a href="https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io/undertow/server/handlers/ExceptionHandler.java#L17">https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io/undertow/server/handlers/ExceptionHandler.java#L17</a><div><br></div><div>Should they use the same Key or be kept separate?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 16, 2016 at 8:45 PM, Stuart Douglas <span dir="ltr">&lt;<a href="mailto:sdouglas@redhat.com" target="_blank">sdouglas@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I have added support for this, which will be available in Undertow<br>
1.4.0 which should come out very shortly. The exception is will be<br>
stored under the io.undertow.server.DefaultResponseListener#EXCEPTION<br>
attachment key).<br>
<br>
Stuart<br>
<br>
On Fri, Jun 17, 2016 at 12:17 AM, Wolinsky, Jared<br>
<div class="HOEnZb"><div class="h5">&lt;<a href="mailto:jared.wolinsky@mlb.com">jared.wolinsky@mlb.com</a>&gt; wrote:<br>
&gt; For me, adding the exception onto the exchange would be fine, along with a mention in the error handling section of the docs.  I think it&#39;s ok if the DefaultResponseListener isn&#39;t called if the exchange is ended because that is some handler explicitly taking care of the response and overriding the default case.  That said, I don&#39;t think an explicit error handling interface would be a bad way to go either.<br>
&gt;<br>
&gt; I was actually able to work around this using Bill O&#39;Neil&#39;s advice and dispatching the request every time in my ErrorHandler, which is the outer handler in my chain.  Then I try-catch the next.handleRequest call, and do my exception handling there.<br>
&gt;<br>
&gt; Thanks,<br>
&gt; Jared<br>
&gt; ________________________________________<br>
&gt; From: Stuart Douglas [<a href="mailto:sdouglas@redhat.com">sdouglas@redhat.com</a>]<br>
&gt; Sent: Wednesday, June 15, 2016 10:37 PM<br>
&gt; To: Wolinsky, Jared<br>
&gt; Cc: <a href="mailto:undertow-dev@lists.jboss.org">undertow-dev@lists.jboss.org</a><br>
&gt; Subject: Re: [undertow-dev] How to handle exceptions thrown from worker threads<br>
&gt;<br>
&gt; I think you are correct that we don&#39;t handle this case very well, the<br>
&gt; basic error handing strategy has always been to just catch the error<br>
&gt; in a handler, but when you don&#39;t have control over the dispatch site<br>
&gt; this gets tricky.<br>
&gt;<br>
&gt; We should definitely make the error available in<br>
&gt; DefaultResponseListener, probably just as an attachment on the<br>
&gt; exchange. Would this be enough to meet your requirements, or would<br>
&gt; some kind of actual error handling interface be better?<br>
&gt; DefaultResponseListener may not always be called if the exchange has<br>
&gt; already been finished when the error occurs (i.e. the page has already<br>
&gt; been sent to the user).<br>
&gt;<br>
&gt; Stuart<br>
&gt;<br>
&gt; On Wed, Jun 15, 2016 at 2:01 AM, Wolinsky, Jared &lt;<a href="mailto:jared.wolinsky@mlb.com">jared.wolinsky@mlb.com</a>&gt; wrote:<br>
&gt;&gt; Good morning,<br>
&gt;&gt;<br>
&gt;&gt; We&#39;re using Undertow in a new web service at MLB, and I haven&#39;t been able to<br>
&gt;&gt; find a solution for handling errors that occur in requests that have been<br>
&gt;&gt; dispatched to worker threads.  Here is a link to my SO question:<br>
&gt;&gt; <a href="http://stackoverflow.com/questions/37753726/how-to-handle-exceptions-thrown-from-undertow-worker-threads" rel="noreferrer" target="_blank">http://stackoverflow.com/questions/37753726/how-to-handle-exceptions-thrown-from-undertow-worker-threads</a>.<br>
&gt;&gt; Ignoring worker threads, my model for error handling is to have an outer<br>
&gt;&gt; handler that maintains a map of exception type -&gt; {log level, http status<br>
&gt;&gt; code}.  Then I allow exceptions to propagate out from the actual API<br>
&gt;&gt; handlers, hitting the error handler which logs the error and responds to the<br>
&gt;&gt; client with the correct status code based on the exception type.  When<br>
&gt;&gt; exceptions are thrown from worker threads, however, they break out of the<br>
&gt;&gt; normal handler chain and never hit the error handler, resulting in a 500<br>
&gt;&gt; response every time.  Here are options I&#39;ve considered for handling this<br>
&gt;&gt; problem:<br>
&gt;&gt;<br>
&gt;&gt; Inside my error handler, set a DefaultResponseListener<br>
&gt;&gt; (<a href="https://http2.undertow.io/documentation/core/error-handling.html" rel="noreferrer" target="_blank">https://http2.undertow.io/documentation/core/error-handling.html</a>) on the<br>
&gt;&gt; exchange that contains my error handling logic.  I hit a wall here after<br>
&gt;&gt; realizing the listener only has access to the Exchange, not to the exception<br>
&gt;&gt; that will be thrown.<br>
&gt;&gt; Set an UncaughtExceptionHandler on each handler that&#39;s on a worker thread.<br>
&gt;&gt; This code would be added to my base handler class, do a<br>
&gt;&gt; !exchange.isInIoThread() check, set the error handler, then call the<br>
&gt;&gt; handleRequest method.  The caveat here is that I can only do this for<br>
&gt;&gt; handlers that I have control over, not built-in handlers that dispatch to<br>
&gt;&gt; worker threads such as the AuthenticationCallHandler.<br>
&gt;&gt; Use an AspectJ-based approach where I create an @Around advice that executes<br>
&gt;&gt; for all of my handlers that will wrap the execution in a try-catch, and take<br>
&gt;&gt; care of the error handling.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Are there best practices for handling this?<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Thanks,<br>
&gt;&gt;<br>
&gt;&gt; Jared Wolinsky<br>
&gt;&gt;<br>
&gt;&gt; Senior Software Engineer, MLB Advanced Media<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; **********************************************************<br>
&gt;&gt;<br>
&gt;&gt; MLB.com - Where Baseball is Always On.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; undertow-dev mailing list<br>
&gt;&gt; <a href="mailto:undertow-dev@lists.jboss.org">undertow-dev@lists.jboss.org</a><br>
&gt;&gt; <a href="https://lists.jboss.org/mailman/listinfo/undertow-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/undertow-dev</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; **********************************************************<br>
&gt;<br>
&gt; MLB.com &lt;<a href="http://mlb.com" rel="noreferrer" target="_blank">http://mlb.com</a>&gt; - Where Baseball is Always On.<br>
&gt;<br>
<br>
_______________________________________________<br>
undertow-dev mailing list<br>
<a href="mailto:undertow-dev@lists.jboss.org">undertow-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/undertow-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/undertow-dev</a><br>
</div></div></blockquote></div><br></div>