Fork me on GitHub

Hi, I have a function throw an error and I reckon that my error-interceptor is the one that gets the last say on what happens. Are there idiomatic or preferred ways to have the error-interceptor return a particular {:body "" :status 200} for errors that are anticipated?


In your case, it sounds like your error-interceptor should either process the exception by returning (assoc ctx :response {:body "" :status 200}), or signal that it can't by returning (assoc ctx :error ex).


Okay cool, I will try that. ty

😀 1

Pedestal addresses this by catching all exceptions thrown from an interceptor. It wraps the exception in an ExceptionInfo instance which is then bound to the :io.pedestal.interceptor.chain/error key in the context map.

As long as there is an error attached to that key, Pedestal will not invoke the usual :enter and :leave functions. Instead, it looks for the next interceptor in the chain that has a :error function attached to it.
So there's :enter :leave and also :error I want to return a 200 on a certain "error" but I'm still having a little trouble sussing out how


You'll want to enqueue an interceptor high enough up in the chain to catch any potential errors. This interceptor only needs an :error function


This function has only one responsibility: Given a context and an exception, either handle the exception or pass it on


I think it's important to understand that when an error is thrown, the rest of the enqueued interceptors are dropped, and we start going up the stack of previously visited interceptors. Maybe the documentation doesn't make this 100% clear.


If you want to share some code we can walk through this together 🙂


I think it makes sense, I would have preferred a graphical explanation 😅


Oh hey, I figured it out.


I really appreciate you taking the time to point me in the right direction. I was close but I needed a better understanding of ex-info and catching it in the right interceptor (we have 2 error interceptors, for different endpoints)