🚀 go-pugleaf

In article <25d7743b.425f@polyslo.CalPoly.EDU> 
dorourke@polyslo.CalPoly.EDU (David M. O'Rourke) writes:
>   procedure GetChooserName(var theString :        Str255);
>   const
>     ChooserNameID   =       -16096;
>   var
>     TempString      :       StringHandle;
>   begin
>     TempString := GetString(ChooserNameID);
>     theString := TempString^^;
>   end;    {GetChooserName}

Ummm, not to get overly picky here or anything, but this is a chance to 
point out an error and at the same time discuss error handling...

Always check calls that attempt to load resources for the possibility of 
NIL before dereferencing them.  What should one do in this case?  I 
probably wouldn't bother to propagate the error up any higher, but I 
certainly would return a NIL string in that case.  A simple

IF TempString = NIL THEN
  theString := ''
ELSE
  theString = TempString^^;

would do great here.  

But what is the "right" thing to do?  Since the string probably isn't used 
for anything serious, and you have to deal with the nil case anyway (in 
the case that the user hasn't changed the chooser name), you already 
should have code higher up to deal with the NIL string.  Unless, of 
course, you put up an alert that says "Please set your chooser name" 
because in that case it is in fact your fault and not the users so this 
error message would be misleading.  Error handling can be, as we see in 
this example, very different depending on the expectations of the routine 
that calls this routine.

The truely paranoid would return an error from the routine (ResError() I 
suppose) in addition to the string.  The paranoid would then claim that 
based on this error code they could report more information to the user.  
I claim that the chances of a call to GetString() revealing an I/O error 
condition on the disk are slim to none, and that the excessive error 
handling can bloat and slow down code for nobody's benefit.  In addition, 
how far up the chain do you propogate this error, and is it EVERY 
routine's responsibilty to know what to do with the error?  Or do you 
report it here (via a DIALOG?), but then what if the caller doesn't want 
an alert?  Do you add another parameter?  This way madness lies...

Remember that you should make sure that the code path of NORMAL execution 
is clean and straight.  Do error handling, ALWAYS, but never muck up code 
to do so.  I always report errors, even in development programs.  I have 
always claimed that for a development program, it is FAR better to drop 
into Macsbug than to churn away and erase my own hard disk.  You may agree 
with this view...:-)

For excellent error handling, see the MacApp Failure mechanism, which may 
also be available from DTS in one of the sample code sets (Mark?).  I've 
used the FailNIL(), FailOSErr() type calls in many non-MacApp programs.  
They work well and really stay out of the way of your code.  In addition, 
code can choose to allow certain errors to happen in the normal course of 
things, catch them, clean up and continue.  Classic examples of this would 
be using the EOF error to terminate reading from a file.  Larry can 
probably give other good examples from the MacApp source.

 Tom Dowdy                 Internet:  dowdy@apple.COM
 Apple Computer MS:81EQ    UUCP:      {sun,voder,amdahl,decwrl}!apple!dowdy
 20525 Mariani Ave         AppleLink: DOWDY1
 Cupertino, CA 95014       
 "The 'Ooh-Ah' Bird is so called because it lays square eggs."