From -6427873933873841262
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f78e5,9723061da44e5214
X-Google-Attributes: gidf78e5,public
From: "Ed Brey" <brey@afd.mke.etn.com>
Subject: Re: Exception while throwing an exception?
Date: 1999/09/09
Message-ID: <7r8sdg$7db1@interserv.etn.com>#1/1
X-Deja-AN: 523063623
X-NNTP-Posting-Host: firewall.etn.com
Approved: stephen.clamage@sun.com (comp.std.c++)
References: <37D3E50E.A13D8AFC@prodigy.net> <slrn7t8m3o.too.sbnaran@localhost.localdomain> <37D5AF88.8681E2AE@prodigy.net>
X-UID: 0000000001
X-Priority: 3
X-Status: $$$T
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Organization: Eaton Corporation
X-MSMail-Priority: Normal
Newsgroups: comp.std.c++
Originator: clamage@taumet


Andy Larson <AndyLarson@prodigy.net> wrote in message
news:37D5AF88.8681E2AE@prodigy.net...
>
> Siemel B. Naran wrote:
> [...]
> > The default behaviour of std::terminate() is to call std::abort().
> > You can change the default behaviour at your option by using the
> > function std::set_terminate(void (*)()).
> >
> > Coding guideline: try to make your exception objects not throw.
> > To avoid risking to throw an out-of-memory or std::bad_alloc,
> > avoid dynamic memory in the exception object.
>
> I agree with your guidelines.  I asked the question in the first place
> as the result a review of the standard exception classes in <stdexcept>,
> such as invalid_argument.  The constructors for these classes don't
> contain an exception specification so it is implementation dependant
> whether or not they actually might throw an exception themselves.  A
> corollary to this guideline would, therefore, seem to be "don't use the
> standard exceptions".  Hmmmm.

Using a standard exception class, such as std::logic_error, as the argument
to throw is no worse than using any other standard library function
normally.  It is just as implementation defined for std::vector as it is for
std::logic_error as to whether it throws some exception you weren't
expecting.

In the case of std::logic_error throwing an error in the constructor, it may
happen that the exception gets raised during the evaluation of the argument
to throw (and so the throw statement never finishes being executed), but
your catching code won't really care if the exception occurred a long time
before some throw statement or just a moment before a throw statement gets
executed.  For example,

void fn()
{
    std::vector<int> v;
    fill_me_in(v);
    std::cout "The first element is " << v.at(1) << endl;
}

When a function calling fn() from a try block catches the exception, it
won't care whether memory ran out (or whatever exception) while creating v,
filling in v, or when at() tries to raise the std::out_of_range (assuming
out_of_range's constructor might throw) if fill_me_in didn't do anything.
With so many places where constructors could throw bad_alloc or other
exceptions, why make the std::exception derivatives a special case?

Since the std::exception derivatives only specify a constructor and leave
the destructor to be compiler generated, and since the base class's
destructor (std::exception) has an empty throw specification, they will not
throw when destroyed.  The same goes for copy construction.  Therefore, they
will never cause terminate() to be called.  I'm assuming here that an
implementation is not allowed to write a copy constructor or destructor
because those functions are not listed in 19.1.x.  Please correct me if I'm
wrong about this.




[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]