try, finally

[Noel Yap]

On Fri, Mar 21, 2008 at 3:50 PM, Brian Dessent <brian@dessent.net> wrote:
> Jason Cipriani wrote:
>
>  > One feature that I have
>  > always desired the most in a C++ compiler is strict enforcement of
>  > throw() clauses.
>
>  Since you seem to be well aware of the design of C++ exceptions you
>  should realize why this is a near impossibility.  In order for the
>  compiler to enforce a throw declaration, it would have to have complete
>  knowledge of the entire outbound call graph of the function.  Two things
>  stand in the way of this: separate compilation and function
>  pointers/virtual functions.  The problem of separate compilation (i.e.
>  that the compiler only has local knowledge of a given translation unit
>  at any time) can somewhat be dealt with by using gcc --combine, but
>  that's more of a crutch.  It won't fix the issue that necessitated
>  separate compilation in the first place: the explostion of complexity as
>  the size of one "unit" grows.  (And here I'm not speaking at all of the
>  human factors of keeping source units small and maintainable, I'm
>  strictly referring to the algorithmic complexity experienced by the
>  compiler.)
>
>  Longer term, the gcc LTO project will eventually provide a better
>  infrastructure for whole-program optimizations, but it will still not be
>  able to see past library boundaries.  That might not be a problem if
>  like you say C++ had been more Java-like and required accurate throw
>  declarations from the beginning.  But there is just no reasonable way to
>  expect that now, so from a compiler standpoint the only way to implement
>  enforcement of throw declarations would be to "see down into" all
>  library code (unrealistic for all but perhaps embedded applications) or
>  to rewrite all library code to include accurate throw declarations in
>  their headers and then tell the compiler it can trust them.  Either way,
>  it's a ton of work.
>
>  And this hasn't even begun to address the issue of function pointers and
>  virtual methods, where the call graph can't even be known at compile
>  time.  I'm sure you could construct a pathological testcase without too
>  much effort for which it would be provably impossible to enforce throw
>  declarations at compile or link time.
>
>  However, you may be interested in Brendon Costa's EDoc++ which consists
>  of a hacked up gcc that embeds additional exception and callgraph data
>  into the objects, and a post processing tool to recover, combine, and
>  analyze it all at link time.  <http://edoc.sourceforge.net/>

I agree with all this and wanted to add:
+ C linkage (which may be included above) -- since C functions don't
have exception specs, how should they be handled especially if they
wind up calling C++ functions through callbacks
+ template functions -- what if the exception spec is dependent upon
the template parameters?

Noel