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
No need to throw an error; it'll never happen.
LOL
Because this is JavaScript
Don’t expect sensible error handling
Which part gives it away as JS?
Could be also Java or C#, or likely some other languages.
// TODO quick hack need to fix DON'T RUN IN PROD
commit date: 2007
Tbh, that would be a great place for an assert, depending if it's an actually relevant part of code.
"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
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.
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.
Primitive language. Week type system. 😂
In Scala:
type Header = "name_statement" | "import_statement"
@main def run =
val header: Header =
if true //scala.util.Random.nextBoolean // We don't want to randomly crash here, but the warnings would still work of course
then "name_statement"
else "import_statement"
val r = header match
case "name_statement" => "n"
case "import_statement" => "i"
val w1 = header match
case "name_statement" => "n"
// match may not be exhaustive.
// It would fail on pattern case: "import_statement"
val w2 = header match
case "name_statement" => "n"
case "import_statement" => "i"
case _ => throw Error("boom!") // unreachable case
// Unreachable case except for null (if this is intentional, consider writing case null => instead)
println(r)
println(w1)
println(w2)
[ https://scastie.scala-lang.org/6OlmG1kqTDO6hy5h4YymXg ]
One of the more interesting parts here is that Scala can actually assign an union type to an if-expression. Try change the strings in the if, and see for yourself. (But one needs to force it with the type annotation as otherwise this if-expression would be typed as String.)
---
To be fair, the exhaustivity checks in Scala have quite some gotchas and warts.
But Scala has at least more or less working union types, and singleton types (in depth).
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)
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...)
// 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.
I write this all the time!!! XD
me, working in games for business, asking the product owner some questions so i could handle some exceptional cases
me: what if somebody gives to much discount and takes all the sales? him: it will never happen
me: what if somebody sells zero units him: it will never happen
both happened. system broke from division by zero a couple times. and i needed to fix it so the game could go on.
HellFrozeOverException
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
Wait, isn't !data also NULL, so just return data...
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 .unwrap many things because if it does fail then it's a problem if the code not an error to handle
Most Rust code is full of
unwrap. That's why Rust programs crash a lot in my experience.Still better than silent memory corruption like in C++, but imho not how you build robust systems.
Coming from Scala I was actually shocked to see that people in Rust almost never handle the results properly, which means to (more or less) never unwrap them and just chain stuff with
?. In Scala it's even harder as you need to thread wrapped stuff through for-comprehensions; still people go almost always the extra mile!In Scala you have also usually lints active in production code that will outright fail compilation if you use any
.get(equivalent of.unwraponOptions) or similar…Of course there are some cases where you want to fail fast and actually crash the whole system if something returns a "failed" result. For example, if you can't read in config it makes not much sense to try to further boot the system. But even than a clean shutdown is likely better than a hard crash with an exception.
I write it daily, and I distinctly notice my peers never writing it when I do code reviews. 😡