Comment by Stratoscope | Hacker News Reader

Comment by Stratoscope | Hacker News Reader

20 years ago I was working on Acrobat at Adobe. I was mostly the "Windows guy" but also worked and tested on the Mac.

When I tried to install Acrobat on my Mac, I got this message:

"Your hard disk is too small"

My what is too small?!

Later, on Windows I got this unexpected popup:

"You are not here"

WTF?

I searched the code for that string and found it in a function named "CantHappen()". This function was called in numerous places where the programmer thought there was no possible way for the code to get to that place. But of course CantHappen() did happen.

As I looked through the code I found many other messages that were bizarre and incomprehensible and sometimes downright offensive.

So I started a project to go through all our messages and make them more clear and informative - and even better, when possible to not have the message at all but just take care of the situation.

The underlying cause of these bad messages was twofold:

1. Programmers never got raises for writing great error messages or finding ways to avoid them in the first place. We were just rated on how much work we got done.

2. We did have a product designer who was supposed to specify all user-facing messages. But the designer mainly considered the "happy path" and didn't think about edge cases. It was left to developers working under time pressure to handle those.

> Later, on Windows I got this unexpected popup: > > "You are not here"

The absolute best I had in a Microsoft product was this (paraphrasing): "An error happened because your computer may be turned off". I still have a screenshot of that somewhere. What it meant was that an hypothetical computer I may be trying to connect to (which I wasn't, it was all local) was off, but that wasn't the case. This was seriously WTF.

The second most beautiful one from another Microsoft product was whatever software generating a password and asking me, in a pop-up window, to write it down. The problem was the password was something like:

    9mZOvy9E(4)?6b(w(<$KcTU%>9T6cz0Z4YxgQ-<tw035X6S.dLE0[2n0"42`/S=S1{q5{)61s190':&6UHT.4hZXjO6b%l#X7v]~4tIT2Y0._ebFH,>2:G>%*P]7n4"

I probably also still have a screenshot of that somewhere.

Haven't used Microsoft stuff in two decades so it was a long time ago. But it's still seriously WTF.

The best error message on Windows is “The operation completed successfully”: https://www.google.com/search?q=the+operation+completed+succ...

…which is the text for result code zero, which is used to mean “no error”.

“Guru Meditation Error”

Long time ago I ran into a "catastrophic failure" in Word, which sounds quite serious.

There's also that hilarious Windows Phone error that prompts users to insert their Windows installation disc and restart their "computer".

The paradox of CantHappen is that if the programmer truly thought it can't happen then there would be no need for it in the first place. The only reason to include it is because of a fear that it may in fact happen.

Rust funny enough has unreachable()! for that case, but it also has unreachable_unchecked() for actually unreachable code. The latter has undefined behavior and exists to help the optimizer.

What does unreachable()! do actually? I had no idea that was a thing.

It terminates the program with panic!

https://doc.rust-lang.org/std/macro.unreachable.html

So is the usual flow to throw these in places where code shouldn't execute but then create tests to try and trip it up to see if that is truly the case? I would hate to be running a release build with this, or does the compiler do something different depending on build type?

> I would hate to be running a release build with this

The usual argument is that the program would be in an invalid state if the condition was reached, so the only option is to crash. If it turns out it's a valid state, then the programmer can treat in a branch. I don't think tests would capture this because they would operating under the same assumption that such states cannot exist. Maybe fuzzy testing could surface an issue like this.

Rust has a few of those, they all panic but with different default messages: panic!(), todo!(), unimplemented!(), and unreachable!()

I’m guilting of writing a “can’t happen” branch (as I’m sure many of us are).

I stripped it out before production after verifying it couldn’t actually happen but it was something like an artefact of my thinking process while writing the code.

It feels like a kind of assertion of underlying assumptions, and I know enough to know I’m fallible.

I’m always careful to make the error message something reasonable if it ever did actually come up in a tech demo or something though. Anything else is tempting the Fates.

I don’t understand why the message would be ‘Can’t happen’ in the first place.

I’d always make it something like “If you see this, something entirely unexpected went wrong.”

Showing and triggering the error is helpful in itself since it’ll generate a trace and all the attendant stuff.

"lp0 on fire" and "PC LOAD LETTER" are two good ones, too.

ESLint complains if no `default` option on `switch` statements. Sometimes it's not possible. I have been trained to add it regardless. While developing, I add some message like "not possible" and sure enough it hits once in a while in dev due to something I didn't consider.

Reply on news.ycombinator.com