ZAssert([moc save:&error], ....

NSError *error = nil; ZAssert(![managedObjectContext save:&error], @"My save failed: %@\n%@", [error localizedDescription], [error userInfo]);

So if save: returns a Yes, you are inverting it before passing it to ZAssert which then promptly re-inverts it.

define ZAssert(condition, ...) do { if (!(condition)) { ALog(VA_ARGS); }} while(0)

So a successful save goes from YES->NO->YES and an ALog is produced. I know first hand as it just happened to me :)

This works as expected // if (![self.managedObjectContext save:&error]) { // NSLog(@"My save failed: %@\n%@", [error localizedDescription], [error userInfo]); // abort(); // } ZAssert([self.managedObjectContext save:&error], @"My save failed: %@\n%@", [error localizedDescription], [error userInfo]);

The macro’s conditional statement would read “if not condition”. The example implementation applies a “not [save success?]“.

As such the condition is built as follows, given a successful save: “if not (not true)”.

ZAssert raises an exception when the save is successful, which is the opposite of the desired outcome.

Easy fix: Remove the “!” from the condition defined in the macro or the “!” from the first argument passed to ZAssert.

Remaining consistent given it’s common to pass “if not” logic to NSAssert, I’ve opted to change the macro’s conditional to “if (condition)”. The implementation remains consistent with your example as well as existing NSAssert calls.

Thoughts?

static inline BOOL IsEmpty(id thing) { return thing == nil || ([thing respondsToSelector:@selector(length)] && [(NSData *)thing length] == 0) || ([thing respondsToSelector:@selector(count)] && [(NSArray *)thing count] == 0); }

This can come in handy is you want to check if a NSString, NSArray, NSSet or NSData variable is empty (variable is nil or does not contain any elements).

As for the do {} while (0) instead of nothing is because there are a few rare code situations where replacing DLog(@”"); with ; can cause issues. Replacing it with do {} while(0); is safer in those rare cases and will get optimized out by the compiler anyway.

http://gist.github.com/387747

define ALog(format, …) NSLog((@”%s [L%d] ” format), PRETTY_FUNCTION, LINE, ##VA_ARGS);

ifdef DEBUG

define DLog(format, …) ALog(format, ##VA_ARGS);

else

define DLog(…)

endif

Is there any reason why you expand DLog() to “do { } while (0)” when DEBUG is undefined, rather than nothing?