Valentin Bonnard wrote:
>

>
> The intent of standard is that throwing from a destructor has a well
> defined behaviour is every case, and that all destructors and
> desallocation
> functions (which are kind of destructors) are called when a destructor
> exit with an exception.

That is my interpretation as well.

>
> Warning:
>
>  Many people, who haven't read the standard, claim otherwise because
>  they believe that throwing an exception in a destructor is bad, and
>  has to be discouraged (they put their moral opinions in the mouth of
>  the standard).
>

Certainly letting an exception out of a destructor can result in very
bad consequences; this has been discussed before. I starting to get
worried, however, that some implementations may be seriously flawed. My
worry is prompted by simple pragmatism.

In an earlier posting I gave an example where an implementation called
the wrong deallocation function because an exception was allowed to
escape a destructor; at the time I had tested only one implementation.
Today I tested three more. The result is that either:

1) Three of four implementations are incorrect when an exception escapes
a destructor. HP's aCC (B3910B A.01.18), compiled with +eh, handled the
situation in the expected manner.
2) My code is defective.

Given one successful implementation I lean towards (1) as the correct
hypothesis. In this case, I'd strongly suggest, for pragmatc reasons,
such as your using g++, SunPro 4.2, or MSVC 6, that you carefully
control the situations where you let an exception out of a destructor.

I've given a listing (modified from the original, designed to compile
using g++, SunPro 4.2, aCC, and MSVC 6 without undue complaints) below.
It is interesting to note (use aCC -Fc -..c +eh sourceFile.C) that the
line

  try { delete new D(1); ... } catch(...) {...}

generates about 60 lines of C code!


Regards, John.


#include <new.h>
#include <stdlib.h>
#include <stdio.h>
#include <iostream.h>

void* operator new( size_t sz ) { return malloc( sz ); }
void operator delete( void* p ) { free( p ); printf("%x\n",p); }

struct B { virtual ~B(){} };
struct D : public B {
  int Throw;
  D(int xThrow = 0) : Throw(xThrow) {}
  void* operator new( size_t );
  void operator delete( void* );
  ~D();
};

D::~D() { if ( Throw ) throw 42; }

void* D::operator new( size_t sz )
{
  D* ptr = (D*) malloc( 2*sizeof(D) );
  cout << "D::op new(" << sz << ") ===> " << (ptr+1) << endl;
  return ptr+1;
}

void D::operator delete( void* p )
{
  cout << "D::op del(" << p << ")\n";
  D* x = ((D*)p) - 1;
  free( x );
}

int main()
{
  cout << "1\n" << flush;
  try { D d; } catch(...) {}
  cout << "2\n" << flush;
  try { delete new D; } catch(...) {}
  cout << "3\n" << flush;
  try { "xyzzy"; delete new D(1); } catch(...) { cout << "[exception
caught]" << flush; }
  cout << "4\n" << flush;
  return 0;
}

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Valentin Bonnard wrote:
>Yaroslav Mironov wrote:
>> I've tried this on Borland C++ 5.5 and it doesn't call the corresponding
>> delete operator of my class.
>
>That's _not_ surprising.


Well then, I tried it with GCC, the result being the same. Are there any
"surprising" compilers?

Yaroslav


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Destructors must not throw exceptions or allow them to leak out.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <y5IJCtA9gaG6EwFc@ntlworld.com>,
  Francis Glassborow <francisG@robinton.demon.co.uk> wrote:
> In article <3A19426B.C3A@free.fr>, Valentin Bonnard
> <Valentin.Bonnard@free.fr> writes

The question was, in the following expression:

    A* p ;
    delete p ;

Is the memory freed if the destructor for A exits because of an
exception.

> >> Regardless of whether the destructor throws in line 1 or not, the
memory a
> >> is pointing to is freed.

> >> Am I right?

> >Yes.

> I am not disagreeing with you (I haven't got time to fish around in
> the standard) but this would mean that not only would you have an
> incompletely destroyed object, but the base memory on which it was
> built would disappear leaving nothing but ghosts behind. I cannot
> imagine why you would want to do this.

