I think he meant the idea of shaming companies for not donating to things.
I think he meant the idea of shaming companies for not donating to things.
I don’t think you can blame them for this. How many resources do you use without voluntarily paying extra above your legal requirements? Do you donate every time you go to free libraries, museums, parks, cathedrals, etc? I certainly don’t and I don’t think that makes me “the parasite class”.
I think I disagree with everything here.
Exceptions Are Much Easier to Work With
Well, they’re “easier” in the same way that dynamic typing is easier. It’s obviously less work initially just to say “screw it; any error gets caught in main()
”. But that’s short term easiness. In the long term its much more painful because:
try {
int& foo = bar();
} catch (...) {
std::cout << "bar failed, try ...\n";
return nullopt;
}
foo = 5;
(It actually gets worse than that but I can’t think of a good example.)
Over 100× less code! [fewer exception catching in their C++ database than error handling in a Go database]
Well… I’m guessing your codebase is a lot smaller than the other one for a start, and you’re comparing with Go which is kind of worst case… But anyway this kind of proves my point! You only actually have proper error handling in 140 places - apparently mostly in tests. In other words you just throw all exceptions to main()
.
System errors [he’s mainly talking about OOM, stack overflow & arithmetic errors like integer overflow]
Kind of a fair point I guess. I dunno how you can reasonably stack overflows without exceptions. But guess what - Rust does have panic!()
for that, and you can catch panics. I’d say that’s one of the few reasonable cases to use catch_unwind
.
Exceptions Lead to Better Error Messages
Hahahahahaha. I dunno if a bare stack trace with NullPointerException
counts as a “better error message”. Ridiculous.
Exceptions Are More Performant
Sure maybe in error handling microbenchmarks, or particularly extreme examples. In real world code it clearly makes little difference. Certainly not enough to choose an inferior error handling system.
I would say one real reason to prefer exceptions over Result<>
s is they are a fair bit easier to debug because you can just break on throw. That’s tricky with Result<>
because creating a Err
is not necessarily an error. At least I have not found a way to “break on Err
”. You can break on unwrap()
but that is usually after the stack has been unwound quite a bit and you lose all context.
Yes but they frequently ask for optional donations too. Are you a parasite for not donating?