Fork me on GitHub
#error-message-catalog
<
2016-04-30
>
eggsyntax00:04:08

Cool, I’ll go that route for now.

tolitius00:04:52

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

eggsyntax00:04:00

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

tolitius00:04:15

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

tolitius00:04:15

might not even need the title then, yea

eggsyntax00:04:28

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

tolitius00:04:09

we are just shaping things up

tolitius00:04:13

with your help simple_smile

eggsyntax00:04:24

One other idea: maybe it’d be worth having a “java” subdir at the same level as “clj” and “cljs”.

yogthos00:04:04

yeah I think that makes sense

eggsyntax00:04:12

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

yogthos00:04:17

cause some exceptions will be interop specific

yogthos00:04:57

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

eggsyntax00:04:01

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

yogthos00:04:05

I think more hands on deck will definitely help simple_smile

eggsyntax00:04:45

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

yogthos00:04:57

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

eggsyntax00:04:10

Seems like a good idea.

yogthos00:04:47

ideally it would be nice to be able to parse the md files into structured data at some point

yogthos00:04:26

that would require that all files follow a strict format though, so prs would have to be curated with extra care

eggsyntax00:04:26

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.

yogthos00:04:56

yeah that would definitely be fancy simple_smile

eggsyntax00:04:02

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

eggsyntax00:04:20

Or just one way or another, make it available to people at the time they hit the error.

yogthos00:04:32

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

eggsyntax00:04:19

Absolutely. Could even give them an easy route to improving the situation by absorbing all or part of the project.

eggsyntax00:04:28

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

cfleming02:04:11

Yeah, I’m actually wondering whether the best solution would be a ClojureDocs style site with an API.

cfleming02:04:31

I’d love to be able to programmatically access the data from Cursive.

cfleming02:04:10

I haven’t thought much about it yet, but currently I’d have to parse all the markdown into some structure I could use.

cfleming02:04:07

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.

cfleming02:04:32

I could then use that to provide a suggested link to the user.

cfleming02:04:17

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.

eggsyntax02:04:12

“Cursive Clippy” would be highly amusing 😄

cfleming02:04:47

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

cfleming02:04:20

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

eggsyntax02:04:53

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

eggsyntax02:04:35

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.

cfleming02:04:39

The nice thing about having an api would be that submission could be automated from Cider/Cursive.

cfleming02:04:57

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

eggsyntax02:04:58

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.

eggsyntax02:04:15

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

cfleming02:04:41

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.

cfleming02:04:49

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

cfleming02:04:08

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

eggsyntax02:04:39

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.

cfleming02:04:06

It’s the next best thing, certainly.

eggsyntax02:04:46

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.

yogthos02:04:03

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

yogthos02:04:39

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

yogthos02:04:03

but even outside errors in the core, there are also library errors, and I think that’s just as important

yogthos02:04:13

and those can be fixed right now by the maintainers

yogthos02:04:47

so if there was an automated submission process, that would definitely help aggregate errors

yogthos02:04:16

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

eggsyntax02:04:32

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.

eggsyntax02:04:29

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.

eggsyntax02:04:32

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