Re: odd behavior with NSError?
On Oct 15, 2009, at 10:41 pm, Nathan Vander Wilt wrote:
Ouch. So the following pattern is incorrect?
NSError* internalError = nil;
(void)[foo somethingReturningBool:bar error:internalError];
if (internalError) {
// ...
}
http://developer.apple.com/mac/library/DOCUMENTATION/Cocoa/Conceptual/ErrorHandlingCocoa/CreateCustomizeNSError/CreateCustomizeNSError.html#//apple_ref/doc/uid/TP40001806-CH204-BAJIIGCC
Note: Cocoa methods that indirectly return error objects in the Cocoa error
domain are guaranteed to return such objects if the method indicates failure by
directly returning nil or NO. With such methods, you should always check if the
return value is nil or NO before attempting to do anything with the NSError
object.
mmalc
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: odd behavior with NSError?
Bill Bumgarner wrote: On Oct 15, 2009, at 10:41 PM, Nathan Vander Wilt wrote: ... You're saying that some methods go out of their way to trample my (potentially unavailable) error storage even on success? If the error storage is not available, as indicated by passing an NSError** of nil, then the unavailable error storage is never written. Correct? I just want to be sure I understand this completely. -- GG ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: odd behavior with NSError?
(response is pedantic for the purposes of the archive :)
even more better flaming pedanticism!
On Oct 15, 2009, at 10:41 PM, Nathan Vander Wilt wrote:
Ouch. So the following pattern is incorrect?
Yes; it is incorrect.
NSError* internalError = nil;
(void)[foo somethingReturningBool:bar error:internalError];
if (internalError) {
// ...
}
Specifically, assuming anything about the value of 'internalError'
without first determining the return value of -
somethingReturningBool:error: returned a value indicating an error
(typically NO/0/nil/NULL) is an error.
The specific issue is failing to check the return value of the method
before touching the internalError value. You MUST check it.
However, the documentation also encourages not assigning nil to local
NSError* declarations. Not initializing locals is imho,
professionally, realistically, and morally wrong. It's just a bug
waiting to happen. And you have to know it is, just looking at it.
Whatever might have been saved / gained by not initializing them was
wasted, for all of time, the first time I had to debug the segfault.
Which I did, like an idiot, a long time ago.
Let me just say I really especially appreciated the time spent
debugging other people not initializing their locals. It wasn't
visions of sugar plums.
Other people have different perspectives on local variable
initialization. Wrong perspectives, but different. Fortunately now,
they waste their arguments upon the merciless http://llvm.org/img/DragonFull.png
- Ben
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: odd behavior with NSError?
On 16/10/2009, at 4:45 PM, Ben Trumbull wrote: Other people have different perspectives on local variable initialization. Wrong perspectives, but different. Fortunately now, they waste their arguments upon the merciless http://llvm.org/img/DragonFull.png Clangdor the Burninator. Excellent. -- Rob Keniger ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: odd behavior with NSError?
If we get an NSError, or in the case of NSAppleScript an NSDictionary with the error description, what is the Retain count and do we release it when we're done with it? I'd been not releasing them, I didn't allocate or copy it, but when I Build and Analyzed my code in 3.2 on Snow Leopard it said that I had a retain count of +1. Am I leaking? Any advice on this? Cheers Kevin ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: odd behavior with NSError?
On 2009 Oct 16, at 03:44, Kevin Bracey wrote: If we get an NSError, or in the case of NSAppleScript an NSDictionary with the error description, what is the Retain count The retain count of an object is equal to 1 for alloc + the number of - retain messages - the number of -release messages that the object has been sent. (I realize that's not the answer you wanted ... read on.) and do we release it when we're done with it? No, because you didn't alloc, copy or retain it. I'd been not releasing them, I didn't allocate or copy it, but when I Build and Analyzed my code in 3.2 on Snow Leopard it said that I had a retain count of +1. It had better be, because if it was not = 1 it would be gone. Am I leaking? No. Whoever retained it is responsible for releasing it. In this trivial case, *probably* whoever gave it to you autoreleased it. But use such conjectures for debugging only, never for design. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: odd behavior with NSError?
Kevin Bracey wrote: If we get an NSError, or in the case of NSAppleScript an NSDictionary with the error description, what is the Retain count and do we release it when we're done with it? Wrong question. The retain count is not an ownership count. The right question is Do I own it? If you own it, you're responsible for releasing it. If you don't own it, you must not release it. I'd been not releasing them, I didn't allocate or copy it, but when I Build and Analyzed my code in 3.2 on Snow Leopard it said that I had a retain count of +1. Am I leaking? Any advice on this? Find the word NSError on this page: http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/ MemoryMgmt/Articles/mmObjectOwnership.html It's under the heading Objects Returned by Reference. -- GG ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: odd behavior with NSError?
On Oct 2, 2009, at 7:45 AM, Bill Bumgarner wrote:
In either case, assuming the undefined reference is nil would be a
bug. Initializing the variables to nil prior to the call isn't going
to change anything in that regard.
(And, yes, there are methods that modify their error parameter on
success -- purely an implementation detail. Perfect valid thing to
do since the return value is undefined on success.)
Ouch. So the following pattern is incorrect?
NSError* internalError = nil;
(void)[foo somethingReturningBool:bar error:internalError];
if (internalError) {
// ...
}
I got into this habit because most every method is documented to say
things like parameter used if an error occurs and May be NULL.
You're saying that some methods go out of their way to trample my
(potentially unavailable) error storage even on success? I'm starting
to worry that I'll spend tomorrow fixing much old code instead of
getting to make new mistakes...
thanks,
-natevw
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: odd behavior with NSError?
(response is pedantic for the purposes of the archive :)
On Oct 15, 2009, at 10:41 PM, Nathan Vander Wilt wrote:
Ouch. So the following pattern is incorrect?
Yes; it is incorrect.
NSError* internalError = nil;
(void)[foo somethingReturningBool:bar error:internalError];
if (internalError) {
// ...
}
Specifically, assuming anything about the value of 'internalError'
without first determining the return value of -
somethingReturningBool:error: returned a value indicating an error
(typically NO/0/nil/NULL) is an error.
I got into this habit because most every method is documented to say
things like parameter used if an error occurs and May be NULL.
You're saying that some methods go out of their way to trample my
(potentially unavailable) error storage even on success? I'm
starting to worry that I'll spend tomorrow fixing much old code
instead of getting to make new mistakes...
They don't go out of the way to trample it, but may trample it as a
part of whatever internal implementation they use.
I have, however, debugged several bugs that have boiled down to code
assuming the NSError**'s value is definitively indicative of an error.
In one case, a method that takes an (NSError **) argument may call
other methods that take the same, it might -- as an implementation
detail -- pass the argument through, maybe even one of those returns
hey, man, an error occurred, and the caller might recover from it
and eventually return success, but not actually clear the error value
in the process (because there is no need to do so, by definition of
the API).
A similar problem occurred when the NSError** was set up to describe
some problem, later corrected, and then the error was released.
Success was returned, but the caller assumed the error was valid...
*boom*.
b.bum
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: odd behavior with NSError?
On Thu, Oct 15, 2009 at 10:41 PM, Nathan Vander Wilt
nate-li...@calftrail.com wrote:
Ouch. So the following pattern is incorrect?
NSError* internalError = nil;
(void)[foo somethingReturningBool:bar error:internalError];
if (internalError) {
Indeed, this is very incorrect. If the existence of the NSError
object were intended to be the indication of an error, the methods
would just return NSErrors rather than BOOLs.
I got into this habit because most every method is documented to say things
like parameter used if an error occurs and May be NULL. You're saying
that some methods go out of their way to trample my (potentially
unavailable) error storage even on success? I'm starting to worry that I'll
spend tomorrow fixing much old code instead of getting to make new
mistakes...
In fact they do. AppKit *loves* to do this. We've filed Radars on
the cases where it does.
But your use of the error object as indication of failure is misguided
and is your bug, not Apple's.
--Kyle Sluder
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: odd behavior with NSError?
Stephen J. Butler wrote: On Thu, Oct 1, 2009 at 10:31 PM, Colin Howarth co...@howarth.de wrote: NSStringEncoding *enc; NSError *error; NSString *file = [NSString stringWithContentsOfFile:@/Users/colin/developer/Trace/glass.csv usedEncoding:enc error:error]; The way you pass enc is also wrong. If the method had actually succeeded, your program would have crashed. NSStringEncoding enc; NSError *error; NSString *file = [NSString stringWithContentsOfFile:@/Users/colin/developer/Trace/glass.csv usedEncoding:enc error:error]; While we're at it, the values of enc and error are (effectively) nondeterministic before the message send. The documentation for the method you're invoking doesn't specify what it'll put into the encoding argument on failure or into the error argument on success, which means you really shouldn't be blindly using either of them after the call. It would be a good idea to get into the habit of initializing your local variables at the point of declaration. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: odd behavior with NSError?
On Oct 2, 2009, at 4:05 AM, Gregory Weston wrote: While we're at it, the values of enc and error are (effectively) nondeterministic before the message send. The documentation for the method you're invoking doesn't specify what it'll put into the encoding argument on failure or into the error argument on success, which means you really shouldn't be blindly using either of them after the call. It would be a good idea to get into the habit of initializing your local variables at the point of declaration. That is partially correct; you should never assume anything about the values of enc and error after the call. Period. No amount of initialization is going to change this. Consider this code: NSStringEncoding enc = nil; NSError *error = nil; NSString *file = [NSString stringWithContentsOfFile:@/Users/colin/developer/Trace/glass.csv usedEncoding:enc error:error]; If the method fails -- if file is nil -- the 'error' will be filled in with an [autoreleased] NSError instance describing the error. However, 'enc' will be undefined. If the method succeeds, file and enc will be non-nil references to the result, but 'error' will be undefined. In either case, assuming the undefined reference is nil would be a bug. Initializing the variables to nil prior to the call isn't going to change anything in that regard. (And, yes, there are methods that modify their error parameter on success -- purely an implementation detail. Perfect valid thing to do since the return value is undefined on success.) b.bum ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: odd behavior with NSError?
On Fri, 02 Oct 2009 07:05:37 -0400, Gregory Weston gwes...@mac.com said: Stephen J. Butler wrote: On Thu, Oct 1, 2009 at 10:31 PM, Colin Howarth co...@howarth.de wrote: NSStringEncoding *enc; NSError *error; NSString *file = [NSString stringWithContentsOfFile:@/Users/colin/developer/Trace/glass.csv usedEncoding:enc error:error]; While we're at it, the values of enc and error are (effectively) nondeterministic before the message send. The documentation for the method you're invoking doesn't specify what it'll put into the encoding argument on failure or into the error argument on success, which means you really shouldn't be blindly using either of them after the call. It would be a good idea to get into the habit of initializing your local variables at the point of declaration. And IIRC the Build and Analyze mechanism (clang?) will warn of this. Try it, you'll like it! m. -- matt neuburg, phd = m...@tidbits.com, http://www.tidbits.com/matt/ A fool + a tool + an autorelease pool = cool! AppleScript: the Definitive Guide - Second Edition! http://www.tidbits.com/matt/default.html#applescriptthings ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: odd behavior with NSError?
On Oct 2, 2009, at 4:05 AM, Gregory Weston wrote: It would be a good idea to get into the habit of initializing your local variables at the point of declaration. At the risk of starting a religious debate, I disagree. It makes the code somewhat bigger and slower, and worse, it can mask uninitialized- variable errors that the compiler can otherwise catch for you (if you turn on the right warning flag, which unfortunately only works in optimized builds.) I prefer to declare variables only at the point where they're first used, which means that most variables get initialized anyway with non- redundant values. In the case here, initializing the variable doesn't actually help, as Bill pointed out. —Jens___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: odd behavior with NSError?
On 2 Oct, 2009, at 07:36, Stephen J. Butler wrote: On Thu, Oct 1, 2009 at 10:31 PM, Colin Howarth co...@howarth.de wrote: NSStringEncoding *enc; NSError *error; NSString *file = [NSString stringWithContentsOfFile:@/Users/colin/developer/Trace/glass.csv usedEncoding:enc error:error]; The way you pass enc is also wrong. If the method had actually succeeded, your program would have crashed. NSStringEncoding enc; NSError *error; NSString *file = [NSString stringWithContentsOfFile:@/Users/colin/developer/Trace/glass.csv usedEncoding:enc error:error]; Thanks, I thought it looked odd. But, hmmph! I'm used to everything being an object. If it had simply been + (id)stringWithContentsOfFile:(NSString *)path encoding:(int *)enc error:(NSError **)error I'd have been alright :-) --colin ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: odd behavior with NSError?
Because userInfo is a dictionary and is obviously not what you want. Using `po` winds up calling -description, which for NSError returns a synthesis of its localizedDescription, localizedFailureReason, localizedRecoveryOptions, and localizedRecoverySuggestion. So if you want that info, just log the error object rather than its userInfo. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: odd behavior with NSError?
On Oct 1, 2009, at 20:31, Colin Howarth wrote: Why is my NSLog statement being so unhelpful??? Try logging [error localizedDescription] instead. That's what the debugger's showing you. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: odd behavior with NSError?
On Thu, Oct 1, 2009 at 10:31 PM, Colin Howarth co...@howarth.de wrote: NSStringEncoding *enc; NSError *error; NSString *file = [NSString stringWithContentsOfFile:@/Users/colin/developer/Trace/glass.csv usedEncoding:enc error:error]; The way you pass enc is also wrong. If the method had actually succeeded, your program would have crashed. NSStringEncoding enc; NSError *error; NSString *file = [NSString stringWithContentsOfFile:@/Users/colin/developer/Trace/glass.csv usedEncoding:enc error:error]; ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
