4 ms·

I'm the author of this article, btw :) > 50% at least of these tiresome "here's why exceptions suck" articles begin by talking about how "try" is un-ergonomic.

I'm the author of this article, btw :) > 50% at least of these tiresome "here's why exceptions suck" articles begin by talking about how "try" is un-ergonomic. Idk about the other articles, but mine doesn't begin with that. The first argument in the article is this: "exceptions introduce a special try-catch flow which is separate from normal returns and assignments" (when there's no entrinsic reason why errors shouldn't be returned and assigned normally). The first mentioned implication of that is ergonomics, but I immediately follow up with the implications regarding reliability and code clarity. See the "Can you guess why I used an intermediate variable" toggle. Later, I also bring up a separate disadvantage of having to manually document thrown unchecked exceptions. > The people writing these things misunderstand exceptions, probably never having actually used them in a real program. I've supported C++ and Python applications in production. > pretend to think that using exceptions means writing "try" everywhere. Nope: "[propagation] is a very common error-handling pattern, and I get why people want to automate it". > That's a strawman. Exceptional programs don't need error handling logic everywhere. Where does the article say otherwise? You're the one pulling a strawman here. > The article's author even admits at the end that Rust's error handling is garbage You're free to make that conclusion. In the end, the tradeoff is subjective. But it's not the conclusion that I make in the article. > forces programmers to do manually ("best practices around logging" --> waste your brain doing a computer's work) That's true. But languages with unchecked exceptions force you to manually check the documentation of every method you call, in order to see whether it can throw any exceptions that you're interested in catching. And that documentation can simply be incorrect and let you down. And the set of exceptions can silently change in the next version of the library (the compiler won't tell you). And refactoring your code can silently break your error handling (the compiler won't tell you). And manually verifying the refactoring is really hard because you can't use local reasoning (`catch` is non-local and "jumps" all across the layers of your app). It's a tradeoff.

saurik 1y ago
I almost never see people "handle" errors and actually add value, though... it feels a lot like how people sprinkle timeouts throughout their logic that just serve to make the system less stable. Almost all of the time--like, seriously: almost all of the time, not 99% of the time, or 99.9% of the time, but almost every single time--you call a function, you shouldn't care what errors it can raise, as that's not your problem. In a scant handful of places throughout your entire project--in the context of a web site backend, this often won't even be in your code at all: it will be taken care of inside of the router--you will catch errors, report them, and provide a way for the operation to retry somehow; but, if you care why the error happened, either the API was designed wrong (which sometimes happens) or you are using it wrong. You have to already misunderstand this aspect of error design in order to even contemplate the existence of a language that forces people to deal with local error handling.
- Expurple 1y ago
  > almost all of the time, not 99% of the time, or 99.9% of the time, but almost every single time--you call a function, you shouldn't care what errors it can raise Sure, that's often the case. That's why dynamically-typed anyhow::Error is so popular. But I really care whether a function can raise at all. This affects the control flow in my program and composability of things like `.map()`. `Result` is so good because it makes "raising" functions just as composable as "normal" functions. When you `.map()`, you need to make a decision whether you want it to stop on the first error or keep going and return you Results with all individual errors. Rust makes it very easy and explicit, and allows to reuse the same `.map()` abstraction for both cases. > a language that forces people to deal with local error handling. It does that for the reason above: explicit control flow. See the "Can you guess why I used an intermediate variable" toggle in the article. It doesn't mean that you have to do full "local error handling" on every level. 99% of the time, `?` operator is used. Because, as you've said, 99% of the time you just want to propagate an error. That's understood in the Rust community and the language supports it well. When you need to wrap the error for some reason, `?` can even do that automatically for you. That's what makes anyhow::Error so seamless and sweet. It automatically wraps all concrete library errors and you no longer need to deal with their types. Basically, `Result<T, anyhow::Error>` is `throws Expection`. But, like, ergonomic, composable and actually useful.

saurik 1y ago

I almost never see people "handle" errors and actually add value, though... it feels a lot like how people sprinkle timeouts throughout their logic that just serve to make the system less stable. Almost all of the time--like, seriously: almost all of the time, not 99% of the time, or 99.9% of the time, but almost every single time--you call a function, you shouldn't care what errors it can raise, as that's not your problem. In a scant handful of places throughout your entire project--in the context of a web site backend, this often won't even be in your code at all: it will be taken care of inside of the router--you will catch errors, report them, and provide a way for the operation to retry somehow; but, if you care why the error happened, either the API was designed wrong (which sometimes happens) or you are using it wrong. You have to already misunderstand this aspect of error design in order to even contemplate the existence of a language that forces people to deal with local error handling.

Expurple 1y ago
> almost all of the time, not 99% of the time, or 99.9% of the time, but almost every single time--you call a function, you shouldn't care what errors it can raise Sure, that's often the case. That's why dynamically-typed anyhow::Error is so popular. But I really care whether a function can raise at all. This affects the control flow in my program and composability of things like `.map()`. `Result` is so good because it makes "raising" functions just as composable as "normal" functions. When you `.map()`, you need to make a decision whether you want it to stop on the first error or keep going and return you Results with all individual errors. Rust makes it very easy and explicit, and allows to reuse the same `.map()` abstraction for both cases. > a language that forces people to deal with local error handling. It does that for the reason above: explicit control flow. See the "Can you guess why I used an intermediate variable" toggle in the article. It doesn't mean that you have to do full "local error handling" on every level. 99% of the time, `?` operator is used. Because, as you've said, 99% of the time you just want to propagate an error. That's understood in the Rust community and the language supports it well. When you need to wrap the error for some reason, `?` can even do that automatically for you. That's what makes anyhow::Error so seamless and sweet. It automatically wraps all concrete library errors and you no longer need to deal with their types. Basically, `Result<T, anyhow::Error>` is `throws Expection`. But, like, ergonomic, composable and actually useful.