Hacker News Reader

Comment by codeflo | Hacker News Reader

Some anecdotes where error messages truly delighted me:

When I accidentally misresolved a conflict after a git pull, the C# compiler, upon encountering the >>>>> markers in the source code, noted that there’s an unresolved merge conflict in that line instead of complaining about bitshifts.

When I tried to bitwise invert a value in Rust with “~x”, which is wrong, instead of complaining about an unknown character, the compiler helpfully explained that the operator to use in Rust is “!x”.

When I was in the Python interpreter and entered “exit”, which doesn’t work because exit is not a keyword, I got a message that told me how to actually exit.

View on HN

Apple’s MPW C compiler had some funny error messages, sometimes also useful. Examples:

- This label is the target of a goto from outside of the block containing this label AND this block has an automatic variable with an initializer AND your window wasn't wide enough to read this whole error message

- String literal too long (I let you have 512 characters, that's 3 more than ANSI said I should)

- Too many errors on one line (make fewer)

Whenever I read these again (e.g. on https://www.cs.cmu.edu/~jasonh/personal/humor/compile.html), I wonder what made ANSI pick 509 as the limit for the length of string literals.

> - Too many errors on one line (make fewer)

Thank god it wasn't a C++ compiler...

I have a love/hate relationship with C++, but some of those error messages are just awful. When it comes to template errors in C++, I almost never try to understand any of the gibberish and just look for the file and line where the error was originally reported. Which is a task in itself, since most of the time the file you actually care about is neither at the bottom nor at the top of the pile of files.

On the other hand, error messages other than template-related errors have improved in C++ lately.

Sometimes I gaze into the stars and wonder how many programming careers were ruined by nebulous "stack overflow", "null pointer exception" and "segmentation fault: core dumped" messages.

Talking about StackOverflow, shouldn’t all messages have a permalink to their StackOverflow unique identifier where people will discuss them ;)

A really evil programming language would give you an error code and a link to create a question on Stack Overflow asking what the hell it means.

Visual Studio already does almost this, if you hover over a Intellisense or Build error it will give you a link to search for it on Bing. Which is extremely helpful when the error is "Linker error".

https://docs.microsoft.com/en-us/visualstudio/ide/find-and-f...

Bus error. (i miss those pizza boxes)

And the all time favourite: "This programm has violated system integrity and must be terminated"

The best advice I've gotten on template error messages is that it's either at the top of the output or the bottom...then you've just gotta hope that your terminal has enough of a buffer to see the top[0] :)

[0] yes i know terminals support quasi-infinite scrollback by writing to a file, or i could redirect. but that makes for much less amusing anecdote.

“Unexpected friend” was one of my favorites in C++. It seemed fortuitous; it’s good to have friends, right? (Usually the actual error was a missing semicolon.)

Well, you have to define a buffer size for the lexer, for both avoiding dynamic allocations and avoid bowing your memory. A 512 bytes buffer can hold 509 ASCII characters, two quotes and a zero terminator.

I don't know why they did it, but the size makes a lot of sense.

But why would the lexer include the delimiting quotes in the token for a string literal?

You probably wouldn't. But a standard should allow the most possible kinds of usage, and there are some situation where it makes sense (like on transpilers).

> I wonder what made ANSI pick 509 as the limit for the length of string literals.

Just a guess: In a 512 byte block, a 509 bytes long string literal would leave room for a NUL terminator and a 16-bit length field (prefix).

> When I was in the Python interpreter and entered “exit”, which doesn’t work because exit is not a keyword, I got a message that told me how to actually exit.

This was something that one of those "Zen of Ruby" style articles brought up as a negative and although I'm not a Ruby person, I tend to agree. exit is not a keyword, but it is reserved so that you can get this message. Nobody can (or at least should) name a symbol exit, and alternative Python interpreters just turn "exit" into exit(). So why can't the normal interpreter do what I meant instead of being pedantic? It is generally user friendly in other cases (the new error messages in 3.10, for instance).

Because the built-in console doesn't support any special keywords or syntax. Other consoles already support special keywords and syntax, so it's no problem to interpret "exit" as one of those.

The context is good error messages; what you’re saying is that DWYM (do what you mean) is even better than a good error message. That’s sometimes true and can help beginners. But it also means more special cases and magic, which can make a language hard to learn in a different way. Python and Ruby are almost at the opposite ends of that trade-off, so it shouldn’t be surprising that a Ruby person doesn’t like Python’s solution.

Also, and this is really off-topic, I also completely disagree that the names of built-in functions are off limits in a program, or should effectively be keywords. I'm not saying it's particularly wise to name a variable "print" or something. But should I learn by heart the names of all built in functions before naming any variable? Should I refactor my program whenever a new one is added? Resolving those kinds of conflicts is what scoping is for, and it works.

> The context is good error messages; what you’re saying is that DWYM (do what you mean) is even better than a good error message.

I'm not sure that's true. "Just do what I mean" is an understandable response when you get an error message that hints that the program knew exactly what you meant. It feels like a human responding to "Can I have some water?" with "I don't know CAN you?", but it ignores the fact that the program doesn't really know what the user meant. Sure whoever authored the Python interpreter guessed that 99% of the time if you type `exit` you want to leave, but if they just assume that, then what happens if I'm actually trying to see what's in a variable `ext` (short for extension) and my fingers just auto completed `exit` because it's something I type so frequently (this kind of typo happens to me all the time). Suddenly the interpreter is dead and I have to start over on whatever I was doing.

I'd actually rather the program gives me instruction on how to what it thinks I want to do, and let me decide if it's really what I mean.

> exit is not a keyword, but it is reserved so that you can get this message.

`exit` is not reserved. It's a callable implemented in pure Python [1] injected into the local scope when in interactive mode. There's no special functionality associated with it—The error message is implemented using the standard `__repr__` behavior. You are free to override the value of `exit` if you so choose.

"Special cases aren't special enough to break the rules."

[1] https://github.com/python/cpython/blob/06b8f1615b09099fae5c5...

Learn something new every day. I hadn't thought to check, just figured it was reserved since iPython used it fine.

Thanks for the correction.

> When I was in the Python interpreter and entered “exit”, which doesn’t work because exit is not a keyword, I got a message that told me how to actually exit.

This happened to me too once, and I was also delighted. It simultaneously teaches you how to supply an EOF to anything that's reading your input off the command line.

But I've seen people scream about how obnoxious it is that the python shell knows what you want to do, and then lectures you about how to do it properly instead of just doing it for you. I don't understand those people.

I still harbor a certain fondness for "'long long long' is too long for GCC", which is superficially a bit silly while also subtly acknowledging that an ISO-conformant C compiler could support "long long long" as an implementation-defined type.

I think clang got support for detecting unresolved merge conflicts around a decade ago too.

Reply on news.ycombinator.com