This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (3)
- # arachne (8)
- # beginners (5)
- # boot (52)
- # braveandtrue (4)
- # cider (17)
- # cljsrn (1)
- # clojure (36)
- # clojure-dusseldorf (2)
- # clojure-india (1)
- # clojure-russia (30)
- # clojure-uk (1)
- # clojurebridge (1)
- # clojurescript (47)
- # clojutre (1)
- # component (1)
- # core-async (3)
- # cursive (5)
- # datascript (1)
- # datomic (4)
- # emacs (1)
- # error-message-catalog (62)
- # garden (3)
- # hoplon (16)
- # jobs (5)
- # luminus (11)
- # mount (1)
- # om (32)
- # onyx (17)
- # spacemacs (4)
- # untangled (20)
- # yada (4)
yea, if an exception / error already exists its cause (if different) should be just added to the
That would mean that
## [Title] and
### Error Message are essentially the same thing, and should maybe be collapsed into one thing — unless the idea is that title be an informal description of the precise exception named in “error message”.
Note also that the example page suggested in the readme (namely https://github.com/eggsyntax/clojure-error-message-catalog/blob/master/lib/mount/derefablestate-cannot-be-cast-to-ifn.md ) follows the other pattern (assuming there can be other causes of that error, and I would somewhat expect so).
we'll need to update this: https://github.com/yogthos/clojure-error-message-catalog#error-file-format
One other idea: maybe it’d be worth having a “java” subdir at the same level as “clj” and “cljs”.
@tolitius: oh, totally, I’m expecting everything to be rough, I just thought I’d contribute one right away, and pointing stuff out as I see it.
Sure, by all means add me! My availability to contribute will be pretty intermittent, but I think it’s an excellent idea and I definitely want to help out at least a bit
it would probably be good to look at the exceptions we've got in a week or so, and take another look at how to classify them
ideally it would be nice to be able to parse the md files into structured data at some point
that would require that all files follow a strict format though, so prs would have to be curated with extra care
For sure. And yeah, I think that’s where this starts to really pay off big — could have a lein plugin, for example, that appends a link to the appropriate page to every error thrown.
Or just one way or another, make it available to people at the time they hit the error.
another nice side effect would be that it could help inform clojure core team as well as library maintainers on what's tripping people up
Absolutely. Could even give them an easy route to improving the situation by absorbing all or part of the project.
Went ahead & created a PR from my fork for now; would appreciate any feedback. Thanks! https://github.com/yogthos/clojure-error-message-catalog/pull/15
Yeah, I’m actually wondering whether the best solution would be a ClojureDocs style site with an API.
I haven’t thought much about it yet, but currently I’d have to parse all the markdown into some structure I could use.
Another thing that might be interesting (not sure how useful/general it would be though) would be to be able to indicate which frame in the stacktrace is actually responsible for the error, if that can be determined.
I’ll look at that Scala page when I get a chance, since I’d like to do a clippy-style thing by pattern matching over known errors.
“Hi, it looks like your stack is overflowing. Have you considered calling fewer functions?"
As far as I understand, btw — I just ran across the project today myself — the idea for the moment is to have a submission format that makes it as easy as possible for people to add new exception pages, while still being formalized enough (w/ fixed section titles) to later parse into something more easily machine-readable.
There’s some discussion of that in https://github.com/yogthos/clojure-error-message-catalog/issues/6
The nice thing about having an api would be that submission could be automated from Cider/Cursive.
One big win on the Scala Clippy project is having a website to make submissions even easier (& could use several separate form fields to ensure format-correctness). I’m definitely hoping that’s where this project will end up going.
Yeah, I think that will become necessary. It’s not so critical for the Elm project because they’re manually looking at cases, and actually fixing them in the compiler.
If most of the tooling around clj/s can offer friendlier error messages on request, derived from this project, I think that’ll be nearly as useful as getting them into the compiler.
In the 2015 State of Clojure survey, on the question "What has been most frustrating or has prevented you from using Clojure more than you do now?," "Error Messages” was by far the most common answer, so clearly the need is pretty great.
Alex mentioned that he’s working on that for 1.9 release, so I’m looking forward to that, but I think that needs to be an ongoing effort
but even outside errors in the core, there are also library errors, and I think that’s just as important
so if there was an automated submission process, that would definitely help aggregate errors
it would be really nice to be able to count duplicate submissions as well, that way you could see what errors people get tripped up on most often
Seems like it might be worth bringing Alex’s attention to this project soon, in case there’s some coordination step that would make (possible) integration into core easier at some future date.
One cool idea the Scala folks had (not for immediate implementation, but long-run) was to show all duplicate answers in one place & let them be voted up or down, stack-overflow-style. That could leave room for answers to get better & better without a lot of attention from project devs.