On Mar 15, 2010, at 7:49 PM, Dave Fernandes wrote: > > On 2010-03-15, at 3:30 PM, Ben Trumbull wrote: > >> Running an integrity check can be useful if you have previously gotten a >> corrupt db error back from fetching or saving, or your app previously >> crashed, or you have some other active indicator it might be worthwhile. >> However, it's quiet expensive in I/O and you should not do it on every app >> launch / document open. Customers with account home directories on AFP, NFS >> or SMB servers will be very unhappy, and if your files become large enough >> so will people using local drives. > > That's a shame. It would certainly be easier to check when opening the file > than to scatter code all over the app to diagnose the problem. Is there a > standard exception I can expect to get when fetching or saving? > NSInternalInconsistencyException is the one I currently get.
You should generally get an NSError with the code that is NSFileReadCorruptFileError. In gdb, what does: >future-break objc_exception_throw >future-break +[NSError errorWithDomain:code:userInfo:] ... >info threads >thread apply all bt say ? The only place you should get an exception is if you try to fault in an object that is unreachable. Either because the database was deleted or corrupted, or because another thread / context deleted that object you wanted before you and you only held the reference instead of getting all the data at once (e.g. race on delete) - 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
