First, I don’t work for Google, so I have not had my sense of humor removed.
Still, a much better message would be “E3141 - HODIE NATUS EST RADICI FRATER”. That is, it has a clear, searchable link to where there might be random detailed information, or even ramblings. It is a mistake that each detectable, obscure, arcane error needs a professionally produced tome. The tome can be accumulated if the error ever occurs.
I really would like to add numbered errors to my programs to make them easy to look up. I still wonder what can make it a relatively low-maintenance task, though.
Someone like Oracle can just throw more human-hours at the problem, I can’t.
It doesn’t have to be hard. I just keep a text file that lists all the errors (and their numbers). I picked up the idea from a previous job where we had over 1,000 different number errors. Not hard to keep it up once started.
You could represent all errors in your program as variants of a given type, and then implement an error_code() method on that type that forces each error variant to have a unique code. In Rust this might look like:
The usual issue is growing that list. Protobuf uses that approach and for something that will have to remain stable and thus should be carefully designed before you release it to other people, but error conditions are naturally dynamic.
Then I realize that there can also be permissions issues and now I need to add PermissionDenied. If I add it between FileNotFound and UserError, I’ll have to change all error codes after it, so the error message formatting and the manual will have to change as well. If I add it at the end, it’s no longer grouped with other IO errors.
One possible approach is to leave gaps and make it like:
If I add it at the end, it’s no longer grouped with other IO errors.
This is only a problem if your error codes are hierarchical identifiers whose first digits are categorical and whose latter digits are the specific error. But it’s not clear that that’s a desirable property in the first place: errors can fall into multiple categories, and with enough errors you’re likely to end up with a “misc” category anyway.
The point of the error code is to be a direct index to the error. If you want to generate documentation where error codes are grouped by topic, you can do that. You could even list the same error code in multiple sections if it’s relevant to multiple. The code number itself is arbitrary.
You are thinking too hard. If you get away from ‘32 bit integer’, you could just use a dotted number. Every single call to an error routine should have a separate number and it can be in random order. If I have a group of “324 Input Address Validation Failure”, I can have “324.952 Zip code neither 5 nor 9 letters” That should correspond to one place in the code, and, if anyone cares, have any unique troubleshooting above and beyond the “324.*” page.
I really would like to add numbered errors to my programs to make them easy to look up. I still wonder what can make it a relatively low-maintenance task, though.
I ended up with codes, not numbers: “system-something”. For example: “contact-notfound”. Easy to grep for, and having the code tells me the error already.
I’m so tired of this kind of humor. When an error message comes up, I am already in a stressful situation. The last thing I want in that case is another riddle on top.
The programmer who put a Latin error message in that place apparently cared more about their own fun than about the other people who have to deal with it.
Then again, maybe (probably) I’m complaining unfairly. First of all, I have no idea how often thing like Latin error messages were put in the code. And the linked page at least does not indicate that the afflicted technicians appreciated this humor; so maybe everyone else was as tired of this back then just as I am today.
Second, that XKCD comic (and many others) shows again that nerds can be humble and self-reflective; and given XKCDs popularity it probably even educates people to this nicer behavior. That’s a nice progression from the seventies to today.
I dunno, seems easy enough to say something like “SSTN recovery code had a brother pointer at the bottom of the tree when it was finished, this should never happen”. That’s a longer message to shove into the code, sure, but you could always just give it an error code and print it in the manual.
A good error message for the user should give at least some hints about possible further steps. There’s certainly a “spectrum of helpfulness” depending on how much the program knows about its environment and how many external factors are involved:
No space left on device — free up some space on the device.
Unrecognized option --forbnicate, did you mean --frobnicate — correct the typo.
Unrecognized option --frobnicate — check the docs for option syntax.
File not found — check if you point the program at the right path, or check why the file is not created where you expect it.
ICMP host administratively prohibited — this is a network problem, caused by a policy, you should check the configs or contact the network admin.
Connection reset by peer — uhm, try to reconnect maybe, but at least you can be certain it’s not a problem on your side.
Beyong that there’s basically the “check the source code or contact the developer” territory. Say, assertion error: the system has a negative number of logged in users. The only way it can happen is if there’s a flaw in the program logic.
And then there are problems like the duplicate root pointer. From that article, my impression is that no one understood how and why that condition could occur or what exactly a possible fix could be, so a message that didn’t need translation from Latin wouldn’t bring the user any closer to a solution. In that situation, the only thing people can do it either contact the developer or grep the source code for the error, and for that purpose, any unique message is as good as any other.
Yes, the HODIE NATUS EST RADICI FRATER error message was a “an impossible situation” from Multics’ point of view. As it turns out, the problem was in the hardware; specifically the system had been mis-configured in such a way the the root disk appeared twice as distinct physical devices. Thus the “brother” is a second root disk, a situation which cannot arise as part of the Multics software configuration; and lack of debugging guidance from Multics is quite understandable.
Obviously here the error can’t say exactly how to fix the issue but the fact that 2 teams had to grasp at straws should be all the proof you need that it should state the “impossible” situation clearly. That would’ve narrowed what to look at for them, just like the phone call did.
And nothing prevents you from having the joke and then a real message.
Warning: Very, very long. But also very, very good. Don’t bother clicking on the link if you are in a rush. Set aside half an hour or so to read everything; to look at all the details.
I’m less concerned about topicality in this case (we have fun little trivia posts sometimes, and as long as they don’t overwhelm the queue I’m fine with it; we all need a little whimsy in our lives), but I am concerned that the poster seems to almost entirely post their own content.
Looking at their posting history it’s pretty lopsided.
I think all of those examples can answer ‘yes’ to at least one of the questions for at least some Lobsters readers. (If you’re dealing with upgrade compatibility issues for a platform you develop; if you’re interested in programming languages or systems in the niche of Gleam; if you’re building LLM-based systems; if you maintain any kind of system that has a CAPTCHA-type access control).
It’s funny, I wouldn’t have flagged this story as off-topic, but I did flag the Half Life documentary you posted as off topic. I feel like this story is on topic because it explains a weird error message, while the Half Life documentary did not give me technical insights about building or running software. What makes you feel the Half Life documentary is more on-topic?
(To be fair, while I think this story is on topic, I also feel it’s not very good.)
(To be fair, while I think this story is on topic, I also feel it’s not very good.)
I felt the same way about it. I think some exposition about __builtin_unreachable and why we might want that in release builds but something different in debug builds could have made it a good article.
But my take was “on-topic, but not very good,” which led to neither a vote nor a flag from me. It’s certainly about computing, even if it doesn’t meet those rules of thumb for a “good” submission.
As a ‘making-of’ documentary I think it’s interesting and on-topic to anyone who does game development, even as a twenty-years-later retrospective – in particular because it’s about a game that has been so massively influential. Sure, there’s a lot in it that isn’t on-topic in that sense (I don’t think an entire documentary about the Valve/Vivendi lawsuit would be on-topic), but also a lot that is. It interested me even though I’ve never done any game development (but I’ve been curious about it for a long time).
MULTICS has a hard to interpret but descriptive error message for the extremely unlikely situation when the system ended up with two root volumes.
I’m not sure if it could be made actually easier to interpret.
First, I don’t work for Google, so I have not had my sense of humor removed.
Still, a much better message would be “E3141 - HODIE NATUS EST RADICI FRATER”. That is, it has a clear, searchable link to where there might be random detailed information, or even ramblings. It is a mistake that each detectable, obscure, arcane error needs a professionally produced tome. The tome can be accumulated if the error ever occurs.
I really would like to add numbered errors to my programs to make them easy to look up. I still wonder what can make it a relatively low-maintenance task, though.
Someone like Oracle can just throw more human-hours at the problem, I can’t.
It doesn’t have to be hard. I just keep a text file that lists all the errors (and their numbers). I picked up the idea from a previous job where we had over 1,000 different number errors. Not hard to keep it up once started.
You could represent all errors in your program as variants of a given type, and then implement an
error_code()method on that type that forces each error variant to have a unique code. In Rust this might look like:And then you’d simply use this
Errortype pervasively throughout your code to return errors.The usual issue is growing that list. Protobuf uses that approach and for something that will have to remain stable and thus should be carefully designed before you release it to other people, but error conditions are naturally dynamic.
Suppose I started from something like this:
Then I realize that there can also be permissions issues and now I need to add
PermissionDenied. If I add it betweenFileNotFoundandUserError, I’ll have to change all error codes after it, so the error message formatting and the manual will have to change as well. If I add it at the end, it’s no longer grouped with other IO errors.One possible approach is to leave gaps and make it like:
Then I can add
PermissionDeniedas error code 102. Not a zero maintenance approach but might be serviceable enough to try…This is only a problem if your error codes are hierarchical identifiers whose first digits are categorical and whose latter digits are the specific error. But it’s not clear that that’s a desirable property in the first place: errors can fall into multiple categories, and with enough errors you’re likely to end up with a “misc” category anyway.
The point of the error code is to be a direct index to the error. If you want to generate documentation where error codes are grouped by topic, you can do that. You could even list the same error code in multiple sections if it’s relevant to multiple. The code number itself is arbitrary.
You are thinking too hard. If you get away from ‘32 bit integer’, you could just use a dotted number. Every single call to an error routine should have a separate number and it can be in random order. If I have a group of “324 Input Address Validation Failure”, I can have “324.952 Zip code neither 5 nor 9 letters” That should correspond to one place in the code, and, if anyone cares, have any unique troubleshooting above and beyond the “324.*” page.
I ended up with codes, not numbers: “system-something”. For example: “contact-notfound”. Easy to grep for, and having the code tells me the error already.
I’m so tired of this kind of humor. When an error message comes up, I am already in a stressful situation. The last thing I want in that case is another riddle on top.
The programmer who put a Latin error message in that place apparently cared more about their own fun than about the other people who have to deal with it.
Then again, maybe (probably) I’m complaining unfairly. First of all, I have no idea how often thing like Latin error messages were put in the code. And the linked page at least does not indicate that the afflicted technicians appreciated this humor; so maybe everyone else was as tired of this back then just as I am today.
Second, that XKCD comic (and many others) shows again that nerds can be humble and self-reflective; and given XKCDs popularity it probably even educates people to this nicer behavior. That’s a nice progression from the seventies to today.
I dunno, seems easy enough to say something like “SSTN recovery code had a brother pointer at the bottom of the tree when it was finished, this should never happen”. That’s a longer message to shove into the code, sure, but you could always just give it an error code and print it in the manual.
A good error message for the user should give at least some hints about possible further steps. There’s certainly a “spectrum of helpfulness” depending on how much the program knows about its environment and how many external factors are involved:
No space left on device— free up some space on the device.Unrecognized option --forbnicate, did you mean --frobnicate— correct the typo.Unrecognized option --frobnicate— check the docs for option syntax.File not found— check if you point the program at the right path, or check why the file is not created where you expect it.host administratively prohibited— this is a network problem, caused by a policy, you should check the configs or contact the network admin.Connection reset by peer— uhm, try to reconnect maybe, but at least you can be certain it’s not a problem on your side.Beyong that there’s basically the “check the source code or contact the developer” territory. Say,
assertion error: the system has a negative number of logged in users. The only way it can happen is if there’s a flaw in the program logic.And then there are problems like the duplicate root pointer. From that article, my impression is that no one understood how and why that condition could occur or what exactly a possible fix could be, so a message that didn’t need translation from Latin wouldn’t bring the user any closer to a solution. In that situation, the only thing people can do it either contact the developer or grep the source code for the error, and for that purpose, any unique message is as good as any other.
Yes, the HODIE NATUS EST RADICI FRATER error message was a “an impossible situation” from Multics’ point of view. As it turns out, the problem was in the hardware; specifically the system had been mis-configured in such a way the the root disk appeared twice as distinct physical devices. Thus the “brother” is a second root disk, a situation which cannot arise as part of the Multics software configuration; and lack of debugging guidance from Multics is quite understandable.
Obviously here the error can’t say exactly how to fix the issue but the fact that 2 teams had to grasp at straws should be all the proof you need that it should state the “impossible” situation clearly. That would’ve narrowed what to look at for them, just like the phone call did.
And nothing prevents you from having the joke and then a real message.
It reminded me of this Subnormality comic about an error message no one would ever hear:
https://www.viruscomix.com/page588.html
Warning: Very, very long. But also very, very good. Don’t bother clicking on the link if you are in a rush. Set aside half an hour or so to read everything; to look at all the details.
Ha, somehow I had never seen that xkcd either!
(Mitigation: “Make illegal states unrepresentable”, something that the C language is unfortunately not great at)
Flagged as off-topic because the answer to all three topicality questions is a resounding ‘no’, I think.
I’m less concerned about topicality in this case (we have fun little trivia posts sometimes, and as long as they don’t overwhelm the queue I’m fine with it; we all need a little whimsy in our lives), but I am concerned that the poster seems to almost entirely post their own content.
Looking at their posting history it’s pretty lopsided.
By those metrics, half of the front page is off-topic. For some examples, all of these would be considered off-topic by your argument: “Why did Windows 95 setup use three operating systems?”, “Gleam v1.6.0 released”, “ChatGPT is Slipping”, “I was banned from the hCaptcha accessibility account for not being blind”. Not to mention that it says those are “rules of thumb for great stories to submit”, not the end all be all of what and what not to post.
I think all of those examples can answer ‘yes’ to at least one of the questions for at least some Lobsters readers. (If you’re dealing with upgrade compatibility issues for a platform you develop; if you’re interested in programming languages or systems in the niche of Gleam; if you’re building LLM-based systems; if you maintain any kind of system that has a CAPTCHA-type access control).
It’s funny, I wouldn’t have flagged this story as off-topic, but I did flag the Half Life documentary you posted as off topic. I feel like this story is on topic because it explains a weird error message, while the Half Life documentary did not give me technical insights about building or running software. What makes you feel the Half Life documentary is more on-topic?
(To be fair, while I think this story is on topic, I also feel it’s not very good.)
I felt the same way about it. I think some exposition about
__builtin_unreachableand why we might want that in release builds but something different in debug builds could have made it a good article.But my take was “on-topic, but not very good,” which led to neither a vote nor a flag from me. It’s certainly about computing, even if it doesn’t meet those rules of thumb for a “good” submission.
As a ‘making-of’ documentary I think it’s interesting and on-topic to anyone who does game development, even as a twenty-years-later retrospective – in particular because it’s about a game that has been so massively influential. Sure, there’s a lot in it that isn’t on-topic in that sense (I don’t think an entire documentary about the Valve/Vivendi lawsuit would be on-topic), but also a lot that is. It interested me even though I’ve never done any game development (but I’ve been curious about it for a long time).
Good point, all other off-topic stories should be flagged as well.
https://en.wikipedia.org/wiki/Whataboutism