Dear Readers,
Some of you may be happy to see that I have little to say this time as pressures of the real World have strongly curtailed the time I have for writing. The following is a response to the letter from Will Watts.
Will is, of course, entirely correct. I should have said 'the first of these mechanisms'. I think I must have had a mental spasm, as it was the first thing in the list but the last thing I wrote about in the preceding paragraph.
The next comment really embarrasses me. I can only plead that writing articles while nursing a child with toothache is not conducive to error free code. Perhaps that also explains my perverse negativity.
On his last point, I completely agree. What I was attempting to outline was some mechanism (coding guidelines) that would make use of exception specifications useful.
A dialogue with Francis has persuaded me that the Standards Committees have a lot of work to do.
The first thing they need to do is to remove the requirement for runtime checking of Exception Specifications (ES). We really need something that will provide us the same choices as we had with the C assert() . Obviously it cannot be done the same way but we need the ability to have ES in our code for static checking but leave it out for release versions of executables. Why leave it out? Because supporting ES has a measurable influence on code size and execution speed.
The other oft quoted problem of terminate being called by unexpected() , that is easily fixed by using std::set_unexpected to change the default behaviour to throw std::bad_exception() .
What I want to provide is a mechanism by which exceptions are handled at whatever level that the programmer can do so. Application programmers should not expect to handle low level problems, generally the next level should handle these. I could always convert unknown exceptions (those introduced by new releases of a library and so not handled by older client code) by converting them to std:: bad_exception but I naïvely thought there might be some benefit from doing otherwise.
Apart from the problem of ES impacting on performance issues (actually empty throw specifications can result in slimmer, faster code) there is also the problem of templates. We clearly need a whole raft of extra requirements if we are to handle ES in template code. For example:
template <typename T> void fn(T t) ???
{
t.dosomething();
}
How do I specify that fn() is to inherit the ES of the member function dosomething() that belongs to the specific type T for which fn() is being instantiated.
At the moment templates slap a great big barrier across all uses of ES.
Then there is the issue that Francis tells me WG21 & J16 are going to address, 'is the exception specification' part of the type or not? Sometimes it seems that it is and other times it seems it isn't (can't be used in typedef 's but are applied to virtual function overriders)
