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

Neil Pilgrim wrote:
> 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'.

Well, that is true if the ORB can't know whether the object exists or not,
i.e. if the respective code is managed by the application, for example
if you use a ServantManager. That doesn't apply to Fresco (yet), though.

>>>- 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;

They are, at least on some compilers (mipspro, for example)

> since they're not, I believe its far better to just use a comment
> instead.

Readable code is much more worth than any comments you could come up with.

> 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);

see Nathaniel's comment: a 'throw' spec is a restriction wrt. possible
exceptions, so better optimization is possible, not less.

> - 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;

Didn't you just say that throw specs are not compile-time checked ? How
does that align with your new statement of throw specs being part of
the signature ? ;-)

> - template: you can't tell what the types they operate on may throw

Well, that boils down to the other point: if they are compile-time checked,
this would provide a good means to restrict what domain the template
can operate on, i.e. the compiler could infer requirements for the parameter
of the template.

Regards,
		Stefan