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 loc
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,
yo
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 basicall
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 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;
OBEr
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 NSErr
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 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 pa
On Thu, Jul 16, 2009 at 3:54 PM, Quincey
Morris 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 follow the childhood rule
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 sh
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 whe
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 instanti
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 set
On Thu, Jul 16, 2009 at 1:26 PM, Bill Bumgarner 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 in the addre
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 th
>
>
> 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 thin
On 17 Jul 2009, at 00:13 AM, Fritz Anderson 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 in objc_msgSen
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
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 wh
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 NSE
Hello,
I am writing a CoreData based application. I am creating Managed Objects and
then saving them with by sending the save message to the context thus:
NSError *err;
BOOL result = [moc save: &err];
The problem is that every time I call this method the result is NO implying a
fail
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 h
Hey all,
I'm tearing my hair out trying to debug a strange Core Data error I
keep running into.
My app loads data from the web on a regular basis (every minute or so)
and saves it locally for the user to reference.
I use Core Data to store the information and it all runs pretty
smoothly, th
23 matches
Mail list logo
