Fork me on GitHub

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?


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.


This is really impressive stuff


Just looked at it


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


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


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


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.


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.