@jdkealy Pedestal wraps all exceptions thrown by interceptors in an ExceptionInfo
. You can either get the cause off the thrown ExceptionInfo
pull it out of the ex-data
using the :exception
key. The joining of interceptor name and original message is not configurable. For additional attrs in ex-data, see http://pedestal.io/reference/error-handling
Hey. I also have a question about exceptions. In a ‘normal’ synchronous interceptor I can just raise (or not catch) exceptions, and they’ll eventually end up in an :error
interceptor. However, I can’t figure out what to do with exceptions occuring in asynchonous interceptors. The docs say they should return channels with context maps, and that exceptions are put in ::chain/error
in the context map wrapped in an ExceptionInfo
, but I am struggling to find out how to create such a wrapped exception to put in the context in my asynchronous interceptor.
Hi @lennart.buit, assoc an ex-info wrapping your exception to the context using the :io.pedestal.interceptor.chain/error
key. You can add the ex-data specified in http://pedestal.io/reference/error-handling#_error_function if you are dispatching on that info in a generic error handler. Currently the code which converts an exception to a wrapped exception is private and not part of the public api.
@lennart.buit
Not all the ex-data is required. It depends on what you are dispatching on. The ::chain/execution-id
is on the context but the stage
is not. You do, however, know the stage so can add that if necessary
Okay, I’ll do that then. Thank you for answering 🙂
Works like a charm :thumbsup: , can provide basically the same ex-data as pedestal would! Thanks again