Re: Document file read, but -readFromData:(etc) has error.
Re: Document file read, but -readFromData:(etc) has error.
- Subject: Re: Document file read, but -readFromData:(etc) has error.
- From: John Velman <email@hidden>
- Date: Thu, 13 Aug 2009 20:33:21 -0700
- Mail-followup-to: John Velman <email@hidden>, Cocoa Development <email@hidden>
On Thu, Aug 13, 2009 at 08:50:06PM -0500, Ken Thomases wrote:
> On Aug 13, 2009, at 4:07 PM, John Velman wrote:
>
>> - (BOOL)readFromData:(NSData *)data ofType:(NSString *)typeName
>> error:(NSError **)outError
>> {
>> NSLog(@"readFromData has been called, typeName is: %@\n", typeName);
>>
>> if ( outError != NULL ) {
>> NSLog(@"outError is not null");
>>
>> NSLog(@"Going to call NSError\n");
>> *outError = [NSError errorWithDomain:NSOSStatusErrorDomain
>> code:unimpErr userInfo:NULL];
>> NSLog(@"Read error -- outError is: %@\n\n", *outError);
>> [self setInputData:[[NSString alloc]
>> initWithData:data
>> encoding:NSUTF8StringEncoding]];
>> [self convertData];
>> return NO;
>> }
>
> You appear to have misunderstand the nature of the outError parameter. As
> the "out" prefix suggests, this is an output parameter. The caller
> supplies the address of a place where you _could_ store an NSError object
> pointer _if_ your method encounters an error in reading from the data.
>
> If outError == NULL, that means the caller is not interested in getting the
> details of any error that might occur. If outError != NULL, that does
> _not_ mean that an error has occurred or should be provoked. It only means
> the caller wishes to receive the pointer to an NSError object _if_ an error
> occurs. So, your 'if ( outError != NULL )' conditional makes no sense as
> it stands.
>
> Your code should attempt to perform the conversion of the data and, only if
> that conversion fails, it should check if the caller wanted a detailed
> error object and supply one. So, you should only check if outError is or
> is not NULL after _you_ have determine that _your conversion code_
> encountered an error. You are not being signaled that there's been an
> error by your caller. Your caller doesn't know if there's been an error.
> It's waiting to find out.
>
> Likewise, you should return TRUE or YES or the like if your conversion
> succeeds. You should only return NO or FALSE if your conversion fails.
>
> Regards,
> Ken
Thanks, Ken. This is very helpful. Originally I had left the error test
out, did my conversion as part of the read, and everything was fine except
that the program hung up after the conversion was complete. But I'll leave
the long story out. I got to putting in the log print of the error _after_
I tinkered around for a while and couldn't find why I was unable to do
something with the data in a different method (an IBAction) _after_ the
data was read. Clearly this problem was elsewhere.
Back to the drawing board. After the I.S. response, I went back and read
the document.pdf, and checked some of my other programs, and what I did
originally seems to have been in conformance with doc's and working. I
must have another error, which I completely masked by missunderstanding the
nature of the outError argument.
Thanks again,
John V.
_______________________________________________
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