Re: unhandled exceptions and exception specs
On Mar 13, 5:41 pm, ytrem...@nyx.nyx.net (Yannick Tremblay) wrote:
In article <MPG.22419320120994d8989...@news.sunsite.dk>,
Jerry Coffin <jcof...@taeus.com> wrote:
In the end, I guess I'm not all that worried about whether we
agree or not, but I'm left wondering about what you think of
the OP's question: how often do you see code that really
benefits from an exception specification.
Actually, to continue or add precision to my question:
1- I suggest that as they stand in the language, exception
specification are as good as useless (except maybe throw()).
a) Am I wrong, are they useful?
Except in very exceptional cases (I've never seen one), the only
useful exception specification is throw(). It is, however, very
useful.
b) Should/could they be removed from the language (they catch
newbies unaware hence are bad) (or maybe they are good cause
they make the language harder hence the pay rate better?)
Well, the no throw guarantee is very useful, and definitely
should not be removed. Practically speaking, I don't think that
it's possible to remove the more general use either. And
although I could imagine a compiler warning about a non empty
exception specification, I'm not really too much in favor of
compiler warnings just because the programmer might not have
understood the language.
c) should/could they be fixed
The no throw guarantee works fine as is, and doesn't need
fixing. Anything else is so rarely used, it doesn't matter.
2- throw(), the non throwing specification
The only execption specification I have ever used is
(no)throw(). Even there, I am in two mind about its value. I
have used it for functions that must be called by exception
unaware code, sometimes by pure C code. However, these
functions tend to be written in the style:
ErrorCodeType foo() throw();
ErrorCodeType foo() throw()
{
try
{
// Do some C++
return SuccessValue;
}
catch(...)
{
}
return ErrorValue
}
I guess the compiler will then wrap the whole thing as:
ErrorCodeType compiler_foo()
{
try
{
return foo()
}
catch(...)
{
std::unexpected();
}
}
The most frequent case of no throw that I see is for C++
functions which intentionally do nothing which can throw.
Things like swap() member functions, constructors of exception
types, etc.
Assuming the functions themselves are properly written with a
top level try/catch, the non-throw specification become almost
useless however, I can see two small values to it:
1- It call unexpected() if a function is badly written
(unfortunately, at runtime, in a rare failure scenario, probably after
the code has been released, I'd much prefer compile time warning :-( )
2- It documents the interface
("// This function will not throw" could do an almost as good a job)
Both of these are rather weak justification to use it. Almost
insufficient and certainly arguable.
In what way are they different from assert()? And assert() is
one of the most important and useful tools I know.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34