Re: [Fresco-devel] Coding standard: throw specifications

Stefan Seefeld wrote:
> Neil Pilgrim wrote:
> > Nathaniel Smith wrote:

> > I completely agree...almost...but you might say that throw specs are a
> > way of enabling *user* exceptions - I believe that with corba you can
> > throw some SystemExceptions, eg. OBJECT_NOT_EXIST? ;)
> 
> you shouldn't. Users shouldn't throw anything but user exceptions.

Well this was my original understanding, but I read recently that at
least one system exception is expected to be thrown by applications:
OBJECT_NOT_EXIST.
For reference, see page 379 of H&V, last para of 'Throwing CORBA System
Exceptions'.

But heck, I've never used it, I just happened to read about it somewhere
:)

> > - generally don't bother with exception specifications
> 
> I think exception specs are good to document the intention (similar
> to 'const'), but they may be hard to fulfill. If you can really
> guarantee that only std::runtime_error will be thrown, you may as well
> embed that statement into the API.

TBH I would agree, if throw specifications were compile-time checked;
since they're not, I believe its far better to just use a comment
instead. I'd prefer to use one or the other consistently, and you can't
really do that with throw specs when you only use them in some limited
cases.

> > - except possibly throw() on non-inline non-virtual non-template
> > functions
> 
> huh ?

Generally as always (from those links I gave, and elsewhere):
- inline: compilers may disallow optimisations for functions with
exception specifications (for example - yes, this doesn't apply to
non-core code);
- virtual: want to change the throw specs? the throw spec forms part of
the function signature (AFAIK) so you have to change all of the children
too;
- template: you can't tell what the types they operate on may throw

Basically, from all I've read, I'm unlikely to use anything but a
throw(), in the cases above. And even then I'd probably use a comment
too ;)

-- 
Neil