🚀 go-pugleaf

In article <smeyersDHwpw1.48n@netcom.com>,
   smeyers@netcom.com (Scott Meyers) wrote:
>There is a small performance penalty to be paid for each exception
>specification, because they have to be checked at runtime to be sure
>they're not violated.  This typically increases code size and decreases
>code speed, though the cost of the feature varies from compiler to
>compiler.

Good point, but isn't the exception spec checked only when there actually is
an exception?  If so, then there should be no penalty in normal operation, to
bastardise the old 'only pay for it if you use it' line.  (Assuming that
exceptions are being used properly and not wrongly pressed into service as
error returns or lazy loop exits, natch.)

[Aside: Perhaps I could turn around my original question (whether there's a
good reason not to have exception specs on everything):

	When would you NOT want an exception spec on a function?

To start, I don't think that 'constrains future derived classes' is a good
answer (could even point to design flaws), since we should be able to
consciously write an exception spec that's flexible/adaptable enough for
children to use/extend, even if by the last resort of deriving their own
exception classes from the ones the parent's member function is using.  Better
yet, a class's exception specs should name exception classes as high in the
hierarchy as possible/logical, specifically in order to provide flexibility
for kids and grandkids.]

>In addition, it's probably not practical to get an exception specification
>for every function used in a program, because existing libraries typically
>don't have them.  That being the case, it will be close to impossible to
>guarantee they are never violated.

This brings up a good stylistic question, because you can indeed guarantee
they're never violated simply by always including a catch(...) [there is a
better alternative, see below].  However, this strikes me as exceedingly poor
style because each function should only need to catch those exceptions it has
enough context to decide handling policy for (i.e. many should pass right
through uncaught for higher layers to deal with), but standardising on
catch(...)es breaks this.  (You might say this solution looks good, but
there's a catch(...).)

My inclination here would be to say "don't 'solve' it with catch(...)es, solve
it with your own unexpected() handler that logs and rethrows" despite my other
reservations about reliance on this kind of unexpected().  While I agree that
we can almost never guarantee that any given ex-spec won't be violated (that's
why unexpected() exists in the first place after all), at least this way we
can immediately track the culprit when it does happen.

Bottom line, can we really go wrong by trying to provide exception specs?  It
seems to me that the above argument ('if code we use doesn't use ex-specs how
can we guarantee ours won't be violated') can be applied just as well to any
single function with an exception spec as to 'ex-specs everywhere'... so
taking this to the extreme we might argue we should never write ex-specs at
all.  Since it's clear to me that this isn't a good conclusion in any single
case, why should it cause us to drop ex-specs in even the most general case --
i.e. to supply them ubiquitously in most or all places in our own
classes/code?  Again, how can we go wrong by trying to provide an ex-spec?

If it turns out that there is a runtime overhead even when exceptions aren't
thrown, that would be a valid reason to use ex-specs sparingly/judiciously.
If not, I'm still trying to think of any drawbacks besides the original
"tedium" and "dependencies (all those #includes)" concerns I mentioned.

>"More Effective C++" does have some material on EH, including the above.
>The book will be out in January.

Good to hear.  Please make a short announcement when it's available; thanks.

Herb

	

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Herb Sutter                 2228 Urwin, Ste 102         voice (416) 618-0184
Connected Object Solutions  Oakville ON Canada L6L 2T2    fax (905) 847-6019
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]