rjn@duke.cs.duke.edu (R. James Nusbaum) (08/10/87)
Does anyone have any really good ideas on handling errors in constructors?
If an object is made using a new call:
foo = new class;
then it is fairly easy to signal an error by returning NULL from the
constructor, although you should be careful about cleaning up any memory
that may have been automatically allocated by the constructor. Since
I usually do custom memory allocation for objects, this isn't too much
of a problem. The problem comes when objects are allocated on the stack:
class foo;
Then the memory for the object is on the stack. My constructors are
often fairly complicated (creating sockets, allocating memory). If an
error occurs in the constructor and the object is on the stack I have to
come up with some way of alerting the user that an error has occured
immediately, and not wait for a segmentation fault to occurr later.
Now I do have one solution. All my classes have built in error logging
using a global structure (implemented as an inherited static member)
that acts something like the errno facility in Unix. The user can turn
on debugging so that an error handling function is always called when an
error has occured. The problem is that the user has to somehow turn on
debugging before any objects are created, which can be very kludgy to
do, and that constructor errors should be able to be caught separately
since they are almost always fatal. To deal with this I have my
constructors send a signal (one of the user defined ones) to the process
when there is an error. If the user has made no arrangements to catch
the signal then the program will terminate, or the user can set up a
signal handler and perform whatever actions they desire.
Any other suggestions?
R. James Nusbaum, Duke University Computer Science Department,
Durham NC 27706-2591. Phone (919)684-5110.
CSNET: rjn@duke UUCP: {ihnp4!decvax}!duke!rjn
ARPA: rjn@cs.duke.edushopiro@alice.UUCP (08/17/87)
In article <10024@duke.cs.duke.edu>, rjn@duke.UUCP writes: > > Does anyone have any really good ideas on handling errors in constructors? > If an object is made using a new call: > foo = new class; > then it is fairly easy to signal an error by returning NULL from the > constructor. ... > The problem comes when objects are allocated on the stack: > class foo; > Then the memory for the object is on the stack. ... My rule is that if the constructor returns at all, it must create a legitimate object. If there is a possibility for the constructor to fail, then indication of the failure is stored in the object. I provide such objects with member functions to interrogate their status, and other member functions check the status and try to do something appropriate if they can't do their intended function. I think an error handler which is an inherited static member is fine, but it generally is only useful for logging error messages. If you are building classes to use yourself, then more or less anything goes, but if you are building classes for others to use, then the approach of always creating an object seems cleanest to me. Returning NULL from a constructor is not a good idea at all. Assignments to `this' will soon be deprecated. (Don't worry, a better alternative is coming). -- Jonathan Shopiro AT&T Bell Laboratories, Murray Hill, NJ 07974 research!shopiro (201) 582-4179