Clojurians Log v2

Cool, I’ll go that route for now.

yea, if an exception / error already exists its cause (if different) should be just added to the .md

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”.

brings a good point that ## Cause should be plural from the start

might not even need the title then, yea

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).

yep

we are just shaping things up

with your help :simple_smile:

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”.

yeah I think that makes sense

@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.

cause some exceptions will be interop specific

I could also add you to the project if you're interested

Or may raise java exceptions, I think, even if not explicitly interop.

I think more hands on deck will definitely help :simple_smile:

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 :simple_smile:

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

Seems like a good idea.

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.

yeah that would definitely be fancy :simple_smile:

And/or there could be a “friendly message” section which could also get appended.

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.

yup

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’d love to be able to programmatically access the data from Cursive.

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 could then use that to provide a suggested link to the user.

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.

“Cursive Clippy” would be highly amusing 😄

I’m going to put a request up on 99 designs for some cute mascot :simple_smile:

“Hi, it looks like your stack is overflowing. Have you considered calling fewer functions?"

Hahaha! At this point I’m going to be really disappointed if that never happens.

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.

With a form for the fields we’d like information on.

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.

Automated submission from CIDER/Cursive would definitely be another big win IMO

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.

Sadly that doesn’t look like it will happen for Clojure.

At least the macro errors should be improved in 1.9, with a bit of luck.

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.

It’s the next best thing, certainly.

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.

( http://blog.cognitect.com/blog/2016/1/28/state-of-clojure-2015-survey-results#clj )

I still would like to keep pushing to improve compiler messages as well

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

and those can be fixed right now by the maintainers

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.

Probably not important or feasible until the project reaches the point of having several submissions for many of the errors.