This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-10-31
Channels
- # aleph (12)
- # announcements (4)
- # asami (7)
- # babashka (20)
- # beginners (92)
- # calva (74)
- # clj-kondo (8)
- # cljdoc (70)
- # clojure (47)
- # clojure-dev (29)
- # clojure-europe (27)
- # clojure-nl (7)
- # clojure-norway (3)
- # clojurescript (7)
- # cursive (2)
- # datomic (1)
- # emacs (8)
- # events (5)
- # fulcro (36)
- # gratitude (4)
- # humbleui (25)
- # introduce-yourself (1)
- # lsp (26)
- # malli (6)
- # missionary (8)
- # nbb (50)
- # off-topic (9)
- # pathom (2)
- # pedestal (3)
- # portal (32)
- # practicalli (5)
- # reitit (5)
- # releases (1)
- # ring (6)
- # shadow-cljs (87)
- # sql (31)
- # tools-deps (26)
- # vim (3)
- # xtdb (15)
I'm using the ::runner/wrap-resolver-error
plugin with lenient mode so that I can have warning logs when attributes do fail:
(-> (pci/register {:com.wsscode.pathom3.error/lenient-mode? true}
registry)
(p.plugin/register {::p.plugin/id 'err
:com.wsscode.pathom3.connect.runner/wrap-resolver-error
(fn [_] (fn [env node error]
(log/warn {::pathom-error error
::pathom-env env
:msg
(format "Error resolving attribute '%s': '%s'."
node
(ex-message error))})))}))
I'm noticing that on attributes that fail outright (ie with exceptions) this log statement gets triggered, but surprisingly attributes with {:com.wsscode.pathom3.error/cause :com.wsscode.pathom3.error/attribute-unreachable}
does not go through this "resolver-error" fn.
Is this intended behaviour? If so, why?yes, this is currently by design, but up for debate, what you think about opening a discussion (https://github.com/wilkerlucio/pathom3/discussions) so we can talk more about it?