This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-04-19
Channels
- # announcements (37)
- # aws (6)
- # babashka (12)
- # babashka-sci-dev (16)
- # beginners (83)
- # biff (10)
- # cider (14)
- # cljdoc (26)
- # cljs-dev (20)
- # clojure (123)
- # clojure-czech (9)
- # clojure-europe (26)
- # clojure-nl (4)
- # clojure-norway (20)
- # clojure-spec (7)
- # clojure-uk (6)
- # clojured (14)
- # clojurescript (28)
- # cursive (5)
- # datalevin (8)
- # datomic (3)
- # duct (6)
- # emacs (26)
- # events (2)
- # fulcro (7)
- # gratitude (1)
- # holy-lambda (19)
- # integrant (1)
- # jobs (2)
- # leiningen (8)
- # lsp (7)
- # nyc (1)
- # pathom (70)
- # re-frame (8)
- # reagent (15)
- # releases (1)
- # sci (8)
- # shadow-cljs (117)
- # testing (5)
- # tools-deps (11)
- # vim (5)
at https://youtu.be/dtGzfYvBn3w?t=6346 there is a slide, saying:
> • DO NOT use check
, instrument
or (turn on) assert
in production
> • they are for making sure your program works - use in advance
> • but spec can play a runtime role
> • validating inputs from external systems or users
The args conformance and exception throwing feature of instrument
seems like a very useful guard to have even for production code, especially, when it's checking relationships between the input arguments. It would help us pinpoint code-paths in our code, which is not covered by tests or specs.
Q1: what does "validating inputs from external systems or users" refer to?
using function :pre [...]
conditions?
what spec functions should i use, if not s/assert
?
it seems like that the unconditional s/assert* was made to be used in
:pre` conditions...
Q2: is there a way to do something like instrument
, but only for checking :args
, so i wouldn't need to repeat such logic as function :pre
conditions?
Q1: I would suggest using a construct like
(when-not (s/valid ::spec data)
(throw (ex-info "error in..." {:error-data error-data}))
because asserts (and pre-posts i think) can be disabled by various options to the JVM. Be explicit with your throws after validation.
Q2: I would not recommend using instrument
or pre
when validating input from users or other systems. Rather make this validation a separate step in the processing of data. The way to handle incorrect data can differ between various systems and sources of data.You can also use something like Failjure instead of throwing, but I think the general way is to make use of JVM exceptions
Re throw or not - it depends on how your application handles errors in inputdata. Usually this is very application specific. Usually it's not good to use exceptions for flow control.