3 ms·

One of the ground rules for the old exception specifications was that it had to be possible to link code compiled at different times. Which meant that there mig

One of the ground rules for the old exception specifications was that it had to be possible to link code compiled at different times. Which meant that there might never be a moment when the compiler had access to all the source code. And, given that most code did not have exception specifications, the only way to enforce them at compile time would have been to require them on all functions. I didn't follow the development of noexcept, so I can only guess at the motives. By and large, there were three complaints about exception specifications that I am familiar with: (1) by requiring stack unwinding when a no-throw specification was violated, they often caused worse performance (or, at least, didn't allow an optimization opportunity); (2) generally, the important question is whether a function might throw, not which exceptions it might throw; and (3) the rules around when exception specifications affect a function's signature -- e.g., does a pointer to a function have to match the specification exactly? -- were convoluted. I think it was reasonable for the Committee to focus on those issues.

gpderetta 10y ago
A possible solution would have been optional static enforcement of exception specifications plus fallback on the existing dynamic enforcement. Existing unmarked functions would be expeced to possibly throw everything, while functions with throw specifications would be statically checked. You can call the later from the former, but to do the reverse you need an explicit try/catch. Some form of throw(auto) would enable automatic deduction of exception specifications for e.g. template code. Dyanamic exception specifications will be removed fron the language in c++17, so the synax is open to be reused for such a feature in the future.
- palunon 10y ago
  The problem is C code. You know it won't throw, but there will never be any exception specification on it.

gpderetta 10y ago

A possible solution would have been optional static enforcement of exception specifications plus fallback on the existing dynamic enforcement. Existing unmarked functions would be expeced to possibly throw everything, while functions with throw specifications would be statically checked. You can call the later from the former, but to do the reverse you need an explicit try/catch. Some form of throw(auto) would enable automatic deduction of exception specifications for e.g. template code. Dyanamic exception specifications will be removed fron the language in c++17, so the synax is open to be reused for such a feature in the future.

palunon 10y ago
The problem is C code. You know it won't throw, but there will never be any exception specification on it.