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:
- You don’t know which functions might produce errors, and therefore you don’t know where you should be even trying to handle errors. (Checked exceptions are the answer here but they are relatively rarely used in practice.)
- Actually handling errors properly often involves responding to errors from individual function calls - at least adding human readable context to them. That is stupidly tedious with exceptions. Every line turns into 5. Sometime it makes the code extremely awkward:
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.
It can be pretty convenient to throw an error and be done with it. I think for some languages like Python, that is pretty much a prefered way to deal with things.
But the entire point of Rust and Result is as you say, to handle the places were things go wrong. To force you to make a choice of what should happen in the error path. It both forces you to see problems you may not be aware of, and handle issues in ways that may not stop the entire execution of your function. And after handling the Result in those cases, you know that beyond that point you are always in a good state. Like most things in Rust, that may involve making decisions about using Result and Option in your structs/functions, and designing your program in ways that force correct use… but that a now problem instead of a later problem when it comes up during runtime.
But the entire point of Rust and Result is… to force you to make a choice of what should happen
Checked exceptions also force you to handle it and take way less boilerplate.
But nothing is forcing you to check exeptions in most languages, right?
While not checking for exceptions and .unwrap() are pretty much the same, the first one is something you get by not doing anything extra while the latter is entirely a choice that has to be made. I think that is what makes the difference, and in similar ways why for example nullable enabled project in C# is desired over one that is not. You HAVE to check for null, or you can CHOOSE to assume it is not by trying to use the value directly. To me it makes a difference that we can accidentally forget about a possible exception or if we can choose to ignore it. Because problems dealt with early at compile time, are generally better than those that happen at runtime.
There’s also a massive tradeoff for when the error condition actually occurs. If an exception does get thrown and caught, that is comparatively slowwww.
The author pointed out how exceptions are often faster than checking every value. If your functions throws an error often enough that Exception handling noticeably slow down your program, surely you got to take a second look at what you’re doing.
The guy keeps on picking on Go, which is infamous for having terrible error handling, and then he has the nerve to even pick on the UNIX process return convention, which was designed in the 70s.
The few times he mentions Rust, for whatever reason he keeps on assuming that .unwrap() is the only choice, which’s use is decidedly discouraged in production code.
I do think there is room for debate here. But error handling is a hellishly complex topic, with different needs between among others:
- short- vs. long-running processes
- API vs. user-facing
- small vs. big codebase
- library vs. application code
- prototyping vs. production phase
And even if you pick out a specific field, the two concepts are not clearly separated.
Error values in Rust usually have backtraces these days, for example (unless you’re doing embedded where this isn’t possible).
Or Java makes you list exceptions in your function signature (except for unchecked exceptions), so you actually can’t just start throwing new exceptions in your little corner without the rest of the codebase knowing.
I find it quite difficult to properly define the differences between the two.
I find it quite difficult to properly define the differences between the two.
The handling is enforced by one while the other may be unknown to the person who calls the function. I think that’s a pretty clear difference.
The more I read about these kind of article the more I am amazed that our digital future is at hand in utterly incompetent people.
This person clearly have no understanding of monadic error (AKA Maybe/option monad or slightly more advanced Either monad), which is the first monad we teach at a class targeting second year undergrad.
The performance comparison is just plain factual error. The functional error code will continue to compute n2 when computation of n1 failed; the same do not happen in the exception version. If you compare codes with completely different traces, of course they will have different performance…
A properly implemented monadic error will return as soon as compute for n1 failed, and never execute the rest of the code. This is the default and idiomatic behavior in Haskell, OCaml, F#, and rust. This performance problem doesn’t even happen in LINQ-style handling like in C# and Kotlin (maybe also Typescript?).
The point of monadic error is that its control flow is local, whereas exception is non-local. Specifically, the exception can be handled and occur anywhere in the code base, with no indication on the type level. So programmers will be constantly worrying about whether the exception in a function call is properly handled.
Even worse, when you try to catch a certain error, there is always the risk to accidentally catch similar exceptions in a library call or someone else’s code. Writing good code with try-catch requires a lot of principle and style guides. But unlike monads, these principle and rules cannot be enforced by the type system, adding extra burden to programmers.
In fact, we have known for a long time that non-local control flows (goto, break, contiune, exception, long jump) are the breeding ground for spaghetti code. As an evidence, many non-local control flows (goto, long jump) are baned in most languages.
That being said, there are certainly cases, with proper documentation, that exception style is easy to write and understand. But I think they are very specific scenarios, which have to be justified on a case-by-case basis.
I think the author of the article just haven’t understood how to use the ? operator yet, and don’t think they deserve being called “utterly incompetent” for it. Whether something is a monad or not is not necessarily something a programmer should have to think about on a daily basis IMO.
I just think of rust errors as a tagged enum with either a value or an error. And the ? operator as syntax sugar for returning if something was an error. IMO that simple understanding is sufficient to do error handling in Rust. I don’t think we should gatekeep programming behind some intellectual barrier of whether or not you understand category theory. I certainly don’t understand what a monad is, but I can still write working software and do error handling without unwraps.
I was making a shared library at work and was recently asked to start throwing exceptions, because the users wouldn’t care to check my returned error and just continue with the empty returned data.
Well, now they will most probably have an empty catch block and continue doing what they did before.
Nothing can fix a lazy worker.
My anecdotal experience is that Rust code, for example, has more calls to unwrap than I’d like. The problem here is that simply unwrapping results will crash the program on errors that could have been a user-visible error message with exceptions.
unwrap() is explicitly not handling the error in a Result type. If you must do this, then at least use except(), to unwrap the code but with an error message if program crashes. Its the equivalent of having Exceptions and then not handling that exception. Therefore your critique is not valid here.
One problem with Exceptions is, you never know what code your function or library calls that can produce an exception. It’s not encoded in the type system or signature of the function. So you need to pray and try catch all possible exceptions (I look at this from Pythons perspective), if you don’t want a Catch…All, which then you wouldn’t know what error this actually is. And you still don’t know where this error came from or happened in the code, how deep in the function call chain? Instead Errors as Values means its encoded in type system and you can directly see what errors the function can cause and (in Rusts case) you must handle the error, otherwise program won’t compile. You don’t need to handle anything else in this context. Compiler ensures that all possible errors are handled (again within context of our discussion). Vast improvement!
you never know what code your function or library calls that can produce an exception
As far as I remember, there were several attempts at introducing exceptions into type system, and all have failed to a various degree. C++ abandoned the idea completely, Java has a half-assed exception signature where you can always throw an unexpected exception if it’s runtime exception, mist likely there were other cases, too.
So yeah, exception as part of explicit function signature is a vast improvement, I completely agree
So yeah, exception as part of explicit function signature is a vast improvement, I completely agree
Hmm, I’m not sure if you are being sarcastic. In my reply I didn’t meant encoding Exceptions into Type system. Is this a type and you probably meant “Error Types as part of” instead “exception as part of”?
Honestly I don’t know how Exceptions as part of type system would even look like. Because each function call in a chain would need to have all information from previous function call, otherwise that information gets lost to the next caller. The problem is the hierarchy of function and method calls. Somewhere some objects and functions can be edited to Throw a new Exception, that is not handled through the entire chain. And for the higher function caller, there is 0% way of knowing that (through code, besides documentation off course).
Yeah, I shaped my words poorly. What I meant is that errors are sort of equivalent to exceptions, but errors are first class citizens of type system, and this is an improvement over exceptions being kind of independent of type
In C++, ignoring anything that any other language provides…
I mean, yeah, if your language does not support error values, do not use them.
I mean, yeah, if your language does not support error values, do not use them.
Nonsense. If adopting info of the many libraries already available is not for you, it’s trivial to roll your own result type.
Even if that was somehow unexplainably not an option, even the laziest of developers can write a function to return a std::tuple or a std::pair and use structured binding.
The problem is not encoding the result.
The problem is that you need some support from the language to make it easy to deal with. Otherwise you’ll get into go-style infinite if (err != null) handlers that will make your code unreadable.
The problem is that you need some support from the language to make it easy to deal with.
Nonsense.
if (result.isSuccess()) {
do_something(result.value);
}
else {
handle_error(result error);
}
