🚀 go-pugleaf

>>> Joe Walker <walkerjj@ecid.cig.mot.com> writes:
>>>> As I understand the DWP this is legal:
>>>>   void func () throw () {throw 1;}
>>>> The question is, why?  Surely this should be a compiler error.

>> clamage@Eng.Sun.COM (Steve Clamage) wrote:
>>> It is an error if the throw statement is executed, but not otherwise.
>>> That is, "func" might not ever be called.

> dak <pierreba@poster.cae.ca> writes:
>> But how does this affect the fact that it throws when it says it doesn't ?
>> A function returning the wrong type will cause a compiler disgnostic even
>> if it is never called (it could be checked at run time...)

clamage@Eng.sun.com (Steve Clamage) writes:
> The difference is that the return type of a function is known statically.
> The runtime behavior of a program cannot in general be known until runtime.

As dak just said, you could say that about a conditional return statement too.

In fact, you're being disingenuous.  This issue was debated here a while back
by people (including you, I'm sure) who all had valid points of view.  No one
claimed that compile-time exception type checking couldn't be done.  They just
argued its safety versus its oppressive restrictiveness.

It would be perfectly reasonable for the compiler to disallow any throw
statement whose exception type is not handled by an enclosing handler and not
declared in the enclosing function's exception signature.  Furthermore, it
would also be perfectly reasonable to disallow implied or explicit calls of
functions whose exception signatures specify that they *might* throw such a
type at run time.

Contrary to what you say, an exception signature is very much like a return
type.  Both can be enforced at compile time.  In fact, in Modula-3, a function
return is considered a kind of exception throw!

With compile-time exception type checking, there would be complete run-time
exception safety.  No unexpected exceptions would ever occur.  And it would
still allow the style of programming where exceptions are not specified at
compile time, via the `throw (...)' ("throws anything") construct, which is
the default in the absence of an exception signature!  It would be much like
const-correctness, a style which is available to C and C++ programmers, but
need not be used.

There *would* be problems: Libraries whose functions used the `throw-anything'
style would need wrappers when used by code that used the `specific exception
signatures' style.  Template code, in particular, would be troublesome -- the
text of the template could not be written knowing what the functions it called
might throw.  Also, functions would need ungainly exception signatures or
catch clauses, since they would all need to include a cumbersome list of
standard exceptions that could be generated by often-used (standard and
vendor) library routines and operators.

So you could make a valid argument that compile-time restriction would hamper
programmers too much.  But it's certainly debatable.  And you can't plausibly
argue that compile-time enforcement can't be done!

> Don't answer my questions yet, because I have one more example:
> 	void g(); // has no throw-specification, can throw anything
> 	void f4() throw() {g();}
> 
> The current rule, related to the original question, is that function f4
> is OK, and an error results only if g actually exits via an exception.
> The alternative would be to require that every function called have an
> exception specification at least as restrictive as the calling function.
> Such a rule would make exceptions specifications completely useless.

Maybe, maybe not.  Doesn't Modula-3 do it?  (I'm not sure.)

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