Probably to avoid memory leaks.  What do you want to happen?
Typically, the throw will cause me to leave the function where p is
declared, so I cannot delete the memory manually anyway.  And since A
has been (partially) destructed, I can't call delete p a second time
without invoking the destructor on an incomplete object -- undefined
behavior.

I'm pretty sure that 1) operator delete will be called on the memory,
and 2) if the destructor of A throws, the destructors for any base
classes or members will be called as part of stack unwinding, before
deleting the memory.

I can't find the text for 1 -- if it is missing, it can only be an
oversight.  The second point is guaranteed by 15.2/2.

--
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Andrew J Robb wrote:
>
> Destructors must not throw exceptions or allow them to leak out.

There's not much point in making a bare unsupported statement like that.
Would you care to explain your reasons for that statement? Are you
claiming that it's illegal, or simply bad design? I'd recommend taking a
look at a few of the other messages on this thread before deciding.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Andrew J Robb wrote:

> Destructors must not throw exceptions or allow them to leak out.

What do you mean ?

You followuping-to my message, so I believe that you want answer
it. But you haven't quoted a single line of my message.

Should I take your message as ``What you say is plain wrong.'' ?

You can tell me that I am wrong, but if so, please indicate which
part of my message is wrong.

You could as well have said 2 + 2 = 5. Not only it isn't correct,
but it's getting nowhere.

--

Valentin Bonnard

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Christopher Eltschka wrote:
>
> Valentin Bonnard wrote:
> >
> > Yaroslav Mironov wrote:
> >
> > > (Note: I know that throwing from destructors is not generally accepted)
> >
> > But is accepted by the standard (and also me, at least).
> >
> > > The wording of 15.2/2 makes me think that should an exception be thrown from
> > > a destructor when deleting an object, the corresponding deallocation
> > > function would be called anyway.
> > >
> > > That is:
> > >
> > > A * a = new A;
> > >
> > > delete a;    // line 1
> > >
> > > Regardless of whether the destructor throws in line 1 or not, the memory a
> > > is pointing to is freed.
> > >
> > > Am I right?
> >
> > Yes.
> >
> > The intent of standard is that throwing from a destructor has a well
> > defined behaviour is every case, and that all destructors and
> > desallocation
> > functions (which are kind of destructors) are called when a destructor
> > exit with an exception.
> >
> > Warning:
> >
> >  Many people, who haven't read the standard, claim otherwise because
> >  they believe that throwing an exception in a destructor is bad, and
> >  has to be discouraged (they put their moral opinions in the mouth of
> >  the standard).
>
> How is saying that something is bad and should be discouraged in
> any way "putting their moral opinions in the mouth of the standard"?

Many people only find in the standard what they want it to say, and
only that (at least in this newsgroup). When two interpretations of
the standard are equally resonnable, people usually choose the one
they want, and claim that it is more resonnable than the other one.

(Some even do the same with law.)

> The standard isn't about good and bad coding praxis, it's about
> allowed and not allowed C++ constructs, and their behaviour. Even
> deprecated features are no judgement (although you can expect that
> those who made them deprecated considered them bad).

Indeed.

Still, many people try to show that the standard support their
claim that something is bad coding practice.

> And I don't see any relation between having read the standard and
> discouraging exceptions thrown from destructors (except that people
> who have read the standard may more likely see the problems which
> exceptions from destructors may cause).

People who haven't read the standard keep repeating what they
read in old misinformed books, and what they heard from misinformed
people.

I believe that informed people recommand the use of exceptions
more that misinformed people. (Whereas totally uninformed people
also recommand their use, without any concern of exception safety.)

> I never have heared anyone say that throwing from destructor is
> _undefined_.

Probably because your have never read comp.lang.c++.moderated.

> Indeed, the results are well defined - they are just
> not what you would want to happen in certain cases.

That's right.

