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

Stefan Seefeld wrote:
> Neil Pilgrim wrote:
> > Stefan Seefeld wrote:
> >>Neil Pilgrim wrote:

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

Sure, but you didn't specify that this was just applying to Fresco code,
though perhaps I should have taken that to be implicit ;)

> > TBH I would agree, if throw specifications were compile-time checked;
> 
> They are, at least on some compilers (mipspro, for example)

Completely checked? as with java (AIUI)? Is that full-program
compilation?
See below for what I meant by 'compile-time checking' - I should have
been more precise.

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

...depending upon the run-time behaviour constraints. If there was no
run-time difference, ie. throw specs did nothing, then I'd use them ;)

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

By this I meant that I'd prefer to use them on every function, or none.
Not needing to determine whether its beneficial on a case by case basis.

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

OK, yes, a compiler could take this route, ie. assume that other
exceptions will never be thrown and optimise accordingly. However it
also needs to add the checks for the exception specification, assuming
that it still calls unexpected() if the conditions are not met.

So it may optimise, but then normally adds extra code which does the
opposite.

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

Well I'd break down the appropriate compile-time work into multiple
possible parts, including:
1 signature checking
2 optimising according to exception specs assumed to be met
3 inserting run-time code to check that a function can only throw what
it should
4 determining that exception specs will always be met and not add any
extra code

AIUI:
(1) should always present in a conforming compiler. 
(2) should occur in 'good' compilers, but some refuse to optimise when
finding exception specifications.
(3) is common in C++ due to the way that exception specifications work
and generally slows down the code.
(4) is rare in C++, again due to the way that exception specifications
work.

Therefore my summary would be that exception specifications are ok for
use throughout a program if you:
- can accept code which is likely to be less efficient than otherwise,
- want the possible benefit that unexpected() offers over an uncaught
exception, for debugging.

Wrt just the documentation aspect, throw specs or comments work just as
well AFAICT - the choice boils down to whether you accept/want the
run-time behaviour.

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

Does this actually happen? You still need the unexpected()-checking code
with that anyway...assuming that it cannot check which exceptions might
be thrown.


It is since exception checking does not always give a benefit at
run-time that I would not choose to apply exception specs across the
board, only when debugging or in non-mainline code. I'd prefer a
universal application or non-application (using catch blocks only where
needed, instead), not something inbetween, and so would choose not to
use exception specs based on what I understand at this point.

What's wrong with my argument? :)

-- 
Neil