6 ms·

Not downvoting you because I think you bring up meaningful opinions. I have to say that I much prefer errors as values though. With exceptions I never know wha

by dthul 7y ago

Not downvoting you because I think you bring up meaningful opinions. I have to say that I much prefer errors as values though. With exceptions I never know what I might get, with error values on the other hand I know exactly what I'll get. And the "?" operator makes it very low friction. It can sometimes be annoying to wrap error values into an appropriate type though, especially if you combine error types from multiple libraries

couchand 7y ago
> With exceptions I never know what I might get... Exactly this. It's just as Joel Spolsky wrote in that fifteen-year-old article that hit the front page yesterday: exceptions are an invisible goto. > It can sometimes be annoying to wrap error values into an appropriate type though, especially if you combine error types from multiple libraries For one-off code, the quick-error create is invaluable. For production code, I find this is one more indication of the value of the Rust philosophy. Forcing you to address the issue means you get a chance to thoughtfully consider what API you wish to offer your consumers. Most likely, you want to wrap the original errors so details of your dependencies don't become part of your public API.
- quotemstr 7y ago
  > Exactly this. It's just as Joel Spolsky wrote in that fifteen-year-old article that hit the front page yesterday: exceptions are an invisible goto. Exception semantics are well-defined. Exceptions clean up the stack, unlike longjmp and such, and in C++, you can mark which functions throw and which ones don't. When you write Rust code using Result everywhere and propagate all errors using "?", you end up with code that looks just like code that uses exceptions, but with extra syntax noise and decreased efficiency due to the need for runtime branching instead of exception dispatch tables. When you call a Rust function that can fail, do you carefully think through all the various failure paths and reason about everything from scratch? No. You call a function. The compiler complains, you insert a "?", and the compiler stops complaining. You don't reason about all possible errors, and you shouldn't have to reason about all possible errors. Exceptions free program logic on the common path from the mental overhead of the error path, and that's a good thing. Languages that start off boldly exception-free, like Rust and Go, end up reinventing the try/catch model because it turns out that exceptions are actually incredibly useful. As long as exceptions have been around, people have claimed that they've made code hard to follow. I reject these claims. They're just not consistent with my experience. In my experience, it's not difficult at all to understand control flow in exceptional systems, and there are many large C++ systems that you probably use all the time that work with exceptions without major problems. It's the weirdest thing: people who claim that exceptions make C++ unusable on Monday go on to write some Java or Python in Tuesday and don't seem to have immense cognitive difficulty in these languages. That you should avoid exceptions in C++ is obsolete conventional thinking from the 1990s era of bad compilers.
  - couchand 7y ago
    > When you call a Rust function that can fail, do you carefully think through all the various failure paths and reason about everything from scratch? From scratch? No, of course not. The type of the function tells me just what errors I need to expect. It's really not complicated. Either you don't care about the error (or it "shouldn't ever happen"), in which case you .expect("some message") and call it a day, or else you're writing professional code and you absolutely need to think about the error cases first. > Exceptions free program logic on the common path from the mental overhead of the error path, and that's a good thing. This is backwards from the correct way to write professional software. It is, unfortunately, quite common. The proper way to engineer bug-free software is to address the error cases first. Making a habit of ignoring what errors might happen is a sure way to get exploitable vulnerabilities and generally unreliable software.
    - quotemstr 7y ago
      > The proper way to engineer bug-free software is to address the error cases first. And that's what exceptions do: they handle the error cases in a uniform and automatic way so your program can focus on the logic paths. In the vast majority of cases, you "address" the "error cases" in a given stack frame by cleaning up and propagating all errors to your callers. Both exceptions and Rust's "?" operator automate this process: C++ exceptions just do it better. Don't conflate not handling errors with letters errors propagate automatically. Exceptions "address" all errors in a uniform way without polluting the logic with irrelevant details of the errors themselves. Generality and cleanliness are hallmarks of good code. When a language feature allows the right thing to happen by default, that's a good language feature. > professional Are you suggesting that anyone who uses exceptions is an amateur? Billions of dollars say otherwise. People write "professional" exceptional code all the time. Don't try to present your position as the only "professional" one.
      - couchand 7y ago
        I suppose Joel does a better job explaining it than I do, so I'll just quote him verbatim. "In other words, the more information about what code is doing is located right in front of your eyes, the better a job you’ll do at finding the mistakes. When you have code that says dosomething(); cleanup(); "… your eyes tell you, what’s wrong with that? We always clean up! But the possibility that dosomething might throw an exception means that cleanupmight not get called. And that’s easily fixable, using finally or whatnot, but that’s not my point: my point is that the only way to know that cleanup is definitely called is to investigate the entire call tree of dosomething to see if there’s anything in there, anywhere, which can throw an exception, and that’s ok, and there are things like checked exceptions to make it less painful, but the real point is that exceptions eliminate collocation. You have to look somewhere else to answer a question of whether code is doing the right thing, so you’re not able to take advantage of your eye’s built-in ability to learn to see wrong code, because there’s nothing to see." https://www.joelonsoftware.com/2005/05/11/making-wrong-code-look-wrong/ https://www.joelonsoftware.com/2005/05/11/making-wrong-code-...

