C++ Exceptions: Under the Hood (2013)

Post by mikdore » Fri, Aug 13, 2021, 3:33 PM UTC

tialaramex wrote: post #90

TeMPOraL wrote: post #83

Earlier quoted context omitted.

> error handling and [exceptions are] not suitable for that I disagree :). Exceptions are fundamentally equivalent to "return sum type" error handling pattern. In an exception-enabled environment, you can imagine every function returning some Foo is really returning a {Foo, Error}. Then, every call like below, outside of try/catch block: value = SomeFunction(); is secretly translated to: maybeValue = SomeFunction();…

Obviously we can translate one Turing complete paradigm into another, but that's not very interesting. I argue that as so very often C++ the defaults are wrong . You can easily do the wrong thing, or you can go to a lot of effort to do the right thing, and since the right thing was technically possible C++ practitioners proudly declare C++ got this correct, and I say it did not. [See also: everything about const from…

Post by dnautics » Fri, Aug 13, 2021, 3:37 PM UTC

grandinj wrote: post #74

tialaramex wrote: post #73

Earlier quoted context omitted.

> LibreOffice throws exceptions __a lot__ They're terrible for this. C++ Exceptions are a perfectly good exception mechanism, but what C++ programmers are trained to do with them isn't exceptions but error handling and they're not suitable for that. "I tried to create the file but it already existed" is an error - and now you're going to write the unhappy path code, this is the wrong place to have exceptions. "I trie…

I guess people's experiences are different :-) I find exceptions to be a perfectly fine error handling mechanism. I certainly prefer it to cluttering my code with explicit checks for return codes and such like.

Post by lerno » Fri, Aug 13, 2021, 3:44 PM UTC

mananaysiempre wrote: post #89

lerno wrote: post #86

Earlier quoted context omitted.

No I'm quite aware of this. It's a restricted, implicit variant of it. But not also that it's not the type but the binding, which makes it slightly different from using a `Result`.

Hm. OK. I tried writing a response several times but I still feel confused. Can you explain what you mean by “not the type but the binding”? Note that I know the Haskell but not the Rust (guessing from the “Result” name) way of working in this style. (Not necessarily relevant or correct thoughts: - Your language still seems to mark potentially-failed values in the type system, even if it writes them T! not Either Err…

    int! x = ...
    int*! y = &x;
    int**! z = &y;

    // If it had been a type then
    // int!* y = &x;
    // int!** z = &y;

    // int*! y = &x;
    // means 
    // int*! y = "if x is err" ? "error of x" 
    //                         : "the address holding the int of x"

    // int! x;
    int x$real;
    ErrCode x$err;

    // int*! y;
    int* y$real;
    ErrCode y$err;

    // y = &x;
    if (x$err) {
      y$err = x$err;
    } else {
      y$real = &x$real;
    }

    int z;
    // y = &z;
    y$err = 0;
    y$real = &x;

    struct IntErr { 
      bool is_err_tag;
      union {
        int value;
        ErrCode error;
      };
    };

    int! x ... ;
    int!* y = &x; // Ok
    int z = ...
    y = &z; //