On 15 Jul 2009, at 6:14 PM, tmow...@talktalk.net wrote:
(gdb) po err
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x
0x922e668c in objc_msgSend ()
(Earlier:)
NSError *err;
BOOL result = [moc save: err];
Are you sure
On 17 Jul 2009, at 00:13 AM, Fritz Anderson fri...@manoverboard.org wrote:
On 15 Jul 2009, at 6:14 PM, tmow...@talktalk.net wrote:
(gdb) po err
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x
0x922e668c
NSError *err;
BOOL result = [moc save: err];
Make sure you initialize err:
NSError *err = nil;
Otherwise, you may be dealing with a bogus error object, since method-scope
variables are not automatically initialized to 0. (Instance variables are
initialized, btw.) I don't think that
NSError *err;
BOOL result = [moc save: err];
Make sure you initialize err:
NSError *err = nil;
Otherwise, you may be dealing with a bogus error object, since
method-scope
variables are not automatically initialized to 0. (Instance
variables are
initialized, btw.) I don't think
On Thu, Jul 16, 2009 at 1:26 PM, Bill Bumgarnerb...@mac.com wrote:
You should *never* assume *anything* about the value of err across a call to
-save: or any other similar method *unless* the result indicates an error.
This makes many people's lives difficult. It's kinda bogus that if I
pass
On Jul 16, 2009, at 1:37 PM, Kyle Sluder wrote:
This makes many people's lives difficult. It's kinda bogus that if I
pass in the address of a pointer-to-NULL and receive back a YES that I
have to turn around and re-NULL that pointer before reusing it. Many
AppKit methods have a tendency to
On Jul 16, 2009, at 12:51 PM, tmow...@talktalk.net wrote:
I have removed it completely and just called the longer winded
[[NSApp delegate] managedObjectContext] when I need it. I suppose I
could have set the ivar in the awakeFromNib when all NIB objects are
guaranteed to have been
On Jul 16, 2009, at 1:58 PM, Bill Bumgarner wrote:
Then your macros are buggy.
According to the rules now, quite possibly. But the rules are
kinda busted.
One place that looking at *outError and being able to assume it
would be nil on the *entry* to a NSError-returning method is
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
On Thu, Jul 16, 2009 at 3:54 PM, Quincey
Morrisquinceymor...@earthlink.net wrote:
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.
The point is that convenience is increased if NSError-returning
methods
On Jul 16, 2009, at 15:54, Quincey Morris wrote:
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
It seems to be you have this precisely upside-down. outError is an
output
On Jul 16, 2009, at 3:54 PM, Quincey Morris wrote:
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.
Sure. And clang-sa should check for this and
On Jul 16, 2009, at 4:49 PM, Timothy Wood wrote:
Sure, I should remember to ignore it or initialize it to nil myself
or have a OBBaseError macro, but one day I'll forget. The current
rules make me write more and more fragile code than I'd need to if
we could just all depend on setting
On Jul 16, 2009, at 16:49, Timothy Wood wrote:
So, as an example, I might want do do something like:
- (BOOL)saveSomething:(NSError **)outError;
{
NSData *data = build some data;
if ([data writeToFile:path options:someOptions error:outError])
return YES;
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
On Jul 16, 2009, at 5:44 PM, Quincey Morris wrote:
In the second case, you're not screwed because of these NSError
rules but because you're using an output parameter of the method as
an input parameter to the macro. It's a plain bug, unless you assert
it not to be a bug (which is basically
On Jul 16, 2009, at 18:33, Timothy Wood wrote:
and if there's something to do that doesn't return a NSError:
if (![... do something ...]) {
OBError (nil, ...);
return NO;
}
Um, no. This doesn't fill *outError if you pass nil. Either way,
On Jul 16, 2009, at 4:49 PM, Timothy Wood wrote:
Sure, I should remember to ignore it or initialize it to nil myself
or have a OBBaseError macro, but one day I'll forget. The current
rules make me write more and more fragile code than I'd need to if
we could just all depend on setting NSError
Hello,
On 14 Jul 2009, at 10:01 PM, Fritz Anderson wrote:
On 14 Jul 2009, at 5:14 PM, Tim Mowlem wrote:
BOOL result = [moc save: err];
..
The problem is that every time I call this method the result is NO
implying a failure when saving.
..
The issue for this post is that when I try
On 14 Jul 2009, at 5:14 PM, tmow...@talktalk.net wrote:
BOOL result = [moc save: err];
...
The problem is that every time I call this method the result is NO
implying a failure when saving.
...
The issue for this post is that when I try to examine the NSError
object it is invalid. The
I use Core Data to store the information and it all runs pretty
smoothly, that is until the app has been running for 15-20mins and I
start getting Core Data save errors such as CoreData does not support
persistent cross-store relationships
This happens when you save objects to a store that
21 matches
Mail list logo