by dthul 7y ago

couchand 7y ago

> With exceptions I never know what I might get... Exactly this. It's just as Joel Spolsky wrote in that fifteen-year-old article that hit the front page yesterday: exceptions are an invisible goto. > It can sometimes be annoying to wrap error values into an appropriate type though, especially if you combine error types from multiple libraries For one-off code, the quick-error create is invaluable. For production code, I find this is one more indication of the value of the Rust philosophy. Forcing you to address the issue means you get a chance to thoughtfully consider what API you wish to offer your consumers. Most likely, you want to wrap the original errors so details of your dependencies don't become part of your public API.

quotemstr 7y ago
> Exactly this. It's just as Joel Spolsky wrote in that fifteen-year-old article that hit the front page yesterday: exceptions are an invisible goto. Exception semantics are well-defined. Exceptions clean up the stack, unlike longjmp and such, and in C++, you can mark which functions throw and which ones don't. When you write Rust code using Result everywhere and propagate all errors using "?", you end up with code that looks just like code that uses exceptions, but with extra syntax noise and decreased efficiency due to the need for runtime branching instead of exception dispatch tables. When you call a Rust function that can fail, do you carefully think through all the various failure paths and reason about everything from scratch? No. You call a function. The compiler complains, you insert a "?", and the compiler stops complaining. You don't reason about all possible errors, and you shouldn't have to reason about all possible errors. Exceptions free program logic on the common path from the mental overhead of the error path, and that's a good thing. Languages that start off boldly exception-free, like Rust and Go, end up reinventing the try/catch model because it turns out that exceptions are actually incredibly useful. As long as exceptions have been around, people have claimed that they've made code hard to follow. I reject these claims. They're just not consistent with my experience. In my experience, it's not difficult at all to understand control flow in exceptional systems, and there are many large C++ systems that you probably use all the time that work with exceptions without major problems. It's the weirdest thing: people who claim that exceptions make C++ unusable on Monday go on to write some Java or Python in Tuesday and don't seem to have immense cognitive difficulty in these languages. That you should avoid exceptions in C++ is obsolete conventional thinking from the 1990s era of bad compilers.
- couchand 7y ago
  > When you call a Rust function that can fail, do you carefully think through all the various failure paths and reason about everything from scratch? From scratch? No, of course not. The type of the function tells me just what errors I need to expect. It's really not complicated. Either you don't care about the error (or it "shouldn't ever happen"), in which case you .expect("some message") and call it a day, or else you're writing professional code and you absolutely need to think about the error cases first. > Exceptions free program logic on the common path from the mental overhead of the error path, and that's a good thing. This is backwards from the correct way to write professional software. It is, unfortunately, quite common. The proper way to engineer bug-free software is to address the error cases first. Making a habit of ignoring what errors might happen is a sure way to get exploitable vulnerabilities and generally unreliable software.
  - quotemstr 7y ago
    > The proper way to engineer bug-free software is to address the error cases first. And that's what exceptions do: they handle the error cases in a uniform and automatic way so your program can focus on the logic paths. In the vast majority of cases, you "address" the "error cases" in a given stack frame by cleaning up and propagating all errors to your callers. Both exceptions and Rust's "?" operator automate this process: C++ exceptions just do it better. Don't conflate not handling errors with letters errors propagate automatically. Exceptions "address" all errors in a uniform way without polluting the logic with irrelevant details of the errors themselves. Generality and cleanliness are hallmarks of good code. When a language feature allows the right thing to happen by default, that's a good language feature. > professional Are you suggesting that anyone who uses exceptions is an amateur? Billions of dollars say otherwise. People write "professional" exceptional code all the time. Don't try to present your position as the only "professional" one.
    - couchand 7y ago
      I suppose Joel does a better job explaining it than I do, so I'll just quote him verbatim. "In other words, the more information about what code is doing is located right in front of your eyes, the better a job you’ll do at finding the mistakes. When you have code that says dosomething(); cleanup(); "… your eyes tell you, what’s wrong with that? We always clean up! But the possibility that dosomething might throw an exception means that cleanupmight not get called. And that’s easily fixable, using finally or whatnot, but that’s not my point: my point is that the only way to know that cleanup is definitely called is to investigate the entire call tree of dosomething to see if there’s anything in there, anywhere, which can throw an exception, and that’s ok, and there are things like checked exceptions to make it less painful, but the real point is that exceptions eliminate collocation. You have to look somewhere else to answer a question of whether code is doing the right thing, so you’re not able to take advantage of your eye’s built-in ability to learn to see wrong code, because there’s nothing to see." https://www.joelonsoftware.com/2005/05/11/making-wrong-code-look-wrong/ https://www.joelonsoftware.com/2005/05/11/making-wrong-code-...