• 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
Is ignoring nil a good thing? (was Re: [OT] "Fluent Interface"? Welcome to NeXT)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Is ignoring nil a good thing? (was Re: [OT] "Fluent Interface"? Welcome to NeXT)


  • Subject: Is ignoring nil a good thing? (was Re: [OT] "Fluent Interface"? Welcome to NeXT)
  • From: Alastair Houghton <email@hidden>
  • Date: Sat, 4 Aug 2007 12:59:53 +0100

On 4 Aug 2007, at 06:20, Uli Kusterer wrote:

On 04.08.2007, at 00:39, Oleg Kibirev wrote:
No problem, just use [NSNull null], (id)1 or the like in your code. Current design is useful for code with a lot of optional object relationships that would otherwise be littered with if statements.

Tell that to all the system APIs that return NIL on failure. I can't change those. I've seen enough applications just quietly go lobotomic just because something didn't load in the middle of a call chain and the user was never notified of the error.

IMO, the current behaviour is definitely a good thing; the benefits of clearer code and non-fatal handling of unexpected error cases (which is a good thing for a GUI app, since it means the end user has a better chance of saving their data if something does go wrong) *far* outweigh the advantages of early detection of errors. If you want to do something different, you can always subclass the system classes you're using and make them return [NSNull null] instead. Or you can litter your code with NSAssert() statements as required.


If it were an error to send messages to nil, you wouldn't have an option at all, and there would be a lot of extra conditionals, which makes the code a lot harder to test.

Similarly, it's kinda pointless how many classes just log to the console when something goes wrong, where no user is ever likely to see it (not to mention no developer, as is evident from the way iChat keeps littering my system logs with its inability to convert its own dates...).

Yes, it's a shame that we developers don't pay more attention to the console messages, particularly as they appear in Xcode's "Run Log" if you're running your program from there, so it isn't even as if they aren't visible during development.


BTW, ***PLEASE*** let's move this to objc-language where it belongs. We've been asked *twice* now by the moderators to do just that. If you're replying to this message, or any other in this thread, ***PLEASE*** delete cocoa-dev from the list of recipients before doing so. (I've tried setting the Reply-To header, but I doubt the list software will pass that through unmangled.)

Kind regards,

Alastair.

--
http://alastairs-place.net


_______________________________________________

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: 
 >RE: [OT] "Fluent Interface"? Welcome to NeXT (From: Jeff Laing <email@hidden>)
 >Re: [OT] "Fluent Interface"? Welcome to NeXT (From: Uli Kusterer <email@hidden>)
 >Re: [OT] "Fluent Interface"? Welcome to NeXT (From: Oleg Kibirev <email@hidden>)
 >Re: [OT] "Fluent Interface"? Welcome to NeXT (From: Uli Kusterer <email@hidden>)

  • Prev by Date: Re: How to apply arguments to .app application while starting it on Terminal?
  • Next by Date: webloc files
  • Previous by thread: Re: [OT] "Fluent Interface"? Welcome to NeXT
  • Next by thread: RE: [OT] "Fluent Interface"? Welcome to NeXT
  • Index(es):
    • Date
    • Thread