Fork me on GitHub
#error-message-catalog2016-04-26
>
shaunlebron14:04:51

Hi Henry, …

We found a repo with an exceptions directory containing binary files that I think you guys built:


Maybe you can provide some context on this so Dmitri can make use of your data?

shaunlebron14:04:26

A quick refresher suggests that src/errors is the best directory for poking around. We deliberately avoided exactly matching errors, but error_dictionary.clj {Categories of errors}, dictionaries.clj {stracktrace type translations} and error_hints.clj {Suggestions based on the type of error} are useful to skim through. 

Running our code might be informative, but I apparently left that information out of the readme. If you want to see our version of an error, put an entire section of erroneous code in src/intro/may2015.clj (name is for historic reasons). You can also grab the exception object by serializing it (& etc) and then feeding it to errors.prettify_exception/prettify-exception.

shaunlebron15:04:31

This is really impressive stuff

shaunlebron15:04:41

Just looked at it

shaunlebron15:04:41

They have catalogued 51 error patterns with regex, and do auto-translation into clearer messages

cfleming23:04:11

I’ve been planning for a while to allow users to fix errors using their technique in the Cursive REPL.

cfleming23:04:22

Cursive could do it using code folding on the client side.

cfleming23:04:27

Since the REPL is actually pretty non-extensible when it comes to error handling, I’ll probably wrap all forms I send in a try/catch and then post-process any exceptions. Pretty much any exception coming from the compiler doesn’t need a stacktrace, they’re completely useless and quite scary.

cfleming23:04:35

I’d also like to try some kind of pattern matching on an error database to see if a more useful description could be provided to the user.