How do I know when safe to ignore __cxa_throw on an All Exceptions breakpoint?
I am on Xcode 4.5.1. I think this is relatively new behavior I am seeing.
I prefer to develop and test my projects with the "All Exceptions" breakpoint enabled.
I have been running into a scenario where I am loading thumbnail images to cells in a tableview, where I am getting a __cxa_throw exception. When I click the "Continue program execution" button, Xcode continues its merry way. I get the thumbnails. App seems to work fine. I am looking for some tips on how I can determine if this is something safe to ignore. Like maybe some pointers on understanding the stack trace? Or something else?
Here is the snippet of code:
NSString *imageStr = item.thumbURL;
imageStr = [imageStr stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
NSURL *imageURL;
if (![imageStr isEqualToString:@""]) {
imageURL = [NSURL URLWithString:imageStr];
NSLog(@"imageURL: %@",imageURL);
if (imageURL == nil) {
NSLog(@"imageUrl was nil for string: %@",imageStr);
} else {
UIActivityIndicatorView *spinner = [[UIActivityIndicatorView alloc] initWithActivityIndicatorStyle:UIActivityIndicatorViewStyleWhiteLarge];
//spinner.frame = CGRectMake(cell.imageView.frame.size.width/2,cell.imageView.frame.origin.y + cell.imageView.frame.size.height/2,cell.imageView.frame.size.width,cell.imageView.frame.size.height);
spinner.frame = CGRectMake(10,20,40,40);
[spinner startAnimating];
[cell addSubview:spinner];
dispatch_queue_t downloadQueue = dispatch_queue_create("thumbnail downloader", NULL);
dispatch_async(downloadQueue, ^{
NSLog(@"Network request for tour_thumb image: %@",imageStr);
UIImage *img = [[UIImage alloc] initWithData:[NSData dataWithContentsOfURL:imageURL]];
dispatch_async(dispatch_get_main_queue(), ^{
[spinner removeFromSuperview];
UIImageView *imgView=[[UIImageView alloc] initWithFrame:CGRectMake(8, 8, cell.contentView.frame.size.width/2 - 16, cell.contentView.frame.size.height - 16)];
imgView.image = img;
[cell.contentView addSubview:imgView];
});
});
dispatch_release(downloadQueue);
}
}
Here is what I see on the stack trace:
#0 0x34a9c524 in __cxa_throw ()
#1 0x387014ce in AddChildNode(XMP_Node*, XML_Node const&, char const*, bool) ()
#2 0x38700d22 in RDF_LiteralPropertyElement(XMP_Node*, XML_Node const&, bool) ()
#3 0x3870094e in RDF_PropertyElementList(XMP_Node*, XML_Node const&, bool) ()
#4 0x38700608 in ProcessRDF(XMP_Node*, XML_Node const&, unsigned int) ()
#5 0x3871480a in XMPMeta::ParseFromBuffer(char const*, unsigned int, unsigned int) ()
#6 0x387095c0 in WXMPMeta_ParseFromBuffer_1 ()
#7 0x38725578 in TXMPMeta<std::string>::ParseFromBuffer(char const*, unsigned int, unsigned int) ()
#8 0x387254de in TXMPMeta<std::string>::TXMPMeta(char const*, unsigned int) ()
#9 0x38722b70 in CreateMetadataFromXMPDataInternal(char const*, unsigned long, unsigned int) ()
#10 0x38739a50 in readXMPProperties ()
#11 0x386a01fc in readXMPData ()
#12 0x3868cec8 in initImageJPEG ()
#13 0x3868c2ee in _CGImagePluginInitJPEG ()
#14 0x3867e274 in makeImagePlus ()
#15 0x3867ddde in CGImageSourceCreateImageAtIndex ()
#16 0x38e117b6 in _UIImageRefFromData ()
#17 0x38e116c6 in -[UIImage initWithData:] ()
#18 0x0004cb0a in __57-[ViewController tableView:cellForRowAtIndexPath:]_block_invoke_0 at ViewController.m:335
#19 0x313fc792 in _dispatch_call_block_and_release ()
#20 0x313ffb3a in _dispatch_queue_drain ()
#21 0x313fd67c in _dispatch_queue_invoke ()
#22 0x31400612 in _dispatch_root_queue_drain ()
#23 0x314007d8 in _dispatch_worker_thread2 ()
#24 0x394767f0 in _pthread_wqthread ()
#25 0x39476684 in start_wqthread ()
Solution 1:
This is obviously deep within the implementation and C++ exceptions can be part of the normal flow, if they've decided to use exceptions to signal errors internally.
If you aren't writing any C++ yourself then it is safe to ignore.
Just trap the standard Objective-C exception:
objc_exception_throw
Solution 2:
Go here:
And do this:
To turn this:
into this:
You'll still get a lot of the benefit of adding a breakpoint, but won't have your app crash for stuff you probably aren't responsible for anyway. Now if you are working with C++ then you darn better worry about it.