Re: Core Data debugging
Re: Core Data debugging
- Subject: Re: Core Data debugging
- From: Quincey Morris <email@hidden>
- Date: Thu, 16 Jul 2009 15:54:11 -0700
On Jul 16, 2009, at 15:19, Timothy Wood wrote:
then at "xxx" you'd like to build a new NSError that has *outError
(if outError != NULL) as the underlying error. This is perfectly OK
since we are on the failure side. Unless the developer of -bar:
forgot to actually set *outError (clang should check this, see the
Radar below) — so this is yet another case where a convention of
setting it to nil and leaving it alone would be helpful. I'd rather
get some less informative error stack than a crash.
Aside: If the developer of bar "forgot" to set *outError, then the
developer of bar forgot to set an output parameter, and that's not
just a bug on the developer's part, but a *horrible* bug. Setting the
error to nil wouldn't help if the bar then set it to something
invalid. If bar has a horrible bug like that, you can't assume that
you'll catch it with any strategy that involves setting *outError in
advance.
But, what would be really convenient, and thus reduce programmer
error, would be to be able to use the same macro at "yyy" were we
are creating a base NSError w/o any underlying error. As the
calling convention stands now, we can't since we can't depend on the
caller to have initialized *outError. So, instead we have to
remember to use two different patterns of code depending on whether
we are creating a stacked error or a base error. This is especially
fragile under code motion when refactoring (can lose the hook to an
underlying error or start mistakenly looking at pointer contents we
shouldn't).
It seems to be you have this precisely upside-down. outError is an
output parameter, not an an input-output parameter. There *is* no
input value of *outError that can become the underlying error.
I'm assuming that you're following the frameworks usage pattern of
outError. If you're not -- if you're implementing methods that use
outError as an input-output parameter -- then *of course* your scheme
is going to clash with Apple's. In that case, it's not so much a
matter of inconvenience, it's a matter of incompatibility.
If I've misunderstood your point, it would be helpful to see an
example of how your code might look with the NSError-wrapping code in
place.
_______________________________________________
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