• 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: Core Data debugging
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Core Data debugging


  • Subject: Re: Core Data debugging
  • From: Timothy Wood <email@hidden>
  • Date: Thu, 16 Jul 2009 18:22:31 -0700


On Jul 16, 2009, at 5:39 PM, Greg Parker wrote:
The alternative would be to require the caller to set `err=nil` before calling `whateverWithError:&err`.

Yes, and this would a code savings. Only at the top level invocations would you need to worry about this. There are far more methods that deal with errors that take an outError arg that they can just pass through to my children. So, there really aren't that many places that I end up declaring "NSError *error = nil;"


And of course one day you would forget.

Well, no. Since (a) it's always the same pattern rather than being different per call site and (b) as mentioned in my Radar, clang-sa can check this. As another aside, to some extent I don't care what the rules are as long as clang-sa can help enforce them.


The convention as described makes the method author handle more rough corners in order to simplify the method caller's job, which is the usual trade-off for this sort of thing.

I'm not sure I agree and I think it is a non-issue for the reason I stated above (pass through of outError from a parent method to stuff it calls).


You could write an error macro pair that fails at compile time if you forget the first half.

#define OBBaseError(var)                        \
   const int you_forgot_OBBaseError_##var = 0; \
   if (var) *var=0

#define OBError(var, whatever)                  \
   if (you_forgot_OBBaseError_##var) abort();  \
   /* do your stuff with var */

Ugh. This is even more code. Also, it doesn't fix the problem as I understand it:


	if (![self a:outError]) ...
	if (![self b:outError]) ...

If -a: succeeds it might write some temporary crud into outError that I can't read when -b: fails. Of course, the other part of my Radar is that clang-sa should warn if you write to outError unless you have an unconditional path to return NO/nil/NULL/Nil/FALSE/...

  I forgot to mention that *even* two lines of code is too much, IMO:

	SomeErrorMacro(...);
	return NO;

  Really it would be nicer if this was shortened to:

	return SomeErrorMacro(...);

with enough magic to determine which of the 1001 Versions of Zero to return. Of course, if I could get to two someday, then maybe I'll argue for one =)

-tim

_______________________________________________

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: Core Data debugging (From: email@hidden)
 >Re: Core Data debugging (From: Fritz Anderson <email@hidden>)
 >Re: Core Data debugging (From: BJ Homer <email@hidden>)
 >Re: Core Data debugging (From: Bill Bumgarner <email@hidden>)
 >Re: Core Data debugging (From: Kyle Sluder <email@hidden>)
 >Re: Core Data debugging (From: Bill Bumgarner <email@hidden>)
 >Re: Core Data debugging (From: Timothy Wood <email@hidden>)
 >Re: Core Data debugging (From: Quincey Morris <email@hidden>)
 >Re: Core Data debugging (From: Quincey Morris <email@hidden>)
 >Re: Core Data debugging (From: Timothy Wood <email@hidden>)
 >Re: Core Data debugging (From: Greg Parker <email@hidden>)

  • Prev by Date: Re: Core Data debugging
  • Next by Date: Re: Core Data debugging
  • Previous by thread: Re: Core Data debugging
  • Next by thread: Re: Core Data debugging
  • Index(es):
    • Date
    • Thread