> The technical problems could be solved if uncaught_exception()
> returned an int instead of a bool, indicating the _number_ of
> currently active exceptions. Unfortunately, as specified,
> uncaught_exception() is close to useless.

Interresting question, but that's another debate and I don't want
to discuss it in this post.

--

Valentin Bonnard

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Herb Sutter wrote:

> Just to add a few clarifications:
>
> Valentin Bonnard <Valentin.Bonnard@free.fr> writes:

> The language portion of the standard does not disallow throwing
> destructors, of course. That means that, according to today's standard,
> you may write conforming code that has throwing destructors... you just
> can't use them with the standard library.

Exactly !

> The language does, however, make a similar guarantee for the parallel
> case of deallocation functions: it's precisely why all of the standard
> deallocation functions are required not to throw.

W/o such guaranty, you wouldn't be able to easilly write no-throw dtors.

> Now try this:
>
>   A* a = new A[10];
>   delete[] a; // assume every 2nd destructor throws: what's the result?
>
> >The intent of standard is that throwing from a destructor has a well
> >defined behaviour is every case,
>
> Well defined, but not necessarily useful: above, the well-defined
> behavior is to terminate the program immediately without further
> unwinding the stack, destroying globals, or performing any other
> cleanup.

Yes, throwing twice from destructors causes this problem.

> >and that all destructors and desallocation
> >functions (which are kind of destructors)
>
> Incidentally, this "destructor-deallocator" equivalency is an imporant
> point. The former are required by the standard library not to throw; the
> latter are required in both the standard language and the standard
> library not to throw (well, the provided ones are required not to throw,
> but there's no text actually forbidding replacement operators delete and
> delete[] to throw; that's a loophole IMO, not the intent of the
> committee as far as I know it).

I know that exception-specs (ES) aren't part of the type (IMO
they should), but can you replace a non-reserved function with
one w/o ES when the provided default function has one ?

> >are called when a destructor
> >exit with an exception.
>
> Not necessarily. See counterexample above... "go to terminate(), go
> directly to terminate(), do not pass catch, do not collect unwound
> objects..."

;)

--

Valentin Bonnard

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Valentin Bonnard wrote:
>
> Herb Sutter wrote:
...
> > Incidentally, this "destructor-deallocator" equivalency is an imporant
> > point. The former are required by the standard library not to throw; the
> > latter are required in both the standard language and the standard
> > library not to throw (well, the provided ones are required not to throw,
> > but there's no text actually forbidding replacement operators delete and
> > delete[] to throw; that's a loophole IMO, not the intent of the

Yes there is: 17.4.3.6p2: "... the effects are undefined ... if any
replacement function ... throws an exception, unless specifically
allowed in the applicable Required behavior paragraph." The Required
behavior paragraphs for operator delete() and operator delete[]() make
no mention of any allowed exceptions.

> > committee as far as I know it).
>
> I know that exception-specs (ES) aren't part of the type (IMO
> they should), but can you replace a non-reserved function with
> one w/o ES when the provided default function has one ?

I can't find any statements prohibiting that.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

(Note: I know that throwing from destructors is not generally accepted)

The wording of 15.2/2 makes me think that should an exception be thrown from
a destructor when deleting an object, the corresponding deallocation
function would be called anyway.

That is:

A * a = new A;

delete a;    // line 1

Regardless of whether the destructor throws in line 1 or not, the memory a
is pointing to is freed.

Am I right?

I've tried this on Borland C++ 5.5 and it doesn't call the corresponding
delete operator of my class.

The code was:

#include <iostream>

struct A
{
 void * operator new(size_t size)


   std::cerr << "Allocated " << size << " bytes\n";
   return new char[size+1];
 }

 void operator delete(void *p)
 {
  std::cerr << "Deallocated\n";
  delete [] static_cast<char*>(p);
 }

 ~A() {std::cerr << "Destructor called\n"; throw 0;}
};

int main()
{
 try
 {
  A * a = new A;
  delete a;
 }
 catch(...) {}

 std::cerr << "Reached the end of main()\n";
}


