Newsgroups: comp.lang.pascal
Path: utzoo!utgpu!watserv1!watmath!nmouawad
From: nmouawad@watmath.waterloo.edu (Naji Mouawad)
Subject: Re: Messy Stuff
Message-ID: <1991Apr18.165950.8741@watmath.waterloo.edu>
Organization: University of Waterloo
References: <1991Apr17.235717.7580@cs.mcgill.ca> <1991Apr18.133257.4132@maytag.waterloo.edu>
Date: Thu, 18 Apr 1991 16:59:50 GMT
Lines: 57

In article <1991Apr17.235717.7580@cs.mcgill.ca> storm@cs.mcgill.ca (Marc WANDSCHNEIDER) writes:
>I am currently writing a program, and in a bit of a quandery over what to
>do over error handling.

>However, the only way I've come up with so far to do that is have all 
>procedures in fact be functions which return a so called "ErrorCode".
>The main program then does an IF to see if it's 0 (no error), and otherwise
>won't let it continue.

>Is there a way to do this somewhat more efficiently, or is my MAIN stuck
>with IF THEN ELSE mania....?

You may want to consider the following:

Divide the errors into -fatal, -global, and -local. By that I mean,
that errors that may lock-up the system, or crash it are fatal, other
errors from which it is possible to recover can be global to all your
procedures or local to each of them.

Have one fatal error procedure, one global and a set of local ones.

A fatal error should trigger a clean-up mechanism, followed by a
message to the user and a shut-down (halt).

A global error can occur mostly anywhere and as such should reside
in the global error engine. There, a prompt to the user should be
made followed by whatever action necessary.

A local error exist only for specialized types of actions and as such
should be attached to the routine where it originates from.

Finally, have two global variables, ErrorClass and ErrorType and an
ErrorDispatcher which relies on them. You could call ErrorDispatcher
with no If statement since this procedure will either exit immediatly
if the ErrorClass is say 'NoError' or follow the appropriate path.

By breaking down the errors you can distribute them accordingly to
their nature. It makes the code safer since every routine will
transport its own error recovery mechanism via the local engine and
easier to maintain since you don't need to write a big case
statement dealing with all possible errors.

A word of caution: Error recovery could be very time consuming and
sometimes can turn into a simili-expert system :). Know how much you
want to `recover from' before hand.

Finally, If OOP was invented for one thing, it was invented for
Error Recovery.

Hope this help even though I did not give precise examples.

--Naji.
-- 
     -------------------------------------------------------------------
    | Naji Mouawad  |          nmouawad@watmath.waterloo.edu            |
    |  University   |---------------------------------------------------|
    | Of Waterloo   |   "The Stranger in us is our most familiar Self"  |