3 ms·

> Overuse of macros is a symptom of missing language capabilities. Agree. > I think non-local flow control (i.e. exceptions) with automated causal chaining (l

> Overuse of macros is a symptom of missing language capabilities. Agree. > I think non-local flow control (i.e. exceptions) with automated causal chaining (like Python) is a good language design point Stronly disagree: https://home.expurple.me/posts/rust-solves-the-issues-with-exceptions/ https://home.expurple.me/posts/rust-solves-the-issues-with-e... > There should also have been an enforced "does not panic" annotation like noexcept in C++. noexcept DOES NOT mean that the function can't throw an exception! It just means that, when it does, it aborts the program instead of unwinding into the calling function. Quoting cppreference [1]: > Non-throwing functions are permitted to call potentially-throwing functions. Whenever an exception is thrown and the search for a handler encounters the outermost block of a non-throwing function, the function std::terminate is called > And Drop implementations should not be allowed to panic. Ever. Should `panic=abort` panics be allowed in Drop? They are effectively the same as std::process::exit. Do you want to mark and ban that too? [1]: https://en.cppreference.com/w/cpp/language/noexcept_spec.html https://en.cppreference.com/w/cpp/language/noexcept_spec.htm...

quotemstr 1y ago
> Stronly disagree: https://home.expurple.me/posts/rust-solves-the-issues-with-e https://home.expurple.me/posts/rust-solves-the-issues-with-e... 50% at least of these tiresome "here's why exceptions suck" articles begin by talking about how "try" is un-ergonomic. The people writing these things misunderstand exceptions, probably never having actually used them in a real program. These writers think of exceptions as verbose error codes, and think (or pretend to think) that using exceptions means writing "try" everywhere. That's a strawman. Exceptional programs don't need error handling logic everywhere. The article's author even admits at the end that Rust's error handling is garbage and forces programmers to do manually ("best practices around logging" --> waste your brain doing a computer's work) what languages with decent exception systems do for you. > noexcept DOES NOT mean that the function can't throw an exception! It just means that, when it does, it aborts the program instead of unwinding into the calling function Well, yeah. It means the rest of the program can't observe the function marked noexcept throwing. No... except. Noexcept. See how that works? > Should `panic=abort` panics be allowed in Drop? They are effectively the same as std::process::exit. Do you want to mark and ban that too? Aborting in response to logic errors is the right thing to do, even in destructors.
- Expurple 1y ago
  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.

quotemstr 1y ago

> Stronly disagree: https://home.expurple.me/posts/rust-solves-the-issues-with-e https://home.expurple.me/posts/rust-solves-the-issues-with-e... 50% at least of these tiresome "here's why exceptions suck" articles begin by talking about how "try" is un-ergonomic. The people writing these things misunderstand exceptions, probably never having actually used them in a real program. These writers think of exceptions as verbose error codes, and think (or pretend to think) that using exceptions means writing "try" everywhere. That's a strawman. Exceptional programs don't need error handling logic everywhere. The article's author even admits at the end that Rust's error handling is garbage and forces programmers to do manually ("best practices around logging" --> waste your brain doing a computer's work) what languages with decent exception systems do for you. > noexcept DOES NOT mean that the function can't throw an exception! It just means that, when it does, it aborts the program instead of unwinding into the calling function Well, yeah. It means the rest of the program can't observe the function marked noexcept throwing. No... except. Noexcept. See how that works? > Should `panic=abort` panics be allowed in Drop? They are effectively the same as std::process::exit. Do you want to mark and ban that too? Aborting in response to logic errors is the right thing to do, even in destructors.

Expurple 1y ago
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.