6 ms·

The downside of C++ is that exceptions can come from any possible function call depth, whereas in C you only have to deal with error return codes. So in that se

The downside of C++ is that exceptions can come from any possible function call depth, whereas in C you only have to deal with error return codes. So in that sense it’s easier to deal with errors in C, and harder to test the error paths in C++

moloch-hai 4y ago
That is the upside. You don't need to know how far down it happened. If you need to know more, you catch it lower. But most often you don't. Whatever the hell it was didn't work, and you do whatever is called for, then.
- colejohnson66 4y ago
  Exactly. Being forced to handle errors at every function call sounds great, but then you end being forced to bubble up errors you don't care about like Go does: res, err := func() if err != nil: return nil, err That's not actually handling the error, and exceptions save you from being forced to pretend like you are. Just let it bubble up into the catch block further up the stack.
  - moloch-hai 4y ago
    Or Google dialect. Rust, anyway, captures this foolishness in a macro, which saves lines of source code, but still costs cache footprint, branch predictor slots, and runtime.
    - tialaramex 4y ago
      The Rust try! macro, which I assume is what you're thinking of, has been obsolete for many years - you can still refer to it because the Rust compatibility promise is taken more seriously than in C++ but you will need to use rather awkward syntax to get at it in modern Rust editions since the keyword "try" is reserved since 2018 edition. These days you'd use the Try operator ? which is not a macro, it's an operator. Try is really interesting, it's a unary operator so it takes a single parameter and it maps that parameter into a control flow decision. For Result the effect is similar to what you got out of the try! macro, but of course this operator can be implemented on any type. The standard library provides six implementations, including famously on Option, but also on ControlFlow itself, which is pretty nice. This means across a complex system you can choose to collect Results, and decide what to do about the Results later, (perhaps after you have all of them, or after you've a certain amount) or you can choose the same for the ControlFlow decisions resulting from those Results. You can also turn things on their heads, and decide that what you want to do is return early on success, but continue processing for errors -- which is something that's just unthinkable in an exception world where control flow and success are somehow the same thing. Rust took some years to figure out that's just not true which would be embarrassing if the assumption that it's true wasn't baked into the entire C++ language.
      - moloch-hai 4y ago
        You still wouldn't want to throw for the success case, so the point is meaningless. And of course you can return early on success in C++, and continue to process details further otherwise, with zero difficulty, so there is no cause for embarrassment. Rust people should be embarrassed if they carved out something special for this niche case.
        tialaramex 4y ago
        > And of course you can return early on success in C++, and continue to process details further otherwise, with zero difficulty Alas, C++ exceptions don't permit this, on failure the exception will get thrown and control flow switches away without any opportunity to intervene. That is in fact its whole purpose. That's the design mistake, it's not something you can fix, it's a choice which seemed clever last century, and it's last century's design.
        moloch-hai 4y ago
        It is in fact absolutely trivial to do, if you care to. But of course it is vanishingly rare to want it, so you don't see it much. If you cannot figure it out, find someone to explain it to you, instead doubling down when your falsehood is pointed out.
        tialaramex 4y ago
        I'm guessing you're thinking of capturing and hauling around exception_ptrs ? But that's far from "trivial" - it involves needing to understand how the temporary objects which were constructed in some "unspecified storage" work and then wrangle this custom smart pointer. In contrast Rust's Result and ControlFlow are just ordinary sum types, no magic involved.
        moloch-hai 4y ago
        std::optional<T> f() { try { return it(); } catch(...) { clean_up(); return {}; } } Trivial. If you don't want to throw away the exception: T f() { try { return it(); } catch(...) { clean_up(); throw; } } But of course cleanup code belongs in a destructor, so nobody does that. In C++, we say T f() { return it(); } and the responsible destructor does its job, either way.
  - properparity 4y ago
    You don't have to code like that in Go, C or other languages without exceptions or fancy option-type sugar. A sensible thing that often works great is to have a sticky error state (either a single int, or list of stuff you append to) then you just keep calling functions which will append to and/or replace the current error state until you reach a point where you can/care about handling errors, then you examine the persistent state and do something about it.
    - colejohnson66 4y ago
      "Sticky states" work too; IIRC, it's how FPU exceptions on the x87 work. But I was responding to the upthread comment that "exceptions can come from any possible function call depth, whereas in C you only have to deal with error return codes." Sticky states still have that "issue." After all, they're just an alternative to try{}catch{} blocks.
    - Too 4y ago
      I hope you are not referring to things like errno? Because it, just like a returned error, must be checked after every call that might set it, before you know if you can safely proceed with the next. Otherwise, what happens when you keep calling functions and there already is an error present? Are all functions implemented with if(errno) return null guards at the top? That's putting a lot of trust into global state and library writers. How do you know which functions become noops and which continue working in state of error? Additionally, that would be a debugging nightmare, because if you keep calling functions before examining the error, how do you know which call introduced the error first?
      - jstimpfle 4y ago
        > how do you know which call introduced the error first You don't. You can't. You don't want to. Take read()/write() for example. If you look into the kernel, it's physically impossible to name a function call that "introduced" the error. If you do a write() that will simply copy some memory into the buffer, and the syscall returns. When pages are flushed out to storage later, an error might be reported from storage asynchronously. The error is bubbling back at some point, at some syscall related to the file, but the error has nothing to do with that syscall necessarily. The error you get back could even be "caused" by a write to the same file but from a different process. So it's perfectly reasonable that the FILE API, which wraps read()/write(), simply stores returned errors in the FILE Handle. Distributed systems are a perfect application for objects that do error isolation.
pjmlp 4y ago
Don't forget to check for EINTR and keep a list of resources across the call stack in case a longjmp() is called.
mhh__ 4y ago
Ideally I think there is a time and a place for both. If you can't test it you've probably got that balance wrong. That being said this realization is basically a post-functional thing, so a lot of libraries are stuck with one or the other.

moloch-hai 4y ago

That is the upside. You don't need to know how far down it happened. If you need to know more, you catch it lower. But most often you don't. Whatever the hell it was didn't work, and you do whatever is called for, then.

colejohnson66 4y ago
Exactly. Being forced to handle errors at every function call sounds great, but then you end being forced to bubble up errors you don't care about like Go does: res, err := func() if err != nil: return nil, err That's not actually handling the error, and exceptions save you from being forced to pretend like you are. Just let it bubble up into the catch block further up the stack.
- moloch-hai 4y ago
  Or Google dialect. Rust, anyway, captures this foolishness in a macro, which saves lines of source code, but still costs cache footprint, branch predictor slots, and runtime.
  - tialaramex 4y ago
    The Rust try! macro, which I assume is what you're thinking of, has been obsolete for many years - you can still refer to it because the Rust compatibility promise is taken more seriously than in C++ but you will need to use rather awkward syntax to get at it in modern Rust editions since the keyword "try" is reserved since 2018 edition. These days you'd use the Try operator ? which is not a macro, it's an operator. Try is really interesting, it's a unary operator so it takes a single parameter and it maps that parameter into a control flow decision. For Result the effect is similar to what you got out of the try! macro, but of course this operator can be implemented on any type. The standard library provides six implementations, including famously on Option, but also on ControlFlow itself, which is pretty nice. This means across a complex system you can choose to collect Results, and decide what to do about the Results later, (perhaps after you have all of them, or after you've a certain amount) or you can choose the same for the ControlFlow decisions resulting from those Results. You can also turn things on their heads, and decide that what you want to do is return early on success, but continue processing for errors -- which is something that's just unthinkable in an exception world where control flow and success are somehow the same thing. Rust took some years to figure out that's just not true which would be embarrassing if the assumption that it's true wasn't baked into the entire C++ language.
    - moloch-hai 4y ago
      You still wouldn't want to throw for the success case, so the point is meaningless. And of course you can return early on success in C++, and continue to process details further otherwise, with zero difficulty, so there is no cause for embarrassment. Rust people should be embarrassed if they carved out something special for this niche case.
      - tialaramex 4y ago
        > And of course you can return early on success in C++, and continue to process details further otherwise, with zero difficulty Alas, C++ exceptions don't permit this, on failure the exception will get thrown and control flow switches away without any opportunity to intervene. That is in fact its whole purpose. That's the design mistake, it's not something you can fix, it's a choice which seemed clever last century, and it's last century's design.
        moloch-hai 4y ago
        It is in fact absolutely trivial to do, if you care to. But of course it is vanishingly rare to want it, so you don't see it much. If you cannot figure it out, find someone to explain it to you, instead doubling down when your falsehood is pointed out.
        tialaramex 4y ago
        I'm guessing you're thinking of capturing and hauling around exception_ptrs ? But that's far from "trivial" - it involves needing to understand how the temporary objects which were constructed in some "unspecified storage" work and then wrangle this custom smart pointer. In contrast Rust's Result and ControlFlow are just ordinary sum types, no magic involved.
        moloch-hai 4y ago
        std::optional<T> f() { try { return it(); } catch(...) { clean_up(); return {}; } } Trivial. If you don't want to throw away the exception: T f() { try { return it(); } catch(...) { clean_up(); throw; } } But of course cleanup code belongs in a destructor, so nobody does that. In C++, we say T f() { return it(); } and the responsible destructor does its job, either way.
- properparity 4y ago
  You don't have to code like that in Go, C or other languages without exceptions or fancy option-type sugar. A sensible thing that often works great is to have a sticky error state (either a single int, or list of stuff you append to) then you just keep calling functions which will append to and/or replace the current error state until you reach a point where you can/care about handling errors, then you examine the persistent state and do something about it.
  - colejohnson66 4y ago
    "Sticky states" work too; IIRC, it's how FPU exceptions on the x87 work. But I was responding to the upthread comment that "exceptions can come from any possible function call depth, whereas in C you only have to deal with error return codes." Sticky states still have that "issue." After all, they're just an alternative to try{}catch{} blocks.
  - Too 4y ago
    I hope you are not referring to things like errno? Because it, just like a returned error, must be checked after every call that might set it, before you know if you can safely proceed with the next. Otherwise, what happens when you keep calling functions and there already is an error present? Are all functions implemented with if(errno) return null guards at the top? That's putting a lot of trust into global state and library writers. How do you know which functions become noops and which continue working in state of error? Additionally, that would be a debugging nightmare, because if you keep calling functions before examining the error, how do you know which call introduced the error first?
    - jstimpfle 4y ago
      > how do you know which call introduced the error first You don't. You can't. You don't want to. Take read()/write() for example. If you look into the kernel, it's physically impossible to name a function call that "introduced" the error. If you do a write() that will simply copy some memory into the buffer, and the syscall returns. When pages are flushed out to storage later, an error might be reported from storage asynchronously. The error is bubbling back at some point, at some syscall related to the file, but the error has nothing to do with that syscall necessarily. The error you get back could even be "caused" by a write to the same file but from a different process. So it's perfectly reasonable that the FILE API, which wraps read()/write(), simply stores returned errors in the FILE Handle. Distributed systems are a perfect application for objects that do error isolation.

pjmlp 4y ago

Don't forget to check for EINTR and keep a list of resources across the call stack in case a longjmp() is called.

mhh__ 4y ago

Ideally I think there is a time and a place for both. If you can't test it you've probably got that balance wrong. That being said this realization is basically a post-functional thing, so a lot of libraries are stuck with one or the other.