Fork me on GitHub
#pedestal
<
2020-05-17
>
ddeaguiar03:05:42

@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

4
Lennart Buit18:05:17

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.

🔥 4
ddeaguiar22:05:58

Hi @UDF11HLKC, 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. @UDF11HLKC

ddeaguiar22:05:56

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

Lennart Buit06:05:56

Okay, I’ll do that then. Thank you for answering 🙂

Lennart Buit20:05:10

Works like a charm :thumbsup: , can provide basically the same ex-data as pedestal would! Thanks again

👍 4