3 ms·
I agree with this. Error handling code and exceptions are not mutually exclusive, and both have their benefits and drawbacks. Checking return codes in actually
by mytherin 8y ago
I agree with this. Error handling code and exceptions are not mutually exclusive, and both have their benefits and drawbacks. Checking return codes in actually exceptional circumstances makes the code base almost unreadable, and exceptions work amazingly for this. On the other hand, using exceptions for common errors is both inefficient and ugly.
As an example of useful exceptions: malloc errors. In C, handling malloc failures is a nightmare. So much so that very few programs actually do it properly. The reason for that is that not only do you need to check the return code of malloc, you need to check the return code of every single function in your entire program that ever calls a malloc anywhere down the line.
So while this piece of code might be nice if you see it in one or two places:
int rc = fx ();
if (rc != 0) {
handle_error ();
}
Properly handling malloc errors means every single function call becomes a four line monstrosity, basically blowing up your code base by factor four and making the code much more difficult to read. Not to mention how insanely error prone it is to have to check the return code of every single function. When doing the wrong thing is so much easier than doing the correct thing, most people will do the wrong thing.
- int_19h 8y agoThis is an API design issue. The proper solution is to provide two versions of malloc or equivalent - one that doesn't have any error code, and simply panics on failure to allocate, and another that provides a way to recover. A typical app would then mostly use the first version, and very occasionally the second when it anticipates that allocation might be so large that it could fail even in a healthy environment (e.g. loading an entire file into memory).
- mytherin 8y agoPanicing is not handling anything, it is just crashing the program. Unless you can catch the panic, in which case it's just another name for an exception. Not handling failed allocations except for on large allocations is just asking for rare crashes when one of the "unlikely to fail" allocations fails. Neither of these solve the problem in a robust way. Handling this properly is a language design issue. This is just applying a band-aid.
- int_19h 8y agoThis is just recognizing the status quo. Pretty much no desktop or mobile or web software is handling "unlikely to fail" allocations. And how exactly do you expect them to handle it? If, say, it's a desktop app that's rendering a widget, and as part of that it needs to allocate a string, and that fails - how does it recover? Panic on OOM is perfectly reasonable for most. And yes, panics shouldn't be catchable. That's the whole point.
- electrograv 8y agoIf you use a language designed from the start not to need exceptions, this problem is solved: The code in fact looks very much like code that uses checked exceptions (in fact, another commenter even mentioned Rust’s type system is isomorphic to checked exceptions). I have no problem with checked exceptions. Unchecked exceptions is another story, and forces you to “catch all” everywhere (most libraries don’t document every single possible exception of every single method). In retrospect I don’t even know why everyone responded to my original post about focusing on software error handling as if I was attacking exceptions. I think unchecked exceptions and unchecked null pointers are bad, but that’s about it; and that’s not even what my top post was about.