🚀 go-pugleaf

In article 100000@zorglub.cae.ca, dak <pierreba@poster.cae.ca> writes:

>clamage@Eng.Sun.COM (Steve Clamage) wrote:

>> In article 41C67EA6@ecid.cig.mot.com, Joe Walker <walkerjj@ecid.cig.mot.com> writes:
>> >
>> >As I understand the DWP this is legal:
>> >
>> >  void func () throw ()		// #1
>> >  {
>> >    throw 1;
>> >  }

>> >The question is, why?
>> >Surely this should be a compiler error.

>> It is an error if the throw statement is executed, but not otherwise.
>> That is, "func" might not ever be called.

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

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

>> That may sound like nit-picking, but it avoids having to 
>> decide whether examples like the following are valid:
>> 
>> void f1(int j) throw()	// #2
>> {
>> 	if( j == 0 )
>> 		throw 1; // the programmer believes j is always > 0
>> }
>> 
>> #include <math>
>> void f2(unsigned x) throw()	// #3
>> {
>> 	if( std::sqrt((double)x) ) < 0.0 )
>> 		throw 1; // really can't happen, but must compiler deduce that?
>> }
>
>
>
>Why the need to decide ? 

We are talking about the standard. It must define what is well-formed code
and what is not. The number of valid C++ functions having throw expressions
is unbounded, so the standard cannot simply list all the valid functions.
It must instead provide a method for determining whether an as-yet
undreamed-of function is valid.

Example #1 above is clearly invalid in the sense that it will always result
in a call to unexpected(). But what do we say in the standard to make it a
compile-time error? The rule would have to involve determining whether
the throw expression would be executed. In the general case (and the
standard must deal with the general case) that is impossible -- it is
equivalent to solving the halting problem.

In example #2, we cannot know whether the throw expression will be
executed. Is the function valid? If so, why? If not, why not? (Don't
answer yet.)

Example #3 looks a lot like #2, but the difference is that according to
the semantics of "unsigned" and "std::sqrt(double)", the throw expression
can never be executed -- the "if" condition is always false. If #2
is invalid, what sort of compile-time analysis do we require compilers to do
in order to allow #3? If #3 is to be invalid, how about if we replace it with
	if(0) throw 1;

Don't answer my questions yet, because I have one more example:

	void g(); // has no throw-specification, can throw anything

	void f4() throw()	// #4
	{
		g(); // valid or not?
	}

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.

Any answers about #1, #2 and #3 must also make sense with regard to #4.
If #4 is valid, how can #2 be invalid? If #2 is valid, how do we write
a rule that makes #1 invalid? You can't make rules like "If the flow of
control must pass through ..." because in general that is unknowable.

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



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