Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!apple!REEKES@applelink.apple.com
From: REEKES@applelink.apple.com (Jim Reekes)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Why won't ResError return the right message?
Message-ID: <13382@goofy.Apple.COM>
Date: 7 May 91 19:34:03 GMT
References: <1696@babcock.cerc.wvu.wvnet.edu> <1991May6.143630.30448@kuhub.cc.ukans.edu>
Sender: usenet@Apple.COM
Organization: Apple Computer, Inc.
Lines: 35

In article <1991May6.143630.30448@kuhub.cc.ukans.edu>, 2fmlcalls@kuhub.cc.ukans.edu writes:
> 
> > Even though GetResource couldn'thave found the resource (because
> > it wasn't there), ResError returned a 0, indicating that nothing
> > was wrong.  Needless to say, the first time I referred to the
> > resource, I got a Bus Error exception, because I was following
> > the invalid handle out into La-La Land.
> > 
> > Why didn't ResError tell me there was a problem?
> > 
> > --Kurisuto
> > un020070@vaxa.wvnet.edu
> 
> I've seen it documented that ResError doesn't always return 0.  I think the
> preferred method is to check the resource hanfter you read it in.  Check for
> nil.  
> 
> if (myRes = nil) then ....
> 
>   or
> 
> if (myRes^=nil) then ...
> 
> I've never been clear which is more reliable, the handle or pointer.


The handle is the reliable check.  Testing the pointer only tells you if the handle
has been purged, but if you have a nil handle to start with deferencing it will
be bad.  Consider ResError the reason why you got a nil handle.  So, always test for
nil and then look at ResError.  If you are calling AddResource, UpdateResFile, or other
routines that do not return a handle then ResError will be set.  Another gottcha is to
check ResError after calling HGetState.  Otherwise the result is trash, not handle
state information so don't call HSetState with it later.

Jim Reekes E.O., Macintosh Toolbox Engineering