Error Handling

Richard Utter Richard.Utter at f226.n260.z1.FIDONET.ORG
Sat Sep 29 12:40:55 AEST 1990


 > Method 1: Return Error Code When Error Is Encountered
 > Method 2: Set Error Code and Return Only at End
 > Method 3: Use GOTO to Create Exception Handler

Herewith, one vote for #2.

There's a sound _pragmatic_ reason for avoiding #1. If you've written a 
module with enough complexity to generate many errors and associated 
returns, then you may find yourself in the position of having to set just 
as many debugger breakpoints in the module if it doesn't work right the 
first time.

IMHO, #3 is hateful. It's Fortran-66-think. GOTOs are no more than taking 
advantage of an escape clause. "Oops, we broke. Let's get out of here." 
Some will argue the point, but they may not have to maintain or even 
understand code riddled with GOTOs.

...Leaving us with #2. Its most significant disadvantage is that it costs 
you an indent level. Almost all of your productive code will live in 
conditional blocks like--

      if (!error)
      {
            error = do_whatever_is_next ();
      }

Still, the flow of the module remains obvious and, should an error occur, 
the processing time needed to fall through the remaining tests of the 
status variable will normally be negligible.

One final hypercritical thought: at the point where a module tests for more 
than one error, it may be time to consider whether it deserves to be 
transformed into more than one module. If a module does but one thing, 
which can result in but one error, suddenly life becomes simpler.


--  
*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*
Richard Utter - via FidoNet node 1:260/230
UUCP: ...!rochester!ur-valhalla!rochgte!226!Richard.Utter
INTERNET: Richard.Utter at f226.n260.z1.FIDONET.ORG
*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*%*



More information about the Comp.lang.c mailing list