Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!spool.mu.edu!news.cs.indiana.edu!maytag!watstat.waterloo.edu!dmurdoch
From: dmurdoch@watstat.waterloo.edu (Duncan Murdoch)
Newsgroups: comp.lang.pascal
Subject: Re: Messy Stuff
Message-ID: <1991Apr18.133257.4132@maytag.waterloo.edu>
Date: 18 Apr 91 13:32:57 GMT
Article-I.D.: maytag.1991Apr18.133257.4132
References: <1991Apr17.235717.7580@cs.mcgill.ca>
Sender: news@maytag.waterloo.edu (News Owner)
Organization: University of Waterloo
Lines: 49

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....?

Error handling always ends up messy.  I've seen several solutions, but
they're all a bit ugly:

 - maintain a global "status" variable.  If an error occurs, set it to
a non-zero value.  If you want to do it really well, hide the variable,
make its value only available by a function call (like IOResult) which
resets it, and make all your procedures fail if it's non-zero.

 - code your procedures as boolean functions or functions returning a 
status, and embed all of them in a single big procedure.  Use "exit"
to bail out if an error occurs:

  if not Proc1 then
    exit;
  if not Proc2 then
    exit;
  if not Proc3 then
    exit;

etc.  The problem with this is that the Procs may set something up that
needs cleaning up later; if that's the case, you need something like:

  if Proc1 then
  begin
    if Proc2 then
    begin
       ...
       CleanUpProc2;
    end;
    CleanUpProc1;
  end;

There are other more complicated schemes to bail out, but I've never needed
them.  

Duncan Murdoch
dmurdoch@watstat.waterloo.edu