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);
}
Memory isn’t infinite, CPUs can’t process all integers, and Santa isn’t real
Wait, what? Need a spoiler tag.
I’m just going to comment on the face value of the title itself, and make assumptions otherwise.
-
Exceptions are control flow mechanism. I.e. that can be used for code execution flow, in the same application.
-
Error codes are useful across some API boundary.
Does this adequately cover whatever it is they figured out was a good tradeoff?
I’m just going to ask, without making assumptions. Have you managed to cut some time to read the article and find an answer?
I did eventually yes. Thanks for asking. I was exhausted yesterday, and upon reading my comment again, I get the downvotes. Being a second language doesn’t fully explain the wrong tone there. The article was a lot more insightful and in depth than I had mistakenly assumed.
After reading it tho, it seemed a lot more focused on performance than I think would be warranted. But that could be due to different concerns and constraints than where I’m used to working. I’d focus more on the mechanisms that best expresses the intent, and although they do discuss this well, the Venn diagram for the appropriate use of exceptions and error codes don’t overlap as much in my world.
And, it’s not like I’m arguing that they are wrong. It’s an opinion on a choice for a tradeoff that I only think, while allowing the possibility of being wrong, might miss the the mark. Stack unwinding is by its nature less explicit for the state it leaves behind. So it shouldn’t be a question of either error codes or exceptions, but which are most appropriate to express what, and when.
Even for Rust, where monads are preferred and part of the language to express and handle error codes, I would say that the statement of “newer languages like Rust don’t allow the use of exceptions”, seems incorrect to me. Something like panic!("foo"); coupled with panic::catch_unwind(|| { ... } }); I believe would unwind the stack similar to that of a throw/catch.
Anyways. Thanks for reminding me to actually read the post. It was well worth it, and very insightful.
To be fair, I disagree with all the points author makes, except for performance which is important but may be less important than code clarity in different cases. I am surprised that exceptions perform that well, and I am surprised the author said that compared C++ exceptions to Rust results, but actually did the right thing and compared C++ exceptions with C++ expected first. I thought it was going to be one of those “let’s compare assembly to lisp”
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
It would be nice to include Zig’s approach in the comparison. I’ve only just begun learning it, but the syntax seems pretty elegant from what I’ve seen so far.
Upvoting not because I share author’s preference, but because I’m interested in reading other people’s perspectives on the topic.
Read my reply with a handful of sea salt. I just read tutorials and documentation a bit and did Hello World.
Zig is pretty cool too! It can run C code directly just like C++ does (I think), kind of drop in replacement. From my reading so far, Error Handling is kind of a marriage between Go’s and Rust’s Error handling. Actually pretty cool. It has Error Types, but is kept relatively simple and doesn’t force to do all the stuff. It has Try and Catch keywords to handle errors elegantly, but don’t be fooled, this has nothing to do with Try…Catch blocks for Exceptions. Zigs Try and Catch are more like Rusts Result type handling, at least from what I read so far.
I lean more towards Zig than Go, but it still has not reached stable 1.0 release.
