This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-03-28
Channels
- # aws (1)
- # beginners (30)
- # boot (7)
- # cider (52)
- # clara (91)
- # cljs-dev (33)
- # cljsjs (1)
- # clojure (447)
- # clojure-brasil (3)
- # clojure-dev (16)
- # clojure-dusseldorf (5)
- # clojure-filipino (1)
- # clojure-italy (29)
- # clojure-sanfrancisco (5)
- # clojure-spec (62)
- # clojure-uk (37)
- # clojurescript (145)
- # clojurewerkz (1)
- # code-reviews (12)
- # community-development (157)
- # cursive (5)
- # datascript (1)
- # datomic (27)
- # editors (42)
- # emacs (5)
- # fulcro (31)
- # hoplon (2)
- # jobs (2)
- # keechma (1)
- # lumo (31)
- # off-topic (2)
- # om (1)
- # onyx (13)
- # parinfer (8)
- # re-frame (13)
- # reagent (32)
- # remote-jobs (4)
- # shadow-cljs (103)
- # spacemacs (15)
- # specter (10)
- # sql (1)
- # tools-deps (35)
- # unrepl (13)
Not yet, which section in particular?
I think Stu really nailed it, you need the form and the exception to do anything useful about messages
Yeah it's interesting how error messages are perceived as a regression from 1.8
I feel like unravel and other unrepl clients could really help here by giving collapsed-by-default expandable errors
The nitty gritty detail (deep stacktraces, complete spec errors) is hidden by default but it's all there if you need it
I've never understood stack trace woes, they make a lot of sense to me. But spec errors are opaque to me. I've no idea how to solve that even for my environment.
Traditional stack traces are noisy/verbose but makes sense (except for the occasional lazy sequences putting the blame on the consumer)