Re: Error handling

From: jacob navia (jacob_at_jacob.remcomp.fr)
Date: 03/18/04 

Date: Thu, 18 Mar 2004 18:41:45 +0100

"andrews" <andrews098@elink.com> a écrit dans le message de
news:iNb6c.28680$Pa7.743622@bgtnsc05-news.ops.worldnet.att.net...
> Could you share some good tips and recommendation about error handling?
> Thanks.
>
Types of errors
------------------

Errors could be classified as
A: Hard errors (traps)
B: Soft errors (wrong results, data loss)

The first type of errors are easier to catch, and
they can be handled with some language constructs
as described below.

The second type of errors are MUCH more difficult
to catch.

Strategies for type A errors
--------------------------------
The standard C construct for exception handling is the
signal() mechanism.

The strategy used by the lcc-win32 system is to offer
additionally the try/except constructs.
You build protected blocks of code with

#include <seh.h>
...
__try {
}
__except (EXCEPTION_EXECUTE_HANDLER) {
}

Any exception inside the try block will end in the __except block.
There you can rethrow the exception or execute other code.
(See the lcc-win32 documentation for details)

Using one of the above constructs, you can implement
the "Design by contract" strategy proposed by B. Meyer in the
Eiffel language.

Each function is seen as a contract between the caller and
the callee. The callee verifies that the caller has done
its part with the PRECONDITIONS macro, that expands
either into nothing or into a __try/__except or
signal/longjmp block as above

At the end of the function, a verification is done that the function
has fullfilled its job with the POSTCONDITION macro.

By default, the strategy is to stop the program when either
of the preconditions or the postconditions are violated.

You can override this of course.

This is quite efficient since it is implemented entirely in
assembly language. The overhead of a __try without any
exceptions is very very small, the order of a few instructions.

In the case of a taken exception the overhead is much
greater, since a trap ends first in the operating system,
that then dispatches to the default exception handler,
that then dispatches to the exception code.

But exception handling is not all there is to error handling however.

Standard C provides assert, as a debugging aid, but it is
only intended for the programmer. In almost all cases,
more sophisticated mechanisms are needed.

It is a good idea to apply consistency when using error return
values. There is very often the confusion between a
function that returns true if all is OK, or false
if there was a problem, and other functions,
that return zero meaning all is OK, or an
error code, if there was a problem.

Mixing both strategies can be fatal when the maintainer is
confronted with
    if (!DoSomething(data))

Which strategy is following "DoSomething" ??

Perfect error handling is impossible by definition since the
set of possible errors for any non-trivial function runs into
huge number of cases very quickly.

And most of those cases will never arise, or well,
almost never. The __try/__except constructs allows for
a big simplification of error handling when ALL
possible hard errors end up
in the same place and mustn't be handled separatedly.

The problem with handling each error case separatedly
is that you get quickly bogged down into a mess of
if/else constructs.

Strategies for type B errors
--------------------------------

Wrong results are specially difficult to catch since
there is no warning, simply a nonsense result. This implies
that the programmer *must* trace back the whole
calculation to find where it is going wrong. This can
be made easier if the programmer uses the
PRECONDITION/POSTCONDITION or Design by
contract strategy, but that is surely not the silver
bullet since in most cases it is impossible to test
for all possible failure modes in the postconditions
section.

Specially difficult are the floating point errors, for instance.
And there is NO strategy here, that will easy the job.
The programmer MUST follow ALL the calculations
leading to the wrong result.

jacob

http://www.cs.virginia.edu/~lcc-win32

Relevant Pages

  • Re: Error handling
    ... The first type of errors are easier to catch, ... Any exception inside the try block will end in the __except block. ... But exception handling is not all there is to error handling however. ... only intended for the programmer. ...
    (comp.lang.c)
  • Re: Error looping through controls on form in Access 2003
    ... >>code apply only to the controltypes that I wanted it to apply to. ... > I see 2 reasons to choose error handling over pre-checking conditions to avoid ... > new cases of the same condition in new versions of the underlying libraries. ... Now those are the exceptional cases that the word exception implies. ...
    (comp.databases.ms-access)
  • Re: Learning to use decorators with classes
    ... and you could use any legal Python identified instead. ... This kind of "error handling" is more than useless - it's worse than no error handling at all. ... If you cannot handle the problem, just let the exception propagate - you'll get a nice traceback with all the necessary debugging informations. ... Users of your package can always add a top-level "catch-all" exception handler that will log tracebacks, send alert mails to the team, and present the end-user with a nicely formatted error message (and even possibly a way to handle the problem - like providing appropriate connection data (credentials, url, whatever)!-) ...
    (comp.lang.python)
  • Re: code structure for try... catch
    ... What my preference to do is to have the error handling code close to ... "When an exception is thrown, code following the statement will not be executed, and PHP will attempt to find the first matching catch block. ... public function throwException() { ...
    (comp.lang.php)
  • Re: Thoughts on current error handling best practice with VBScript
    ... you should be looking to JScript for structured error handling. ... am in any way representative of the casual programmer it is a constant ... It isn't really reasonable to expect a 'casual programmer' to program ... Structured error handling is the recommended method. ...
    (microsoft.public.scripting.vbscript)