• 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: Empty NSStrings, nil NSStrings
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Empty NSStrings, nil NSStrings


  • Subject: Re: Empty NSStrings, nil NSStrings
  • From: Ondra Cada <email@hidden>
  • Date: Sun, 16 Apr 2006 19:53:57 +0200

Paolo,

On 16.4.2006, at 19:41, Rosyna wrote:

Sometimes the fact they aren't interchangeable causes bugs. For example, two separate bugs in Font Book are caused because it always assumes a string will be either NULL or have a length>0. But in these two completely separate cases, it gets an empty string, tries to call -characterAtIndex:0, and throws an exception.

I guess my point is that never assume just because a string is not NULL that it will not be empty. However, a simple call to [string length] or [array count] will return 0 in both cases due to how Objective-C handles NULL receivers.

I guess this can be translated into "Never ever do something like this"

if (str) NSLog(@"First char: %C",[str characterAtIndex:0]); // WRONG!

"Always do it (somewhat like, there are many valid variations) this"

if ([str length]>0) NSLog(@"First char: %C",[str characterAtIndex: 0]); // all right

Also, it perhaps should be pointed out that

Ack, at 4/16/06, Ali Ozer said:

if the return value ... is NSString, it should return ... an actual string, with the empty string always being represented by the empty string, not nil. Same with NSArray; return an empty NSArray rather than nil.

far as I can say, Cocoa moves towards consistent returning nil in case of an error, but is not there yet (by far).


You can, though, assume that whatever which returns an object and which has an argument NSError **error would *always* return a valid object (perhaps empty, but valid) if no error occurred, and nil if an error occurred (in which case the error would be returned in error).

Presumably, eventually should just *any* method which can return an object and can fail work this very same way, but it is not so in Tiger, and I bet a fortune it won't in Leopard, either :)

Sorry if this all is too self-evident, but I felt (perhaps mistakenly?) it was worth mentioning explicitly.
---
Ondra Čada
OCSoftware: email@hidden http://www.ocs.cz
private email@hidden http://www.ocs.cz/oc



_______________________________________________ Do not post admin requests to the list. They will be ignored. Cocoa-dev mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
  • Follow-Ups:
    • Re: Empty NSStrings, nil NSStrings
      • From: Rosyna <email@hidden>
References: 
 >Empty NSStrings, nil NSStrings (From: Paolo Bertani <email@hidden>)
 >Re: Empty NSStrings, nil NSStrings (From: Ali Ozer <email@hidden>)
 >Re: Empty NSStrings, nil NSStrings (From: Rosyna <email@hidden>)

  • Prev by Date: Highlighting a valid drop target (serious dead end)
  • Next by Date: Re: Empty NSStrings, nil NSStrings
  • Previous by thread: Re: Empty NSStrings, nil NSStrings
  • Next by thread: Re: Empty NSStrings, nil NSStrings
  • Index(es):
    • Date
    • Thread