dowdy@apple.com (Tom Dowdy) (02/14/90)
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."
mjohnson@Apple.COM (Mark B. Johnson) (02/14/90)
In article <6664@internal.Apple.COM> dowdy@apple.com (Tom Dowdy) writes: > >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. > See Macintosh Technical Note #88, Signals and Macintosh Sample Code #12 by the same name. Both are available for anonymous FTP from Apple.com (IP address 130.43.2.2). Look in the ~ftp/pub/dts/mac directory. -- Mark B. Johnson AppleLink: mjohnson Developer Technical Support domain: mjohnson@Apple.com Apple Computer, Inc. UUCP: {amdahl,decwrl,sun,unisoft}!apple!mjohnson "You gave your life to become the person you are right now. Was it worth it?" - Richard Bach, _One_