Re: Rationale behind unwind-protect and double errors

On Sun, 18 Jan 2009 14:40:36 +0000, Mark Wooding
<mdw@xxxxxxxxxxxxxxxx> wrote:

Barry Kelly <barry.j.kelly@xxxxxxxxx> writes:

Be careful what you bundle together there! C++ doesn't have a
try/finally exception handling system.

True. C++ programmers usually use destructors for the same purpose. I
don't think that matters much for the purposes of this discussion,
though the correction is appreciated.

Yes, some programmers try to use destructors, but destructor semantics
are different from try-finally (which C++ does not have). The
preferred idiom for emulating try-finally is to use a conditional
block after try-catch.

It's actually pretty easy to implement a decent try-finally in C++
using preprocessor macros. It isn't perfect because there are too
many ways to implement an exception (dynamically, on the stack, object
or primitive type, etc.) and the exception may need to be preserved
outside the catch block to be thrown again. But it's not hard if you
can pick an implementation and standardize your code base.


Moreover, C++ on Windows usually supports structured exception
handling (SEH), which does not use the mechanism you outline.

The mechanism I described matches the specification in the C++ standard
pretty well. If an implementation doesn't work that way, then it's
broken. Implementation extensions are another matter, but `Windows C++'
isn't the same as `C++'.

Windows SEH is completely independent of C++. It is part of the
Windows API and can be used from any language that can make system
calls.


I note that the C# language doesn't expose this richer exception-
handling semantics to programmers, despite the language's general
objective to provide an interface to the whole of the .NET platform.

..NET (like JVM) is severely lacking in control knobs. A number of
important things like threading, mutual exclusion, load file control,
etc. have only half-assed, lowest denominator implementations and make
your life miserable if you require behavior different from what is
provided.

That said, SEH is accessible from all .NET languages - but it doesn't
play particularly nicely with any of them.

George
.

Relevant Pages

  • Re: Rationale behind unwind-protect and double errors
    ... try/finally exception handling system. ... C++ programmers usually use destructors for the same purpose. ... handling, which does not use the mechanism you outline. ...
    (comp.lang.lisp)
  • Re: Tasty exceptions
    ... to report non-critical errors. ... That's a major part of what we have been trying to get you to understand - you should not be handling exceptions everywhere! ... intellectual your error handling strategy seems to make perfect since for certain programmers. ... and, in that case, exception handling just don't work well from that perspective. ...
    (borland.public.delphi.non-technical)
  • Re: Passing parameters to HandleException
    ... I guess I will probably implement my own Exception class that will be ... > programmer helping programmers. ... >> Handling, and I am trying to pass parameters to HandleException Method, ...
    (microsoft.public.dotnet.framework)
  • Re: Question concerning object-oriented programming
    ... there has usually been a toString. ... I would prefer an exception thrown. ... Actual programmers are supposed to write code that verifies input. ... Educated middle-class people learn how to use language to ...
    (comp.programming)
  • Re: Practical error/exception handling...
    ... Could I humbly suggest that the requirement for a 'standard' way of handling ... But I only need the exception handler in ... > and is informative to both user and developer when errors occur. ...
    (alt.comp.lang.borland-delphi)