iOS NSXMLParser object and setting delegate to self

[drivefast]

i dont know if i'm a great programmer, but i'm a pretty good imitator. so after trying to get to the root of my problem, my class is now almost exactly as the XMLReader in the SeismicXML sample code:

- (bool)parseMyStuffFrom:(NSData *)xml into:(NSMutableArray *)here {
	NSLog(@"goin' parsing...");
	[self.error setString:@""];
	// initialize and start the xml parser pump
	NSXMLParser *pXML = [[NSXMLParser alloc] initWithData:xml];
	[pXML setDelegate:self];
	NSLog(@"here it comes");
	[pXML parse];
	NSLog(@"wuh.");
	if ([pXML parserError]) {
		// parsing error
		NSLog(@"parsing error");
		[self.error setString:@"malformed XML response"];
	}
	[pXML release];	
	return [self.error length];
}

and the runtime log is:

2008-10-19 18:02:01.404 AppName[10325:20b] goin' parsing...
2008-10-19 18:02:01.463 AppName[10325:20b] here it comes
2008-10-19 18:02:01.464 AppName[10325:20b] *** -[NSCFString bytes]: unrecognized selector sent to instance 0x546640
2008-10-19 18:02:01.465 AppName[10325:20b] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[NSCFString bytes]: unrecognized selector sent to instance 0x546640'

my class inherits directly from NSObject. it implements:
parserDidStartDocument:
parser: didStartElement: ...
parser: didEndElement: ...
parser: foundCharacters:

at one point i checked if the .delegate property of my parser object indeed gets set to self. it does. there's probably a few dozen things that i tried as well, but practically i thinned it down to a very understandable class. there's still gotta be something that i'm missing. any ideas what it could be?... thanks.

 

[ace2600]

Can you try implementing this method and see if it prints anything?

- (void)parser:(NSXMLParser *)parser parseErrorOccurred:(NSError *)parseError {
    NSLog(@"ERROR:%@", [parseError localizedDescription]);
}

Otherwise, I suspect it may have something to do with your other parser delegate methods and handling/parsing/appending/etc. strings.

 

[PhoneyDeveloper]

The runtime exception is telling you that your xml parameter, which is supposed to be an instance of NSData, isn't a valid NSData instance. Instead it's an NSString.

How do you call this method? How do you build the NSData object that's supposed to be parsed?

 

[drivefast]

The runtime exception is telling you that your xml parameter, which is supposed to be an instance of NSData, isn't a valid NSData instance. Instead it's an NSString.

oh boy. you're right on. my xml payload was an NSData originally, since i get it from an NSConnection. while debugging that part of the app, i converted it to an NSString so i can NSLog() it. and then, i just accidentally passed the string instead of the data. this probably also explains why sometimes (but not always?...), one of my function calls that was supposed to pass along the data received a yellow card from the compiler.

 

[PhoneyDeveloper]

A bit of advice: Objective-C is a dynamic language, somewhat different from C++ under the covers. You need to pay attention to compiler warnings. In Objective-C when the compiler says that an object may not respond to some method, pay attention. You can send any message to any object but the object may not respond. If it doesn't respond you get a run-time exception. It's better to fix these things at compile time than at run time.

The run-time system helpfully tells you what message you tried to send to what kind of object, and why it failed. But you need to be able to read the output from the run time exception.

Where it said:

-[NSCFString bytes]: unrecognized selector sent to instance 0x546640

'unrecognized selector' means that the object didn't respond to a message. The address of the instance is printed. 'bytes' is the message and 'NSCFString' is the type of the object that it was sent to. This class is undocumented but you can assume it is a subclass of NSString.

'bytes' is of course an instance method of NSData. One can assume that the xml parser works by using bytes and length of the NSData that you pass to it. And of course you've passed an NSString where you needed to pass an NSData, which resulted in this runtime exception.

 

[drivefast]

i'm totally with you regarding compiler warnings. i learned a long time ago that sooner or later these come back and bite you from behind. most of the times, c++ warnings translate into memory leaks or random pointers, and if you ignore them, you can bet you will get a nasty bug after the release. this being said, yes i did ignore the yellow card temporarily, as i was trying to focus on the main program stream for now.

regarding reading the runtime errors, for now their meaning is limited to me. i'm sure this will get better with the experience. it may even get better with reading a manual...

thanks again.