From -6071656930779573074 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fc772,6a5bd5596621f011,start X-Google-Attributes: gidfc772,public X-Google-Thread: f78e5,6a5bd5596621f011,start X-Google-Attributes: gidf78e5,public X-Google-Thread: 109fba,6a5bd5596621f011,start X-Google-Attributes: gid109fba,public X-Google-ArrivalTime: 2003-02-14 02:22:29 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!cyclone.bc.net!logbridge.uoregon.edu!xmission!news-out.spamkiller.net!propagator2-maxim!news-in.spamkiller.net!snewsf0.syd.ops.aspac.uu.net!news1.optus.net.au!optus!news.mel.connect.com.au!news.unimelb.edu.au!bounce-back From: "Stephen Howe" Newsgroups: comp.std.c++,comp.lang.c++,comp.lang.c++.moderated Subject: Re: Exceptions inside a destructor Date: 14 Feb 03 10:21:59 GMT Organization: Taylor Nelson Sofres Lines: 41 Approved: Fergus Henderson Message-ID: <3e4bb197$0$14172$ed9e5944@reading.news.pipex.net> References: Reply-To: "Stephen Howe" NNTP-Posting-Host: taifun.cs.mu.oz.au X-Trace: ariel.ucs.unimelb.edu.au 1045218146 680 128.250.34.72 (14 Feb 2003 10:22:26 GMT) X-Complaints-To: news@news.unimelb.edu.au NNTP-Posting-Date: 14 Feb 2003 10:22:26 GMT X-Original-Date: 13 Feb 2003 21:26:09 -0500 Delivered-To: std-c++@ncar.ucar.edu X-Submission-Address: c++-submit@netlab.cs.rpi.edu X-Auth: PGPMoose V1.1 PGP comp.lang.c++.moderated iQBVAwUAPkxTu0HMCo9UcraBAQHDNQIApocB2FOPVnXNYsNahpVuO7+00y8rBiq7 n34Hn31hE+f3znOEltQ1LJNFOzK+5h5Klgu+h7wrJxnBaTGOKuqcBQ== =0UCP X-Approved-For-Group: kuehl@inf.uni-konstanz.de comp.lang.c++.moderated X-RPI-Spam-Score: -0.7 () NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03 X-Scanned-By: MIMEDefang 2.28 X-Spam-Status: No, hits=-8.5 required=5.0 tests=INVALID_MSGID,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_02_03 version=2.41 X-Auth: PGPMoose V1.1 PGP comp.std.c++ Xref: archiver1.google.com comp.std.c++:17957 comp.lang.c++:203131 comp.lang.c++.moderated:60962 > Am I wrong or is there a fundmanental flaw in the language when it comes to > handling exceptions inside a destructor. The experts provide sufficient > reason why you never should but how do you then inform the outside world > that a destructor failed? A destructor should not fail. If you thow an exception in a destructor, in the process of the stack unwinding to look for an appropriate catch handler, what should destructors of local objects do if they fail? You are already in a pending exception, and throwing a 2nd, 3rd exception does not help. The only clean solution to this is _NEVER_ throw from a destructor. > I can't see any *clean* way of doing it. There is one way. An example: I have a class that manages a file resource. It is perfectly possible that fileclose() for the file might fail. So I provide a member function called Close() which in turn calls fileclose() (and other resources) and leaves the object knowing that it is in a "shutdown" state. If Close() succeeds then the destructor won't have to do much. If Close() fails, then you can report this or throw an exception. But what happens if Close() is not called and the destructor kicks in, calls fileclose() and it fails? In that case there is nothing you can do. But if you had called Close() beforehand, you can do something. Stephen Howe [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ] [ about comp.lang.c++.moderated. First time posters: do 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. --- ]