🚀 go-pugleaf

"Paul D. DeRocco" <pderocco@ix.netcom.com> writes:


>So consider a simple function that I _know_ won't throw an exception:

>    int sumsq(int a, int b) { return a * a + b * b; }

>Do I put a throw() clause on it or not? If the compiler uses throw() 
>only as an optimization hint to the caller, then I most definitely 
>_do_ want to use it. If, on the other hand, the compiler treats 
>throw() as a command to add code to prevent any exceptions from 
>propagating out of the function, then I most definitely _don't_ want 
>to use it. If I guess wrong about the interpretation, I've bought 
>myself nothing, and cost myself something. And unless it's spelled out 
>in the language definition, I can't make _either_ choice without 
>knowing that it won't ever be compiled with a compiler that was 
>designed with the opposite choice in mind.

You probably don't need to worry about bad effects of adding empty
exception-specifications.

If sumsq doesn't have an exception-specification, the compiler must
assume that any call to sumsq could result in any exception being
thrown. If sumsq has a throw() clause, the compiler can assume that
no exceptions will escape from sumsq, and perhaps can avoid adding
exception-handling code to the calling location. At the call
site, there are no disadvantages to sumsq's empty exception-spec,
and there are potential advantages, as you noted in your article.
(A function that calls sumsq might also call other functions that
can throw exceptions, in which case you probably get no benefit at
that call site.)

If a function has an empty exception-spec, the compiler must in
general add scaffolding to the function to ensure that any exceptions
occurring in the function do not escape. In the case of sumsq, the
compiler may be able to determine that no exception is possible,
and not generate the extra code. If the extra code is generated,
on most implementations it does not add to the run time of the
function.  Typically none of the extra code is executed unless an
exception actually occurs and would otherwise escape from the function.

--
Steve Clamage, stephen.clamage@eng.sun.com

[ To submit articles: Try just posting with your newsreader.  If that fails,
		      use mailto:std-c++@ncar.ucar.edu
  FAQ:    http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
  Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]