This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-01-01
Channels
- # announcements (2)
- # aws (27)
- # beginners (67)
- # boot-dev (1)
- # cider (25)
- # cljs-dev (6)
- # clojure (192)
- # clojure-europe (1)
- # clojure-gamedev (1)
- # clojure-italy (4)
- # clojure-nl (2)
- # clojure-russia (1)
- # clojure-spec (9)
- # clojure-uk (12)
- # clojurescript (41)
- # cursive (1)
- # datomic (22)
- # figwheel-main (4)
- # funcool (1)
- # hoplon (1)
- # kaocha (11)
- # klipse (7)
- # off-topic (1)
- # overtone (1)
- # pathom (24)
- # portkey (9)
- # re-frame (129)
- # reagent (3)
- # rum (1)
- # spacemacs (1)
- # specter (6)
@richiardiandrea Isn't the concern there more than you need to not display ex-data
values "as-is" to anyone?
It would be the same as any other ex-info
you throw -- it could well include sensitive data in some context...
that's a tough one, because then my display thing needs to know about what is displaying
aka, I need to call dissoc
on things, maybe it should
I wouldn't expect production code to just display any spec failure as is -- those exceptions are intended for code, not humans, and certainly not end users.
FWIW, our application error logging/reporting code has always contained logic to strip known, sensitive fields from any data logged or reported, long before spec was a thing...
ok yeah maybe that's something I would need to do anyways
I wonder though if things change ...say the string for password changes now I need to change spec AND dissoc
@richiardiandrea That's a good reason to use a globally-unique qualified key name 🙂