Exceptions are often a better way to handle errors than returning them as values. We argue that traditional exceptions provide better user and developer experience, and show that they even result in faster execution.
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”
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 withpanic::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”