Exception specifications
Helmut Zeisel
use exception specifications?
In particular, when templates are present,
is there any chance to use exceptions specifications
(with the possible exception of an empty throw() )?.
For
template<typename T> void f(T& t)
what should the exception specification be?
Dependent on T, many not yet known exceptions could be thrown!
Thanks for any hints,
Helmut
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
Anthony Williams
"Helmut Zeisel" <atva...@attglobal.net> wrote in message
news:3C690F25...@attglobal.net...
> Does someone know any guidelines when and how to
> use exception specifications?
>
> In particular, when templates are present,
> is there any chance to use exceptions specifications
> (with the possible exception of an empty throw() )?.
>
> For
>
> template<typename T> void f(T& t)
>
> what should the exception specification be?
> Dependent on T, many not yet known exceptions could be thrown!
Having previously advocated that exception specifications are useless unless
we can find a syntax to solve your problem, and have them strictly enforced,
I read a convincing post by David Abrahams recently in which he argued that
the only useful exception specification is throw(), since in general it
doesn't matter what type of exception is thrown, except for error reporting.
I would add to this that I still think they should be strictly enforced by
the compiler, but now it is a much simpler problem --- does it throw, or
doesn't it?
So my guideline for exception specifications is --- don't use them, except
for throw(). If your code throws exceptions, document them. If it passes up
exceptions from other code, document that (e.g. f may throw xyz if condition
abc is not met, and will pass out any exception thrown by the copy
constructor or method foo() of the template parameter T)
Anthony
--
Anthony Williams
Software Engineer, Nortel Networks Optical Components Ltd
The opinions expressed in this message are not necessarily those of my
employer
Alexander Terekhov
> use exception specifications?
Try this: ("class nothrow" == std::nothrow_t)
http://www.bleading-edge.com/Publications/C++Report/v9603/Article2a.htm
("Coping With Exceptions")
http://www.bleading-edge.com/Publications/C++Report/v9605/Column1.htm
("Guidelines for Throwing Exceptions")
http://www.bleading-edge.com/Publications/C++Report/v9607/Column2.htm
("Guidelines for Using Exception Specifications")
and, of course, somewhat more "up-to-date" H.Sutter's
"exceptional" stuff (books/articles/"GotW"s):
> In particular, when templates are present,
> is there any chance to use exceptions specifications
> (with the possible exception of an empty throw() )?.
>
> For
>
> template<typename T> void f(T& t)
>
> what should the exception specification be?
> Dependent on T, many not yet known exceptions could be thrown!
You might want to take a look at this thread:
http://groups.google.com/groups?threadm=c29b5e33.0202110310.413c19cb%40posting.google.com
regards,
alexander.
Johan Johansson
> Does someone know any guidelines when and how to
> use exception specifications?
Read the thread called Java-like exception specifications for some views
on this.
> In particular, when templates are present,
> is there any chance to use exceptions specifications
> (with the possible exception of an empty throw() )?.
>
> For
>
> template<typename T> void f(T& t)
>
> what should the exception specification be?
> Dependent on T, many not yet known exceptions could be thrown
Exactly, which means you can't guarantee anything. Since someone else is
bound to if I don't I might as well mention that Herb Sutter's
Exceptional C++ contains some thorough thoughts on this and on exception
handling in general (as well as on a lot of other things).
Personally I am toying with the idea of having exception specifiers
accumulate in the case of templates. It doesn't seem much of a stretch
since we are already happily taking the other consequences of not
knowing the exact types returned from and passed to functions until the
template is instantiated.
But this is not how things are now and probably never will either, so
the short answer to your question IMO is to not use exception specifiers
on templates.
j
Francis Glassborow
<atva...@attglobal.net> writes
>Does someone know any guidelines when and how to
>use exception specifications?
>
>In particular, when templates are present,
>is there any chance to use exceptions specifications
>(with the possible exception of an empty throw() )?.
Basically the current guideline is "DON'T" That expands into only use
empty exception specs other than in the sub-sub-basement of your code.
--
Francis Glassborow
Check out the ACCU Spring Conference 2002
4 Days, 4 tracks, 4+ languages, World class speakers
For details see: http://www.accu.org/events/public/accu0204.htm
Aaron Isotton
news:3C690F25...@attglobal.net...
> Does someone know any guidelines when and how to
> use exception specifications?
>
Have a look at this:
http://www.bleading-edge.com/Publications/C++Report/v9607/Column2.htm
There are also a few other articles about exception handling on the same
site. I found them quite good.
Aaron
Herb Sutter
>news:3C690F25...@attglobal.net...
> > Does someone know any guidelines when and how to
> > use exception specifications?
See also the latest GotW solution, just posted here and at
www.gotw.ca/gotw/082.htm. It addresses exception specifications.
Herb
---
Herb Sutter (www.gotw.ca)
Secretary, ISO WG21/ANSI J16 (C++) standards committee (www.gotw.ca/iso)
Contributing Editor, C/C++ Users Journal (www.cuj.com)
Check out "THE C++ Seminar" - Boston, March 2002 (www.gotw.ca/cpp_seminar)
Shinji Ikari
> >"Helmut Zeisel" <atva...@attglobal.net> ha scritto nel messaggio
> >news:3C690F25...@attglobal.net...
> > > Does someone know any guidelines when and how to
> > > use exception specifications?
>
> See also the latest GotW solution, just posted here and at
> www.gotw.ca/gotw/082.htm. It addresses exception specifications.
How about an empty throw()? Is that evil too?
Helmut Zeisel
> >"Helmut Zeisel" <atva...@attglobal.net> ha scritto nel messaggio
> >news:3C690F25...@attglobal.net...
> > > Does someone know any guidelines when and how to
> > > use exception specifications?
>
> See also the latest GotW solution, just posted here and at
> www.gotw.ca/gotw/082.htm. It addresses exception specifications.
Thank you for the link;
although I essentially agree with the things written there,
I prefer the rule as formulated by Anthony Williams:
guideline for exception specifications is: don't use them, except for throw()
Without the nowthrow guarantee,
neither basic nor strong guarantee can be hold,
so it is a good idea to call unexpected() and terminate(),
since the program will probably be in an inconsistent state anyway.
Helmut
Herb Sutter
> > See also the latest GotW solution, just posted here and at
> > www.gotw.ca/gotw/082.htm. It addresses exception specifications.
>
>Thank you for the link;
>although I essentially agree with the things written there,
>I prefer the rule as formulated by Anthony Williams:
>
>guideline for exception specifications is: don't use them, except for throw()
>
>Without the nowthrow guarantee,
>neither basic nor strong guarantee can be hold,
Yes, but you can have the nothrow guarantee whether the exception
specification says so or not. In fact, I usually write declarations for such
functions like this: "X f( Y ) // throw()".
>so it is a good idea to call unexpected() and terminate(),
>since the program will probably be in an inconsistent state anyway.
But there are performance and other issues. See the above link, and the
Boost link at the end of that article.
Herb
---
Herb Sutter (www.gotw.ca)
Secretary, ISO WG21/ANSI J16 (C++) standards committee (www.gotw.ca/iso)
Contributing Editor, C/C++ Users Journal (www.cuj.com)
Check out "THE C++ Seminar" - Boston, March 2002 (www.gotw.ca/cpp_seminar)
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Alexander Terekhov
[...]
> Yes, but you can have the nothrow guarantee whether the exception
> specification says so or not. In fact, I usually write declarations for such
> functions like this: "X f( Y ) // throw()".
And who is protecting your clients from really bad
things (exceptions/faults) along the lines of:
To me, the current ES is just great! And I ALWAYS use "throw()"!!
(for *NOTHROW* exception safety guarantee)
Here is another ES example:
void oper(); // could throws anything
void checked_oper_call() throw( SOME_KNOWN_EXPECTED_EXCEPTIONS )
{ oper(); }
try {
checked_oper_call();
}
catch( ... ) // I know what I am doing/getting here,
// just do not want to write many
// catch clauses ;-)
{
//...
}
And the following might be really interesting too:
// Search/Check first!!
if ( std::expected_exception< BlaBla >() )
throw BlaBla( ... );
else // -mod/dwa's way ;-)
throw ThisProjectsGenericError( "explanation" );
int oper()
{
//...
if ( error ) {
if ( std::expected_exception< BlaBla >() )
throw BlaBla( ... );
return ERROR_STATUS_BlaBla;
}
//...
return STATUS_OK;
}
void cancelable_oper()
{
bool cancel_expected =
std::expected_exception< thread::cancel_e >();
//...
SOME_LOOP { /**/ if ( cancel_expected ) thread::test_cancel(); /**/
}
//...
}
because that might really help to address the point
of "ES just terminates the program and hence useless"
many people just continue to raise on c.l.c++.mod
again and again... and it would also nicely solve
ALL the problems of std::uncaught_exception(), IMHO.
regards,
alexander.
Helmut Zeisel
> > > See also the latest GotW solution, just posted here and at
> > > www.gotw.ca/gotw/082.htm. It addresses exception specifications.
> >
> >Thank you for the link;
> >although I essentially agree with the things written there,
> >I prefer the rule as formulated by Anthony Williams:
> >
> >guideline for exception specifications is: don't use them, except for throw()
> >
> >Without the nowthrow guarantee,
> >neither basic nor strong guarantee can be hold,
>
> Yes, but you can have the nothrow guarantee whether the exception
> specification says so or not. In fact, I usually write declarations for such
> functions like this: "X f( Y ) // throw()".
>
> >so it is a good idea to call unexpected() and terminate(),
> >since the program will probably be in an inconsistent state anyway.
>
> But there are performance and other issues. See the above link, and the
> Boost link at the end of that article.
I see the performance issue - clearly performance matters
in the real life.
OTOH, the performance issue is just an issue of the
quality of implementation,
so it is different..
As I understand, however, these other issues are not relevant
for the nowthrow guarantee:
on the contrary, if a nowthrow guarantee is broken,
unexpected() is probably the best choice.
I think that a "throw()" specification is very different
from every other exception specification -
so I still do not see why it should not be used
(excpet of the quality of implementation issue)