• 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: Why Don't Cocoa's (Un)Archiving Methods return Errors?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Why Don't Cocoa's (Un)Archiving Methods return Errors?


  • Subject: Re: Why Don't Cocoa's (Un)Archiving Methods return Errors?
  • From: Jens Alfke <email@hidden>
  • Date: Fri, 29 Jul 2011 13:15:19 -0700

On Jul 29, 2011, at 11:12 AM, Jerry Krinock wrote:

> When invoking -archivedDataWithRootObject: on, say, dictionary, finding an un-encodeable object buried somewhere in the dictionary would seem to be quite common.

This is a case of passing invalid data, so throwing an exception is appropriate. It’s implicit that when you archive an object graph, all the objects in it must be archivable.

>  Similarly, when invoking -unarchiveObjectWithFile:, no programmer can guarantee what may be found on the filesystem.

That on the other hand is a valid issue, since you should Never Trust Input Data.

> Has anyone else ever noticed that these methods are exceptionally lame in their lack of error-handling capability?  Is there something about the (un)archiving process which makes it particularly inefficient to detect and handle errors?

There isn’t any way to pass the errors back from the nested calls, is my guess. Consider if you’re unarchiving and your -initWithCoder: method calls -decodeObjectForKey: but the unarchiving of that object fails for some reason. There’s no way for -decodeObjectForKey: to signal an error because it has no error: parameter. All it could do is return nil, which is indistinguishable from the case where there is no object with that key. Even if you did get an NSError, you don’t have a way to return it from -initWithCoder:.

Basically this would require a whole new API to encoding/decoding, where everything took an NSError** parameter.

Not to start another flamewar, but this is a great example of why Exceptions Are Good, since you don’t have to rip apart your API and add lots of extra parameters just to add error handling.

—Jens

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________

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: 
 >Why Don't Cocoa's (Un)Archiving Methods return Errors? (From: Jerry Krinock <email@hidden>)
 >Re: Why Don't Cocoa's (Un)Archiving Methods return Errors? (From: Jerry Krinock <email@hidden>)

  • Prev by Date: Re: MPMoviePlayerController Fast forward
  • Next by Date: Re: A trap with full screen in Lion
  • Previous by thread: Re: Why Don't Cocoa's (Un)Archiving Methods return Errors?
  • Next by thread: Re: Why Don't Cocoa's (Un)Archiving Methods return Errors?
  • Index(es):
    • Date
    • Thread