Title: Exception Errors

Dear John, I just received Overload 28, and am as usual baffled by The Harpist. This time, however, I think it may be his or your fault as well as mine...

On P20 column 1, the Harpist begins a paragraph 'The last of these mechanisms', at which point one's eyes flick up to the paragraph above, to find a list - the last item is calling exit(). I think actually the Harpist means that returning an error code is not possible in destructors - but he definitely got me scratching my head.

In column 2 of P20 he declares a constructor like this

CanFail() : failed(true)
{
  failed = true;
}

Which doesn't strike me as very handy either. I suppose he meant

CanFail() : failed(true)
{
  failed = false;
}

but even this seems a perversely negative and unclear way of writing something like

bool builtFlag;

CanFail() : builtFlag(false)
{
  // body - maybe can exit here...
  builtFlag = true; 
  // successful construction
}

at which point built() becomes a straight accessor function rather than a strange little negator. Or have I missed the point entirely? I am a Delphi-head - there, I've admitted it. When Borland introduced exception handling into its Object Pascal implementation, the result was cleaner, more natural and safer code. Since Stroustrup introduced exceptions into C++, my impression is that resulting C++ code is usually a hideous, hard-to-read mess full of memory leaks. An impression strongly reinforced by the wrapped up function at the bottom of page 21 column 2.

The secret of good exception based code in Delphi is that you very, very rarely need to use the 'except' keyword (approximately analogous to C++'s 'catch') - see the excellent book 'Delphi Component Design' by Danny Thorpe for a wonderful discussion of how Delphi exceptions work.

What the secret of good exception-based code is in C++ I don't know, but I'm sure this ain't it.