• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag
 

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Unable to disassemble objc_assign_strongCast
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unable to disassemble objc_assign_strongCast


  • Subject: Re: Unable to disassemble objc_assign_strongCast
  • From: Quincey Morris <email@hidden>
  • Date: Tue, 3 Nov 2009 01:03:26 -0800

On Nov 2, 2009, at 22:18, Kyle Sluder wrote:

On Mon, Nov 2, 2009 at 10:06 PM, Roland King <email@hidden> wrote:
Haven't there been several threads recently telling people *never* to use
the if( saveError ) check because saveError may be set even if the method
succeeds.

You can use it to determine if there is an error object available. If the method returns NO, it better return a valid NSError or set the pointer to nil.

Just to clarify, since the earlier responses seem open to misinterpretation if not taken in context ...


There are two things NOT to do when using the standard error parameter pattern:

1. DO NOT initialize the NSError* variable to nil.

Doing so isn't literally harmful to the code, just a waste. The harm comes from thinking it does you any good.

1a. If the method call succeeds, the variable might nevertheless have been changed during the call. Its current value is trash.

1b. If the method call fails (returns nil or NO), the variable will of course have been changed to point to a valid object.

Either way, you never needed to initialize the variable.

2. DO NOT use the value of the NSError* variable unless the method call fails. See 1a, especially the part about "Its current value is trash."

I'm not aware of any frameworks methods that fail and pass back a nil value in the NSError* variable, although there may be such. I admit I've written some methods of my own that might pass back either a nil or non-nil NSError* value on failure, but I REALLY don't recommend it. The resulting code in the caller is lousy and incomprehensible.

So this is the correct pattern:

NSError* error; // don't initialize to nil
if (![someObject someMethodThatMightFail: ... error: &error]) {
// Do something with the error object
// No need to test for nil, unless you have reason to really believe that
// 'someMethodThatMightFail' might actually pass back a nil value on failure -- and you care if so
}


At least, that's my understanding of what b.bum and others have been trying to beat into our heads for the last several times we've had this discussion.


_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


References: 
 >Unable to disassemble objc_assign_strongCast (From: Leonardo Borsten <email@hidden>)
 >Re: Unable to disassemble objc_assign_strongCast (From: "Stephen J. Butler" <email@hidden>)
 >Re: Unable to disassemble objc_assign_strongCast (From: Bryan Henry <email@hidden>)
 >Re: Unable to disassemble objc_assign_strongCast (From: Roland King <email@hidden>)
 >Re: Unable to disassemble objc_assign_strongCast (From: Kyle Sluder <email@hidden>)

  • Prev by Date: Re: Apple Remote Control Wrapper sends same button ID for all buttons.
  • Next by Date: Linking Back to My CSS File.
  • Previous by thread: Re: Unable to disassemble objc_assign_strongCast
  • Next by thread: override behaviour of handling NSLinkAttributeName
  • Index(es):
    • Date
    • Thread