pedestal

2020-05-17T03:05:42.121700Z

@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

1
2020-05-17T18:10:17.125800Z

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.

🔥 1
2020-05-18T22:57:58.127Z

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

2020-05-18T22:58:56.127200Z

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

2020-05-19T06:33:56.128100Z

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

2020-05-19T20:30:10.128400Z

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

👍 1