The output was:

Allocated 8 bytes
Destructor called
Reached the end of main()

Yaroslav


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Yaroslav Mironov wrote:

> (Note: I know that throwing from destructors is not generally accepted)

But is accepted by the standard (and also me, at least).

> The wording of 15.2/2 makes me think that should an exception be thrown from
> a destructor when deleting an object, the corresponding deallocation
> function would be called anyway.
>
> That is:
>
> A * a = new A;
>
> delete a;    // line 1
>
> Regardless of whether the destructor throws in line 1 or not, the memory a
> is pointing to is freed.
>
> Am I right?

Yes.

The intent of standard is that throwing from a destructor has a well
defined behaviour is every case, and that all destructors and
desallocation
functions (which are kind of destructors) are called when a destructor
exit with an exception.

Warning:

 Many people, who haven't read the standard, claim otherwise because
 they believe that throwing an exception in a destructor is bad, and
 has to be discouraged (they put their moral opinions in the mouth of
 the standard).

> I've tried this on Borland C++ 5.5 and it doesn't call the corresponding
> delete operator of my class.

That's _not_ surprising.

--

Valentin Bonnard

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Valentin Bonnard wrote:
>
>
> The intent of standard is that throwing from a destructor has a well
> defined behaviour is every case, and that all destructors and
> desallocation
> functions (which are kind of destructors) are called when a destructor
> exit with an exception.
>
> Warning:
>
>  Many people, who haven't read the standard, claim otherwise because
>  they believe that throwing an exception in a destructor is bad, and
>  has to be discouraged (they put their moral opinions in the mouth of
>  the standard).

Well the biggest force to be dealt with is that you may end up in
terminate() if the destruction is occurring curing the unwinding of
the stack from another exception.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Valentin Bonnard wrote:
>
> Yaroslav Mironov wrote:
>
> > (Note: I know that throwing from destructors is not generally accepted)
>
> But is accepted by the standard (and also me, at least).
>
> > The wording of 15.2/2 makes me think that should an exception be thrown from
> > a destructor when deleting an object, the corresponding deallocation
> > function would be called anyway.
> >
> > That is:
> >
> > A * a = new A;
> >
> > delete a;    // line 1
> >
> > Regardless of whether the destructor throws in line 1 or not, the memory a
> > is pointing to is freed.
> >
> > Am I right?
>
> Yes.
>
> The intent of standard is that throwing from a destructor has a well
> defined behaviour is every case, and that all destructors and
> desallocation
> functions (which are kind of destructors) are called when a destructor
> exit with an exception.
>
> Warning:
>
>  Many people, who haven't read the standard, claim otherwise because
>  they believe that throwing an exception in a destructor is bad, and
>  has to be discouraged (they put their moral opinions in the mouth of
>  the standard).

How is saying that something is bad and should be discouraged in
any way "putting their moral opinions in the mouth of the standard"?
The standard isn't about good and bad coding praxis, it's about
allowed and not allowed C++ constructs, and their behaviour. Even
deprecated features are no judgement (although you can expect that
those who made them deprecated considered them bad).

And I don't see any relation between having read the standard and
discouraging exceptions thrown from destructors (except that people
who have read the standard may more likely see the problems which
exceptions from destructors may cause).

I never have heared anyone say that throwing from destructor is
_undefined_. Indeed, the results are well defined - they are just
not what you would want to happen in certain cases.

The technical problems could be solved if uncaught_exception()
returned an int instead of a bool, indicating the _number_ of
currently active exceptions. Unfortunately, as specified,
uncaught_exception() is close to useless.

>
> > I've tried this on Borland C++ 5.5 and it doesn't call the corresponding
> > delete operator of my class.
>
> That's _not_ surprising.

Why not?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Just to add a few clarifications:

Valentin Bonnard <Valentin.Bonnard@free.fr> writes:
>Yaroslav Mironov wrote:
>> (Note: I know that throwing from destructors is not generally accepted)
>
>But is accepted by the standard (and also me, at least).

