This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-12-10
Channels
- # adventofcode (54)
- # announcements (30)
- # asami (13)
- # aws (10)
- # babashka (16)
- # babashka-sci-dev (44)
- # beginners (95)
- # calva (63)
- # clara (10)
- # clj-kondo (3)
- # cljfx (6)
- # cljs-dev (7)
- # cljsrn (1)
- # clojure (68)
- # clojure-europe (59)
- # clojure-nl (7)
- # clojure-norway (12)
- # clojure-spec (6)
- # clojure-uk (6)
- # clojurescript (4)
- # component (4)
- # conjure (5)
- # datomic (3)
- # deps-new (1)
- # events (4)
- # exercism (1)
- # figwheel-main (1)
- # fulcro (33)
- # gratitude (1)
- # improve-getting-started (3)
- # jobs (3)
- # lsp (5)
- # malli (10)
- # membrane (5)
- # music (3)
- # nextjournal (6)
- # off-topic (42)
- # pedestal (2)
- # polylith (14)
- # portal (11)
- # re-frame (42)
- # releases (3)
- # reveal (4)
- # shadow-cljs (62)
- # tools-build (1)
- # tools-deps (3)
- # web-security (1)
- # xtdb (3)
Pedestal Interceptors design history question, was there a consideration for a :finally
/`:always` type of function that would be invoked after :error
or :leave
to focus specifically on clean-up of “opened” resources (e.g. db connection, file io, etc)? I know it could be covered by using the same function reference for both the :error
and :leave
key, but that potentially complects resource clean-up with error handling / post processing, compared to adding complexity/overhead on another exit path through the interceptor