Re: This says it all

From: Old Wolf (oldwolf_at_inspire.net.nz)
Date: 03/26/04 

Date: 25 Mar 2004 16:38:28 -0800

"Risto Lankinen" <rlankine@hotmail.com> wrote:
>"Old Wolf" <oldwolf@inspire.net.nz> wrote:
> >
> > You can achieve the same effect by putting your cleanup code at the
> > end of a function. Example:
> >
> > void foo(void)
> > {
> > try {
> > // do stuff
> > }
> > // optional: other catch blocks
> > catch(...) {
> > // maybe do more stuff
> > }
> >
> > // cleanup code here
> > }
>
> Cleanup code will never be reached if 'try' or 'catch' block
> executes a 'return' statement. With 'finally' (if implemented
> the same way as in Java) it would.

Obviously with this scheme you would not return anywhere except
at the end of the function. That is not a good enough reason
for adding 'finally' to the language.

> Of course you should use RAII idiom
[snip - explanation of what RAII is]
> There are two caveats I see with this approach: First, I think of
> it as inelegant, that C++ infrastructure (and not the object model
> of the problem you're solving) is the basis for the requirement
> of a new class,

Classes are no more 'inelegant infrastructure' than functions are.
You could think of a class as a function with some local storage.
Classes are used this way in Standard Library algorithms such as
for_each(). There is no aesthetic mandate to keep the number
of classes to a minimum, IMHO.

> and secondly, using the destructor may prohibit
> you from using some C++ language feature that nevertheless may
> be needed (for instance, you shouldn't throw an exception from
> the destructor of the clean-up object).

Well, what if code in a finally block throws an exception?
You can't return immediately because then resources that have
not yet been released will still not be released. It would seem
that the only option is to wrap each statement in the finally block
in its own try { } catch(...){} . Ugh!

Incidentally, Borland defines the keyword "__finally" as an extension,
which behaves as expected except that it cannot be used on a try{}
block that has a catch() {} block. (don't ask me why..)

Relevant Pages

  • Re: Exception handling?
    ... // in the read loop of MyDoc class serialize ... // The above takes me to the exact same cleanup code that I get when ... // I read in a corrupt file (with NO exception code at all) and mfc handlers it. ... override ReportSaveLoadException to handle it. ...
    (microsoft.public.vc.mfc)
  • Re: And Finally...
    ... > If Trace.Write happens to throw another exception - then CloseFile wil ... >> Trace.Write ("Data lost"); ... >> // cleanup code ...
    (microsoft.public.dotnet.framework)
  • Re: And Finally...
    ... > If Trace.Write happens to throw another exception - then CloseFile wil ... >> Trace.Write ("Data lost"); ... >> // cleanup code ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: VLA failure
    ... difficult if the function declares one or or more VLAs), ... fail by throwing an exception, which could be caught by the caller. ... Adding an exception mechanism to C is, of course, controversial. ... multiplication in your cleanup code into a function call which could ...
    (comp.std.c)
  • Re: regarding "goto" in C
    ... > void foo ... Which (contrary to Herbert Rosenau's assertion) would make the code ... Which would make maintenance harder and increase the risk of errors, ... since the cleanup code would have to be maintained in both places. ...
    (comp.lang.c)