That's partly false. Destructors that emit exceptions are flatly
disallowed in the standard _library_, in 17.4.4.8/3:

  "No destructor operation defined in the C++ Standard Library
  will throw an exception."

See also 17.4.3.6/2 (4th bullet) to see that this applies not only to
destructor operations defined in the standard library itself (e.g.,
vector::~vector), but also to any type on which the standard library
templates may be instantiated:

1 In certain cases (replacement functions, handler functions, operations
                                                              ^^^^^^^^^^
  on types used to instantiate standard  library  template  components),
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  the  C++ Standard Library depends on components supplied by a C++ pro-
  gram.  If these components do not meet their requirements,  the  Stan-
  dard places no requirements on the implementation.

2 In particular, the effects are undefined in the following cases:
[...]
  --if any replacement function or handler function or destructor opera-
    ^^^^^^                                             ^^^^^^^^^^^^^^^^^
    tion  throws an exception, unless specifically allowed in the appli-
    ^^^^^^^^^^^^^^^^^^^^^^^^^
    cable Required behavior paragraph.

The language portion of the standard does not disallow throwing
destructors, of course. That means that, according to today's standard,
you may write conforming code that has throwing destructors... you just
can't use them with the standard library.

The language does, however, make a similar guarantee for the parallel
case of deallocation functions: it's precisely why all of the standard
deallocation functions are required not to throw.

>> The wording of 15.2/2 makes me think that should an exception be thrown from
>> a destructor when deleting an object, the corresponding deallocation
>> function would be called anyway.
>>
>> That is:
>>
>> A * a = new A;
>>
>> delete a;    // line 1
>>
>> Regardless of whether the destructor throws in line 1 or not, the memory a
>> is pointing to is freed.
>>
>> Am I right?
>
>Yes.

Now try this:

  A* a = new A[10];
  delete[] a; // assume every 2nd destructor throws: what's the result?

>The intent of standard is that throwing from a destructor has a well
>defined behaviour is every case,

Well defined, but not necessarily useful: above, the well-defined
behavior is to terminate the program immediately without further
unwinding the stack, destroying globals, or performing any other
cleanup.

>and that all destructors and desallocation
>functions (which are kind of destructors)

Incidentally, this "destructor-deallocator" equivalency is an imporant
point. The former are required by the standard library not to throw; the
latter are required in both the standard language and the standard
library not to throw (well, the provided ones are required not to throw,
but there's no text actually forbidding replacement operators delete and
delete[] to throw; that's a loophole IMO, not the intent of the
committee as far as I know it).

>are called when a destructor
>exit with an exception.

Not necessarily. See counterexample above... "go to terminate(), go
directly to terminate(), do not pass catch, do not collect unwound
objects..."

>Warning:
>
> Many people, who haven't read the standard, claim otherwise because
> they believe that throwing an exception in a destructor is bad, and
> has to be discouraged (they put their moral opinions in the mouth of
> the standard).

Actually, it's sufficient to read what the standard already explicitly
says.

Herb

---
Herb Sutter (mailto:hsutter@peerdirect.com)

CTO, PeerDirect Inc. (http://www.peerdirect.com)
Contributing Editor, C/C++ Users Journal (http://www.cuj.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3A19426B.C3A@free.fr>, Valentin Bonnard
<Valentin.Bonnard@free.fr> writes
>> Regardless of whether the destructor throws in line 1 or not, the memory a
>> is pointing to is freed.
>>
>> Am I right?
>
>Yes.

I am not disagreeing with you (I haven't got time to fish around in the
standard) but this would mean that not only would you have an
incompletely destroyed object, but the base memory on which it was built
would disappear leaving nothing but ghosts behind. I cannot imagine why
you would want to do this.

>
>The intent of standard is that throwing from a destructor has a well
>defined behaviour is every case, and that all destructors and
>desallocation
>functions (which are kind of destructors) are called when a destructor
>exit with an exception.

Francis Glassborow      Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]