clamage@Eng.sun.com (08 Dec 95):

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

... or a try-catch statement, which catches other exceptions and must not
re-throw them.

> Such a rule would make exceptions specifications completely useless.

If a function can throw an exception although it was declared as throw(),
what's the point of having such a throw declaration at all ??
Wether a function can throw an exception or not could be documented with
the meaning of the function parameters and the use of the function.
Why does the compiler need to be told this, if it doesn't do anything to
prevent functions from behaving differently ??

================================================================================
 Claus Andre Faerber                                     <claus@faerber.muc.de>
================================================================================
## CrossPoint v3.1 ##

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

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

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



Why the need to decide ? Again, comparison with return value, IMO, shows
that not to be a valid reason. I believed that the real reason was to
somehow relax the design of templates and allow a wider range of types to
be use (and resolve any design error at run-time). All time seems quite
contrary to the rest of the C++ design which is to check things at
compile time.

While I understand that some people may think it necessary to allow
non-throwing functions to call functions without throw specs, or even
functions with throw specs, I don't see how it can extent to actual throw
expression...

So am I right to think the rule was decided upon due to templates ?




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

As I understand the DWP this is legal:

  void func () throw ()
  {
    throw 1;
  }

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

What is the justification for this?

TA,
Joe.

--
  ____
 |___ | ___  ___   EMail: walkerjj@sweng.ecid.cig.mot.com
 _  | |/ _ \| __|  SMail: Motorola, 16 Euroway, Blagrove, SWINDON SN58YQ
| |_| | (_) | _|   Tel:   [+44/0] 793 54 5346
 \___/ \___/|___|  Fax:   [+44/0] 793 54 1228


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

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

That may sound like nit-picking, but it avoids having to
decide whether examples like the following are valid:

void f1(int j) throw()
{
 if( j == 0 )
  throw 1; // the programmer believes j is always > 0
}

#include <math>
void f2(unsigned x) throw()
{
 if( std::sqrt((double)x) ) < 0.0 )
  throw 1; // really can't happen, but must compiler deduce that?
}

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

Joe Walker (walkerjj@ecid.cig.mot.com) wrote:

|> As I understand the DWP this is legal:

|>   void func () throw ()
|>   {
|>     throw 1;
|>   }

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

|> What is the justification for this?

Basically for the same reason that returning a reference to a local
variable isn't a compiler error.  It is practically impossible for the
compiler to detect in the general case, and practically impossible to
find wording exact enough for a standard to define when it must be
detected by the compiler, and when the compiler is not required to
detect it.

Consider the following:

 extern void g( int ) throw (int ) ;

 void
 f() throw()
 {
  g( 0 ) ;
 }

Should the compiler complain here?  Apparently, f() may throw an
exception (through g).  But suppose in fact that I know that g cannot
throw an exception if the parameter is 0.  Should I still be required to
enclose it in a try block, to shut up the compiler?

In the direct case that you give as an example, I would imagine that any
reasonable compiler will generate a warning, the same as they do if you
blatantly return the address of a local variable.  (Note that in both
cases, there are potentially reasons why you might *want* to do this.)
--
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils,    tudes et r   alisations en logiciel orient    objet --
              -- A la recherche d'une activit    dans une region francophone


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