Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!wuarchive!udel!rochester!pt.cs.cmu.edu!henry.ece.cmu.edu!hairston
From: hairston@henry.ece.cmu.edu (David Hairston)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Why won't ResError return the right message?
Message-ID: <12946@pt.cs.cmu.edu>
Date: 8 May 91 02:40:56 GMT
References: <1696@babcock.cerc.wvu.wvnet.edu> <1991May6.143630.30448@kuhub.cc.ukans.edu> <13382@goofy.Apple.COM>
Organization: Gaia II
Lines: 42

[un020070@vaxa.wvnet.edu (Kurisuto) 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?

[2fmlcalls@kuhub.cc.ukans.edu writes:]
[] 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.  
[] ...
[] I've never been clear which is more reliable, the handle or pointer.

[REEKES@applelink.apple.com (Jim Reekes) writes:]
[] 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.
[] ...

there's a no-brainer which has worked its way into my code (C example):

#define goodHand(x)    ((x) && *(x))

which gets used for:

realHandle = GetResource(type, index);
if (!goodHand(realHandle))
    ....

as well as for:
fooPointer = NewWindow(...);
if (!goodHand(&fooPointer))
    ....

i guess i shouldn't be lazy but it's a no-brainer ...

  -dave-  
hairston@henry.ece.cmu.edu