Exception Specifications & code quality

[Nathan Sidwell]

Martin von Loewis wrote:
> 
> > The code I'm talking about is between LL3 and LL16. I must say, I'm a
> > little surprised about the exception unwind blocks LLEHB14, LLEHB7 and
> > LLEHB10 around this, surely the routines __cp_eh_info, __tfc,
> > __check_eh_spec cannot throw?
> 
> Good question. __cp_eh_info cannot throw, as far as I can tell.  __tfc
> calls 'new builtin_type_info', and can throw if it runs out of memory.
> __check_eh_spec calls unexpected if the spec doesn't match, which can
> throw the some of the excepted exceptions.

I now see why __check_eh_spec throws (the original exception, the
exception thrown by unexpected or std::bad_exception).

I can't see how __tfc calls new (single stepping through the debugger
doesn't get there). Surely if it did, how can exceptions be guaranteed
to work? If bad_alloc is not in the function's exception specification,
it blows up. (And even if bad_alloc is allowed, the original exception
would be lost.)

I think the reason the exception unwind blocks are there is because
__cp_eh_info, __tfc do not have throw specifications -- they can't for
obvious reasons. Unfortunately this means the compiler naturally assumes
they can throw. What is really needed is a mechanism to allow the
exception specification on the function, but inhibit the compiler
emitting the check that the right tings are thrown for these. My
original observation that checking a function body for uncaught
exceptions and compile time matching this with the exception spec would
also solve the problem, provided __cp_eh_info et al were compiled with
optimization on.

nathan
-- 
Dr Nathan Sidwell :: Computer Science Department :: Bristol University
      You can up the bandwidth, but you can't up the speed of light      
nathan@acm.org  http://www.cs.bris.ac.uk/~nathan/  nathan@cs.bris.ac.uk