ProgrammerHumor
youWish
Discussion
Similarly, things like:
// NOTE: KEEP THIS STATEMENT OUTSIDE THE ASYNC CALL OR EVERY TEST WILL BREAK
Why not throw an error? If it should never happen then you need to know if and when it does
As a fan of offensive programming, that's what I like to do for things like those.
Trying to keep the PR at 4 files changed instead of 96
Tbh, that would be a great place for an assert, depending if it's an actually relevant part of code.
// TODO quick hack need to fix DON'T RUN IN PROD
commit date: 2007
And you laughed when C++ added std::unreachable
The problem with std::unreachable is that it's Rust's unreachable_unchecked!. That is, it's not an assertion; it's UB if you're wrong. The most common thing you want is an assertion. "I, the programmer, don't think this will happen. If it does, please fail quickly". In Python, that's assert. In Rust, that's assert! (or, more directly for this use case, unreachable!).
C++'s std::unreachable and Rust's unreachable_unchecked! are performance micro-optimizations. "I, the programmer, am writing super-low-level code. I have statically verified (through other means) that this branch is mathematically unreachable. Optimize around this fact. If I'm wrong, may the god of undefined behavior strike me down"
The former is common and ordinary. It acknowledges the possibility of wrong-ness and forces the program to fail-fast (with a good error message) if it happens. The latter is an absolute assertion of unchecked correctness. The latter is, 99% of the time, arrogant and overconfident.
I want these sorts of things to just shut up the stupid static analysis tool. There are #ifdefs that the tool ignores, so it's unreachable in some builds but not all builds, and I dont want to make the tool artificially more unreadable just to satisfy a tool.
(yes, yes, I could configure the tool to not be so pendantic but it's controlled by another group that turns the dial to 11 to ensure that all projects are late)
What is the use case for (actually) unreachable code?
It comes up a lot when you're reasoning about several cases (such as in pattern matching). As a recent example in one of my own projects, I'm parsing a data file. The file starts with a few "header" lines. The header lines each begin with name_statement or import_statement. When I encounter something that isn't a header line, I break the loop. So I have something like (obviously simplified code)
loop {
let Some(next_node) = nodes.peek() else {
break;
};
if next_node.kind() != "name_statement" && next_node.kind() != "import_statement" {
break; // Done with header
}
let next = nodes.next().unwrap();
let next_stmt = match next_node.kind() {
"name_statement" => {
// Parse name
}
"import_statement" => {
// Parse import
}
_ => unreachable!(),
};
decls.push(next_stmt);
}
By the time I get to the match statement, you and I both know that next_node.kind() is either a name or an import statement. But the compiler can't reason about that. So I put an unreachable! in that third case. It should never happen, and on the offchance that I'm somehow wrong, I get a panic rather than unexpected behavior.
"This should never happen" belongs in the error message that the user sees, and should include the developer's name phone number.
I do it when on some try/catch! Not with my phone number ; but with a link to my discord server. Never happens, but at last they can call me
There are some languages (I think mainly scripts) that there is no exception handling, you will see a lot of this
I hate when someone asserts on something like this, but the calling function is prepared and ready to handle the "should not happen" case and recover from it properly. As in the caller knows this case can happen. The result is that we should be able to handle the error, but the code crashes for thousands of customers because the developer thought that assert() was a good way to handle errors. Mostly, lots of people learning to program on the job all copying styles from each other and that code is in production for over a decade before suddenly it crashes everywhere all at once.
(on the other hand, an assert() in C code at the customer is slightly less annoying than a full blown Java exception backtrace because it catches all errors at main(). Have to tell people to stop printing out the backtraces because we're running out of printer paper...)
Wait, isn't !data also NULL, so just return data...
// we shouldn't get here
// shoutout to you in the future who got here anyway
Back in the early 90s, a colleague had a "this should never happen" error trap that printed "Oh no Mr. Bill!!!" to the console (trust me, back in the 90s that was a hilarious catch phrase. Ask your grandpa about it.)
Of course it happened, and our biggest client at the time called with... questions.
My framework is full of universal warnings that "should never occur"... until they do.
If it shouldn't happen you shouldn't need the if statement or yet better use non nullable variables if your language supports it.
A fair number of static analyzers will throw warnings if there is any way that the enclosing function could be called in a way that would result in dereferencing a null pointer, whether or not it ever is. Unless you like squiggly lines in the editor, you learn to put those checks everywhere (a lot of languages don't have non-nullable variables or argument declarations).
I would usually throw an appropriate exception (potentially an unchecked one) with a comment explaining that "if this ever happens, something has gone horribly wrong".
Of course, it's entirely possible that, in this case, returning null would be the correct and expected thing to do, and the developer is just reminding themselves that it shouldn't actually happen in practice
If you haven't written this exact comment while implementing error handling, you are not a real programmer.
// TODO: handle this properlydefault: break; // this is never rescheduledIn JS? Yes. In Rust? Fuck no.
suree
Honestly... indeed, it should be a no for Rust. It kinda maybe perhaps doesn't really let you have null values.
You can however type .unwrap and then if you DO get a wrong result, something null-like then it will instantly panic. And often you are tempted to as you assume a given line of code can't fail.
I write it daily, and I distinctly notice my peers never writing it when I do code reviews. 😡