Clojurians Log v2
pedestal 2026-01-05
What's the right way to map exception to another without handling it?
Let's say I use io.pedestal.interceptor.error/error-dispatch and I match to an error from a certain interceptor that I want to map to another.
My first thought was to create a new ex-info and throw it. Pedestal would then catch it, wrap it, and keep the execution in the error stage. But that's not right, https://github.com/pedestal/pedestal/blob/5d47615db2a1e24ac493e889c80e00fd710a6fa3/interceptor/src/io/pedestal/interceptor/chain.clj#L147.
My second thought was to just (assoc ctx :io.pedestal.interceptor.chain/error (ex-info my-new-ex-data-here)). This keeps the execution in the error stage, but now the exception is not wrapped anymore. I have other interceptors down the line that rely on the exception being wrapped.
So the best idea I have is to take the "old" wrapped exception and manually create a new "wrapped" exception of my own using the data from the old wrapped exception and my new exception. Is that the way to do it? Feels a bit clumsy. So I'm asking if there's an easier way I have missed.
This seems like a legitimate use case that may not be covered in the existing code base. My gut reaction is that after invoking the :error callback, Pedestal should identify that there is a different Exception in the error key and should wrap that exception as originating in the interceptor just invoked.
I think so too
Though I'm not sure about this part:
> as originating in the interceptor just invoked
In my case, I have:
1. Validation interceptor that uses 3rd-party validation library (this is the interceptor that throws originally)
2. error-dispatch that maps validation library exception to my generic "invalid params" exception
3. Error handler that handles the exception by turning my generic "invalid params" exception -> {:status 400}
To me if feels that the newly wrapped exception should keep the validation interceptor as the origin