5 ms·

> 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

> 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-...
- layoutIfNeeded 7y ago
  Don’t write C++ like C and cleanup will be guaranteed by RAII.
  - couchand 7y ago
    Yep, RAII is an eminently reasonable way to address the narrow question of cleanup. In fact, that's how idiomatic Rust code would handle it, too. That still leaves the general question of how to tell what errors a function may alert you to. Sanity suggests including it in a type signature, either in the return type or with checked exceptions. From what I've seen, the much more common solution in exception-using code is to ignore or forget the possibility of error.
    - quotemstr 7y ago
      > Sanity suggests including it in a type signature, either in the return type or with checked exceptions Yet basically all of Rust's std::io propagates just io::Result<T>, which is Result<T, io::Error>, where io::Error is a generic result that could be anything vaguely related to the outside world. It's as useful as writing "throws Exception" in Java. C# gets along fine in practice using unchecked exceptions everywhere. Your point would be stronger if, say, File::Create specifically said it could fail only with things like disk-full, file-exists, and so on. But all it actually says is "this can fail". The information richness you're describing does not exist in practice.
      - roblabla 7y ago
        The problem with File::create is that it must interoperate with the existing OSes. And it turns out, File::create can fail for many many reasons. Your file can be on disk, it can be remotely accessible on the network, it can be virtual, etc... And the OS can return just about any error. Linux lists the errors returned on each operation, but they're really just advisory and not exhaustive. So for io::Error, we're basically constrained by what the OS provides. Not much Rust can do about it, I'm afraid.

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-...

layoutIfNeeded 7y ago
Don’t write C++ like C and cleanup will be guaranteed by RAII.
- couchand 7y ago
  Yep, RAII is an eminently reasonable way to address the narrow question of cleanup. In fact, that's how idiomatic Rust code would handle it, too. That still leaves the general question of how to tell what errors a function may alert you to. Sanity suggests including it in a type signature, either in the return type or with checked exceptions. From what I've seen, the much more common solution in exception-using code is to ignore or forget the possibility of error.
  - quotemstr 7y ago
    > Sanity suggests including it in a type signature, either in the return type or with checked exceptions Yet basically all of Rust's std::io propagates just io::Result<T>, which is Result<T, io::Error>, where io::Error is a generic result that could be anything vaguely related to the outside world. It's as useful as writing "throws Exception" in Java. C# gets along fine in practice using unchecked exceptions everywhere. Your point would be stronger if, say, File::Create specifically said it could fail only with things like disk-full, file-exists, and so on. But all it actually says is "this can fail". The information richness you're describing does not exist in practice.
    - roblabla 7y ago
      The problem with File::create is that it must interoperate with the existing OSes. And it turns out, File::create can fail for many many reasons. Your file can be on disk, it can be remotely accessible on the network, it can be virtual, etc... And the OS can return just about any error. Linux lists the errors returned on each operation, but they're really just advisory and not exhaustive. So for io::Error, we're basically constrained by what the OS provides. Not much Rust can do about it, I'm afraid.