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: <13404@goofy.Apple.COM>
Date: 8 May 91 17:56:31 GMT
References: <1696@babcock.cerc.wvu.wvnet.edu> <1991May6.143630.30448@kuhub.cc.ukans.edu> <13382@goofy.Apple.COM> <12946@pt.cs.cmu.edu>
Sender: usenet@Apple.COM
Organization: Apple Computer, Inc.
Lines: 34

In article <12946@pt.cs.cmu.edu>, hairston@henry.ece.cmu.edu (David Hairston) writes:

> 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))

A problem with goodHand above is that if the GetResource fails, then you
may end up dereferencing a nil address.  It will happen with Pascal's
AND expression, but not with MPW Pascal's &.  It all depends on the language's
implementation.  It's safe to just check on the handle being returned to be
nil.  Besides, calling GetResource will never return a handle that is purged,
unless you set ResLoad to false and the resource isn't in memory.  BUT...
if you set ResLoad to false (which is a valid thing to do) then goodHand
above will always report an error!

I have to correct myself in my original response.

> 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.

I meant to say always check _MemError_ after calling HGetState.

Jim Reekes E.O., Macintosh Toolbox Engineering