Hacker News Reader

Comment by rhizome31 | Hacker News Reader

This is great news: Line number and filename information are now included in exception backtraces

I have just subjected my coworkers to some happy shouting and a jaunty little dance over this news.

This has literally cost me man-days of lost productivity over the years I've been working with Erlang, and it just never made sense to me. Sure, compilers are hard, etc etc, but this is a basic thing. I've seen toy languages implemented as a proof-of-concept that will never see the light of day that managed to output line numbers with their errors. It's part of most "Baby's First Compiler" tutorials.

Yes! Although the absence of line numbers forced you to think through (in some cases) related code as well as the code that generated the error :)

For those of you stuck with R14B or earlier, Thomas Lindgren's smart_exceptions library will add line number information to exception backtraces: https://github.com/thomasl/smart_exceptions

When this was announced at EUC in Stockholm there was this palpable feeling of relief.

I had just spent hour wresting with a bug in a fn with many case clauses where the line number would have been fantastic...

Yes! I seriously thought it wasn't possible for some unknown FP related issue.

You will have incomplete stacktraces; tail calls will be removed from the stack trace. However, you'll be able to know where in the current call (and file) the error lies, which was a big problem in Erlang as soon as you had somewhat lengthy functions.

Why didn't they add this before? Lack of time to develop it, or no requests from developers wanting it? I find the latter hard to believe, and the former to be a more likely cause.

Slightly paraphrased quote that I read somewhere: writing a compiler is easy. Writing a compiler with good error messages is the hard part.

Because it isn't that useful in Erlang, so the want to have it has not been that big. Most (proper) Erlang programs happen to be a lot of small functions and you know what function caused the error and the error type to boot in addition.

This information is often enough to quickly figure out what is wrong. The trouble arises when you have a large function you did not break up yet because then finding the culprit is much harder.

While I like the change, there is a risk associated with it. Namely that people will be less inclined to break up their code.

Reply on news.ycombinator.com