Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!csus.edu!ucdavis!iris!lim
From: lim@iris.ucdavis.edu (Lloyd Lim)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Check DialogPtr returned by GetNewDialog?
Message-ID: <8690@ucdavis.ucdavis.edu>
Date: 3 Apr 91 09:39:04 GMT
References: <1991Apr1.052536.27902@ux1.cso.uiuc.edu> <4143@uakari.primate.wisc.edu> <1991Apr1.224254.5399@neon.Stanford.EDU> <1991Apr2.142214.980@ux1.cso.uiuc.edu>
Sender: usenet@ucdavis.ucdavis.edu
Reply-To: lim@iris.ucdavis.edu (Lloyd Lim)
Organization: U.C. Davis - Department of Electrical Engineering and Computer Science
Lines: 20

In article <1991Apr2.142214.980@ux1.cso.uiuc.edu> dorner@pequod.cso.uiuc.edu (Steve Dorner) writes:
>I agree with Apple in principle; there's a point at which things are SO BAD
>that I don't care what happens anymore.  I'm not sure I would have pegged
>GetNewDialog as such a place, though.

Well, each person has their own limit I guess.  Not having a dialog is so
bad of an error to me that I wouldn't see any point in continuing.  Any quick
functionality test should pick up an obvious error like this before the
software even gets close to the door.

The only reason I could see this happening in a released app is if someone
fiddling with ResEdit deleted some resources.  That shouldn't be the
programmer's fault.  This reminds of the discussion a while back on how to
prevent LoadSeg from crashing if a code resource is missing.

+++
Lloyd Lim     Internet: lim@iris.eecs.ucdavis.edu
              America Online: LimUnltd
              Compuserve: 72647,660
              US Mail: 215 Lysle Leach Hall, U.C. Davis, Davis, CA 95616