This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-11-01
Channels
- # announcements (3)
- # babashka (20)
- # beginners (77)
- # calva (27)
- # cider (5)
- # clara (3)
- # clj-kondo (9)
- # cljs-dev (4)
- # cljsrn (5)
- # clojure (26)
- # clojure-europe (32)
- # clojure-italy (5)
- # clojure-nl (3)
- # clojure-uk (5)
- # clojurescript (25)
- # clojureverse-ops (4)
- # core-async (49)
- # cursive (15)
- # data-science (1)
- # datahike (4)
- # datomic (3)
- # docker (1)
- # events (1)
- # helix (5)
- # holy-lambda (3)
- # introduce-yourself (1)
- # jobs (1)
- # kaocha (2)
- # lsp (15)
- # malli (42)
- # off-topic (18)
- # pathom (18)
- # pedestal (12)
- # polylith (7)
- # rdf (1)
- # re-frame (22)
- # reitit (2)
- # releases (1)
- # remote-jobs (1)
- # rewrite-clj (33)
- # shadow-cljs (85)
- # spacemacs (3)
- # vim (12)
- # xtdb (29)
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?
You can have a look at the error-dispatch
interceptor: https://github.com/pedestal/pedestal/blob/d20065013abf5d3793ae5301e18a2398707fa2a9/service/test/io/pedestal/interceptor/error_test.clj
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)
.
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 howYou'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.
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)