This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-09-28
Channels
- # babashka (167)
- # beginners (91)
- # calva (24)
- # chlorine-clover (5)
- # cider (14)
- # clj-kondo (15)
- # cljdoc (20)
- # clojure (122)
- # clojure-czech (1)
- # clojure-europe (31)
- # clojure-france (2)
- # clojure-nl (5)
- # clojure-spec (8)
- # clojure-uk (7)
- # clojurescript (29)
- # conjure (2)
- # cursive (4)
- # data-science (4)
- # datomic (13)
- # figwheel-main (13)
- # fulcro (21)
- # lambdaisland (4)
- # meander (10)
- # observability (7)
- # off-topic (15)
- # overtone (4)
- # pathom (5)
- # pedestal (6)
- # re-frame (9)
- # reitit (13)
- # remote-jobs (2)
- # ring (1)
- # rum (5)
- # shadow-cljs (24)
- # spacemacs (19)
- # test-check (18)
- # tools-deps (82)
- # tree-sitter (1)
- # xtdb (35)
@eyaldocs do you mean core/frontend or the backend coercion? will answer for both: • frontend: easy to add non-throwing variant • backend: few things to do: 1) ensure we use fast-throwing exceptions (e.g. no stack traces) 2) can add a non-throwing variant, BUT the invalid coercion response would need to be identified by all other middleware in chain as “non-success-case”. If you have a middlware that starts a transaction and coercion fails after it, that mw should rollback in case of coercion error.
Thanks @U055NJ5CC! I was referring to the backend. Do you have an example for this? (fast throwing exceptions and non-throwing variant)
filling the stack trace is really slow. Coercion could have a custom Exception type, without filling the stack trace: https://www.atlassian.com/blog/archives/if_you_use_exceptions_for_path_control_dont_fill_in_the_stac
> BUT the invalid coercion response would need to be identified by all other middleware in chain as “non-success-case”. If you have a middlware that starts a transaction and coercion fails after it, that mw should rollback in case of coercion error.
need to solve that first. there is no non-throwing-raise in ring spesification, have to invent such.
the stackless custom coercion exception needs to be added to reitit itself, Issue/PR welcome.
Yes, adding a middlware that identifies the failure is not an issue. Isn't there an option in reiit where I can customize the coerce middleware not to throw the excetopn, just mark it as failed on the request (for example). Then. in a separate middleware, I can check for that flag and act accordingly
async-ring doesn’t have to throw, you can just create an exception (without the stack trace) and pass it into to raise
handler => just an object.
did you run the coercion flamegraphs with malli? happy to optimize the perf on that, Some things in mind: 1. derive optimized Jackson parser from malli schemas => parsing & coercion in single step, we can select just the data needed => 3+ steps less in transformations, less garbage 2. control reitit coercion key keywordization from coercion impl => now re-keywordizating all map-bodies 3. don’t throw on error, optimized responses