hopps@mmm.com (Kevin J Hopps) writes:
> When we designed our exception class hierarchy, we adopted the policy
> that exception classes cannot themselves cause anything to throw an
> exception.

This is a worthy goal, since your program will terminate if the copy
constructor of a thrown object throws an exception.

Unfortunately, your program will also terminate if a destructor ever throws an
exception during stack unwinding for an unrelated exception.

So making your exception classes throw nothing isn't good enough.  You also
need to make sure that no destructor of ANY object in ANY library your program
uses propagates an exception.  This seems like a hopeless task unless it is
universally established as a style rule.

Randal Kuramoto (randalk@compass-da.com) wrote:
> In article <3s6ltc$gdl@dawn.mmm.com>, hopps@mmm.com (Kevin J Hopps) writes:
> |> When we designed our exception class hierarchy, we adopted the policy
> |> that exception classes cannot themselves cause anything to throw an
> |> exception.  It is likely that the embedded String class could fail
> |> under certain circumstances (e.g. out of memory).
> |>
> |> The base class we designed had four data members:
> |>     const char* m_file;  // presumably the value of __FILE__
> |>     unsigned m_line;  // from __LINE__
> |>     char m_why[256];  // derived classes may set this
> |>     char m_func[128];  // prototype of throwing function
> |>
> |> We used fixed size arrays so that no dynamic memory allocation was
> |> required (this can fail, after all).

> I don't see how the above base class member definitions avoids the
> out-of-memory problem that a dynamically allocated string class might
> have.  When an exception is thrown, doesn't the above class definition
> require the allocation of a large amount of space?

The class itself needs to be allocated somewhere, and this class is
quite possibly more of a problem in that regard.  However, the class
itself will never generate an exception.

This raises a standards question.  Is it possible for the statement
    throw Thing();
to fail because there is no space in which to construct a Thing?  If
so, what happens?

> What do you think of the following solution for working in an out-of-memory
> situation?  Preallocated some buffer memory space at the start of the program
> execution.  Then, if an out-of-memory situation is reached, free the buffer
> memory so that at least that amount of memory is available to at least exit
> gracefully from the exception.

This makes the assumption that the program will exit when out-of-memory
occurs.  It also makes the assumption that when an exception is thrown
its space is allocated from the heap.  I don't know if the standard
requires this.
--
Kevin J. Hopps                  e-mail: kjhopps@mmm.com
3M Company                      phone:  (612) 737-4643
3M Center, Bldg. 235-2D-57      fax:    (612) 737-2700
St. Paul, MN 55144-1000         Opinions are my own.  I don't speak for 3M.