3 ms·

If an exception violates its (function's) contract, it can terminate immediately and not reach even a catch-all. That contract can be inside a function I can't

If an exception violates its (function's) contract, it can terminate immediately and not reach even a catch-all. That contract can be inside a function I can't even see. Even if I do have a catch-all, what tells me that it is a "library" exception? They might have thrown a generic std::exception with a vague string description. They might have thrown an "int". At some point what I really want is proper language and compiler support for those boundaries so I can know exactly where an exception came from, and can trap it at those boundaries (or ask the library maintainers to do so).

wvenable 10y ago
This just sounds like there are whole of really bad coding and C++ anti-features and you want to solve it with more C++ anti-features and bad code. A function could just not use exceptions at all and just call abort() on error, what are you going to do then? There isn't really a concept of library boundary in C++; you just have compilation units at best. At worst, you have a library that's implemented entirely as headers. What happens when the exception originates in your code but goes through the libraries call stack (because it was a call on a passed-in object or callback)? What you are asking for is likely impossible.
- makecheck 10y ago
  I know exactly what boundaries are lacking, that is what led to my original comment. And yes, functions can do whatever they want. Programmers expect special language features to be more useful than the alternatives though! If a function does call abort(), I can actually see the call, along with a stack trace; with source code I even know why the code exited. Odds are good that the abort() came from an assert() macro, giving me control over which builds can unexpectedly exit. Exceptions give me none of that, and introduce ways for valuable state to be totally lost in the process.
  - wvenable 10y ago
    I'd be happy if C++ had nice stack traces with exceptions -- that's a good potential language feature. But adding features to explicitly swallow exceptions doesn't sit right with me.

wvenable 10y ago

This just sounds like there are whole of really bad coding and C++ anti-features and you want to solve it with more C++ anti-features and bad code. A function could just not use exceptions at all and just call abort() on error, what are you going to do then? There isn't really a concept of library boundary in C++; you just have compilation units at best. At worst, you have a library that's implemented entirely as headers. What happens when the exception originates in your code but goes through the libraries call stack (because it was a call on a passed-in object or callback)? What you are asking for is likely impossible.

makecheck 10y ago
I know exactly what boundaries are lacking, that is what led to my original comment. And yes, functions can do whatever they want. Programmers expect special language features to be more useful than the alternatives though! If a function does call abort(), I can actually see the call, along with a stack trace; with source code I even know why the code exited. Odds are good that the abort() came from an assert() macro, giving me control over which builds can unexpectedly exit. Exceptions give me none of that, and introduce ways for valuable state to be totally lost in the process.
- wvenable 10y ago
  I'd be happy if C++ had nice stack traces with exceptions -- that's a good potential language feature. But adding features to explicitly swallow exceptions doesn't sit right with me.