4 ms·

> Throwing an exception is an example of a “non local exit” which Rust also implements (in terms of “Return”). They are not isomorphic. Return always hands con

> Throwing an exception is an example of a “non local exit” which Rust also implements (in terms of “Return”). They are not isomorphic. Return always hands control back to the caller; you can emerge from an exception inside any arbitrarily higher scope, and the proliferation of weird edge cases (what happens when I throw an uncaught exception in a constructor or destructor, the exception safety guarantee hierarchy) are good evidence for why this behavior is too complicated for its own good. > Like it or not, any serious c++ ffi must accommodate C++ exceptions Obviously this is the case and I'm not trying to say otherwise. I already said so upthread, but it seems to me that the least complicated way to do so is to wrap wrap foreign C++ function return values in a Result<T> (unless they can be statically proven not to throw), and report errors to C++ through some kind of Either-ish box. Then the C++ caller can decide whether they want to handle the error then and there, or throw an "idiomatic" exception.

CyberRabbi 6y ago
>> Throwing an exception is an example of a “non local exit” which Rust also implements (in terms of “Return”). > They are not isomorphic. It was never claimed that “return” and “throw” were isomorphic. Only that they are both examples of non-local exits. > good evidence for why this behavior is too complicated for its own good. That’s a nice opinion but I wouldn’t consider that evidence except under the loosest definitions of the word. By the same reasoning I could claim that being able to invoke “return” at any arbitrary point in the function is evidence that return is a complicated feature. Just like “return” exceptions in C++ have a statically defined set of areas they can branch to and the invocation of throw is well defined w.r.t. to object cleanup. Admittedly those landing sites are more numerous than “return” but not different in their more defining properties.
- arcticbull 6y ago
  > I could claim that being able to invoke “return” at any arbitrary point in the function is evidence that return is a complicated feature. Not really, because a return statement (like a go-to) only has one place to go. An exception has an unlimited number of places to come from. That put it into its own special circle of hell.
  - CyberRabbi 6y ago
    Your metric of what makes a language feature too complicated is just as arbitrary as mine. > An exception has an unlimited number of places to come from False. An exception can only come from a throw statement, which is both lexical/statically defined and finite in number within every codebase.
    - arcticbull 6y ago
      > False. An exception can only come from a throw statement... Obviously. > ...which is both lexical/statically defined and finite in number within every codebase. Not in every case. Any time you have a library that calls into client code the set is dynamic and uncountable from the perspective of the library author.

CyberRabbi 6y ago

>> Throwing an exception is an example of a “non local exit” which Rust also implements (in terms of “Return”). > They are not isomorphic. It was never claimed that “return” and “throw” were isomorphic. Only that they are both examples of non-local exits. > good evidence for why this behavior is too complicated for its own good. That’s a nice opinion but I wouldn’t consider that evidence except under the loosest definitions of the word. By the same reasoning I could claim that being able to invoke “return” at any arbitrary point in the function is evidence that return is a complicated feature. Just like “return” exceptions in C++ have a statically defined set of areas they can branch to and the invocation of throw is well defined w.r.t. to object cleanup. Admittedly those landing sites are more numerous than “return” but not different in their more defining properties.

arcticbull 6y ago
> I could claim that being able to invoke “return” at any arbitrary point in the function is evidence that return is a complicated feature. Not really, because a return statement (like a go-to) only has one place to go. An exception has an unlimited number of places to come from. That put it into its own special circle of hell.
- CyberRabbi 6y ago
  Your metric of what makes a language feature too complicated is just as arbitrary as mine. > An exception has an unlimited number of places to come from False. An exception can only come from a throw statement, which is both lexical/statically defined and finite in number within every codebase.
  - arcticbull 6y ago
    > False. An exception can only come from a throw statement... Obviously. > ...which is both lexical/statically defined and finite in number within every codebase. Not in every case. Any time you have a library that calls into client code the set is dynamic and uncountable from the perspective of the library author.