Re: Exception not being caught in try statement

[Mark Allan via Cocoa-dev]

Hi all,

Thanks to everyone for their suggestions. I spent far too much time working 
around this bug, but have finally got to the bottom of the original issue.

It turns out this is a known issue with some other apps as well, and (thanks to 
https://trac.cyberduck.io/ticket/11231#comment:25 
 ) can be fixed by removing 
an obscure preference key from the User Defaults system.

I was able to reproduce the issue by setting the 
__NSDisableSharingTextTabInstance key to YES using the "defaults write" command.

I've solved it by removing that key in my -applicationDidFinishLaunching method:
[[NSUserDefaults standardUserDefaults] removeObjectForKey: 
@"__NSDisableSharingTextTabInstance"];

Looks like someone has already submitted a bug report to Apple for it 
(https://openradar.appspot.com/FB8930278 
 ) so I'm just posting this here in 
case it helps anyone else in the future.

Best regards,
Mark 

> On 29 Mar 2021, at 7:01 pm, Martin Wierschin via Cocoa-dev 
>  wrote:
> 
> Breaking the RTFD loading process down into subtasks is a good idea. It might 
> be worth trying to sidestep the issue using NSAttributedString. You can try 
> loading the data yourself as Mike suggested and then use initWithRTFD or 
> initWithRTFDFileWrapper. Once you have the text in an attributed string you 
> can swap its content into your NSTextView/NSTextStorage using 
> -replaceCharactersInRange:withAttributedString:
> 
> However, I suspect the problem will remain. The exception is coming from 
> Apple's internal NSRTFReader class, which we can be reasonably certain is 
> utilized by all RTF/RTFD loading code paths. To really fix this you're 
> probably going to be stuck with ugly code that either:
> 
> 1. Preprocess the RTFD to remove the data that Apple's code can't handle, eg: 
> strip tab stops as someone else suggested.
> 2. Use method swizzling to patch Apple's buggy methods at runtime, eg: 
> replace -[NSRTFReader defaultParagraphStyle] to avert the conditions that 
> lead to the exception, before it gets thrown in the first place.
> 
> One other potential debugging aid: NSExceptionHandler. You can register your 
> own handler, perhaps in a way that prevents AppKit from killing your app 
> outright when an exception occurs (this used to be possible but I don't know 
> the current behavior). But as Mike said, this isn't a real solution for 
> shipping software. Generally speaking once an app has thrown an exception its 
> state can't be relied upon. So you should only use this for testing to gather 
> additional debug information.
> 
> ~Martin Wierschin
> 
>> On Mar 26, 2021, at 11:22 AM, Mike Abdullah via Cocoa-dev 
>>  wrote:
>> 
>> This does seem quite surprising. However, here’s the thing: this code is 
>> very strange approach to take.
>> 
>> Number 1: Cocoa doesn’t support exceptions as an error-handling mechanism 
>> except where explicitly stated and supported. You’re trying to use them, 
>> which is asking for trouble. The system doesn’t guarantee proper handling of 
>> memory if an exception does throw.
>> 
>> Number 2: Your error handling approach is back-to-front. You’re trying an 
>> operation, seeing if it fails, then attempting to guess from the current 
>> state (which might have changed in the meantime) why it might have failed.
>> 
>> Instead, use the proper error APIs and approach:
>> 
>> 1. Load the data from disk, e.g. +[NSData 
>> dataWithContentsOfURL:options:error:]
>> 
>> If that fails you can introspect the error to your heart’s content to find 
>> out what went wrong
>> 
>> 2. Load the data into your text view. I’m not sure if there’s an API to do 
>> that in a single step or not, dunno.
>> 
>> I also note that your code explicitly is trying to read an RTFD which if 
>> memory serves can be a document *bundle* format, so perhaps at step 1 you’d 
>> have to go with a file wrapper. But the path you specify is .rtf so I’m 
>> guessing you really do have a basic file and can load it as data.
>> 
>> Mike.
>> 
>>> On 26 Mar 2021, at 11:11, Mark Allan via Cocoa-dev 
>>>  wrote:
>>> 
>>> Hi folks,
>>> 
>>> Some users are reporting a crash that I can't reproduce, and in an attempt 
>>> to gain additional diagnostics from a user, I wrapped the affected line in 
>>> a try/catch block.  For two users it resolve the crash, but for a third, 
>>> it's still crashing at the same point!
>>> 
>>> The crash occurs when a user attempts to open the "About" window from my 
>>> app's main menu item. I'm not using the standard about panel as there's a 
>>> few additional items I need to display, one of which is an NSTextView which 
>>> I populate with the contents of an RTF file from within the app bundle.
>>> 
>>> I've symbolicated the crash log to find it's happening when populating that 
>>> TextView. The line in question now reads as follows:
>>> 
>>> @try {
>>> [self.aboutBox.creditsTextView 

Re: Exception not being caught in try statement

[Martin Wierschin via Cocoa-dev]

Breaking the RTFD loading process down into subtasks is a good idea. It might 
be worth trying to sidestep the issue using NSAttributedString. You can try 
loading the data yourself as Mike suggested and then use initWithRTFD or 
initWithRTFDFileWrapper. Once you have the text in an attributed string you can 
swap its content into your NSTextView/NSTextStorage using 
-replaceCharactersInRange:withAttributedString:

However, I suspect the problem will remain. The exception is coming from 
Apple's internal NSRTFReader class, which we can be reasonably certain is 
utilized by all RTF/RTFD loading code paths. To really fix this you're probably 
going to be stuck with ugly code that either:

1. Preprocess the RTFD to remove the data that Apple's code can't handle, eg: 
strip tab stops as someone else suggested.
2. Use method swizzling to patch Apple's buggy methods at runtime, eg: replace 
-[NSRTFReader defaultParagraphStyle] to avert the conditions that lead to the 
exception, before it gets thrown in the first place.

One other potential debugging aid: NSExceptionHandler. You can register your 
own handler, perhaps in a way that prevents AppKit from killing your app 
outright when an exception occurs (this used to be possible but I don't know 
the current behavior). But as Mike said, this isn't a real solution for 
shipping software. Generally speaking once an app has thrown an exception its 
state can't be relied upon. So you should only use this for testing to gather 
additional debug information.

~Martin Wierschin

> On Mar 26, 2021, at 11:22 AM, Mike Abdullah via Cocoa-dev 
>  wrote:
> 
> This does seem quite surprising. However, here’s the thing: this code is very 
> strange approach to take.
> 
> Number 1: Cocoa doesn’t support exceptions as an error-handling mechanism 
> except where explicitly stated and supported. You’re trying to use them, 
> which is asking for trouble. The system doesn’t guarantee proper handling of 
> memory if an exception does throw.
> 
> Number 2: Your error handling approach is back-to-front. You’re trying an 
> operation, seeing if it fails, then attempting to guess from the current 
> state (which might have changed in the meantime) why it might have failed.
> 
> Instead, use the proper error APIs and approach:
> 
> 1. Load the data from disk, e.g. +[NSData 
> dataWithContentsOfURL:options:error:]
> 
> If that fails you can introspect the error to your heart’s content to find 
> out what went wrong
> 
> 2. Load the data into your text view. I’m not sure if there’s an API to do 
> that in a single step or not, dunno.
> 
> I also note that your code explicitly is trying to read an RTFD which if 
> memory serves can be a document *bundle* format, so perhaps at step 1 you’d 
> have to go with a file wrapper. But the path you specify is .rtf so I’m 
> guessing you really do have a basic file and can load it as data.
> 
> Mike.
> 
>> On 26 Mar 2021, at 11:11, Mark Allan via Cocoa-dev 
>>  wrote:
>> 
>> Hi folks,
>> 
>> Some users are reporting a crash that I can't reproduce, and in an attempt 
>> to gain additional diagnostics from a user, I wrapped the affected line in a 
>> try/catch block.  For two users it resolve the crash, but for a third, it's 
>> still crashing at the same point!
>> 
>> The crash occurs when a user attempts to open the "About" window from my 
>> app's main menu item. I'm not using the standard about panel as there's a 
>> few additional items I need to display, one of which is an NSTextView which 
>> I populate with the contents of an RTF file from within the app bundle.
>> 
>> I've symbolicated the crash log to find it's happening when populating that 
>> TextView. The line in question now reads as follows:
>> 
>>  @try {
>>  [self.aboutBox.creditsTextView readRTFDFromFile:[[NSBundle 
>> mainBundle] pathForResource:@"Credits" ofType:@"rtf"]];
>>  } @catch (NSException *exception) {
>>  NSLog(@"Error loading the contents of the text file for the 
>> About Box. %@", exception);
>>  //Check we have a file at the expected path 
>>  if([[NSFileManager defaultManager] fileExistsAtPath:[[NSBundle 
>> mainBundle] pathForResource:@"Credits" ofType:@"rtf"]]){
>>  NSLog(@"Yes. Found the RTF credits file");
>>  // check the attributes in case somehow there's no 
>> permission to read the file
>>  NSDictionary *fileAttributes = [[NSFileManager 
>> defaultManager] attributesOfItemAtPath:[[NSBundle mainBundle] 
>> pathForResource:@"Credits" ofType:@"rtf"] error:nil];
>>  NSLog(@"RTF file has following attributes %@", 
>> fileAttributes);
>>  }
>>  else {
>>  NSLog(@"Nope, file not found");
>>  }
>>  }
>> 
>> This is the crash log from the newest build (with the try/catch around that 
>> line):
>> 
>>> Performing @selector(showAboutBox:) from sender NSMenuItem 0x60634540

Re: Exception not being caught in try statement

[Gabriel Zachmann via Cocoa-dev]

I can't really answer your questions ... but just a dumb suggestion: have you 
tried removing all tabs from your RTF file?

Best regards, Gabriel


>> 
>> Any ideas what's going on? Other than the file not being found, why else 
>> might the object at line 3 in the backtrace be nil...and more interestingly, 
>> why is the exception not being caught?
>> 
>> Thanks
>> Mark
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> 
>> 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:
>> https://lists.apple.com/mailman/options/cocoa-dev/dev.iceberg%40gmail.com
>> 
>> This email sent to dev.iceb...@gmail.com
> 
> 
> 
> -- 
> Packaging Resources - http://s.sudre.free.fr/Packaging.html
> 
> 
> --
> 
> Subject: Digest Footer
> 
> ___
> 
> Cocoa-dev mailing list  (Cocoa-dev@lists.apple.com)
> 
> Do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins (at) lists.apple.com
> 
> https://lists.apple.com/mailman/listinfo/cocoa-dev
> 
> 
> --
> 
> End of Cocoa-dev Digest, Vol 18, Issue 8
> 



smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Exception not being caught in try statement

[Stephane Sudre via Cocoa-dev]

It's trying to insert a NSTextTab * object.


On Fri, Mar 26, 2021 at 12:11 PM Mark Allan via Cocoa-dev
 wrote:
>
> Hi folks,
>
> Some users are reporting a crash that I can't reproduce, and in an attempt to 
> gain additional diagnostics from a user, I wrapped the affected line in a 
> try/catch block.  For two users it resolve the crash, but for a third, it's 
> still crashing at the same point!
>
> The crash occurs when a user attempts to open the "About" window from my 
> app's main menu item. I'm not using the standard about panel as there's a few 
> additional items I need to display, one of which is an NSTextView which I 
> populate with the contents of an RTF file from within the app bundle.
>
> I've symbolicated the crash log to find it's happening when populating that 
> TextView. The line in question now reads as follows:
>
> @try {
> [self.aboutBox.creditsTextView readRTFDFromFile:[[NSBundle 
> mainBundle] pathForResource:@"Credits" ofType:@"rtf"]];
> } @catch (NSException *exception) {
> NSLog(@"Error loading the contents of the text file for the 
> About Box. %@", exception);
> //Check we have a file at the expected path
> if([[NSFileManager defaultManager] 
> fileExistsAtPath:[[NSBundle mainBundle] pathForResource:@"Credits" 
> ofType:@"rtf"]]){
> NSLog(@"Yes. Found the RTF credits file");
> // check the attributes in case somehow there's no 
> permission to read the file
> NSDictionary *fileAttributes = [[NSFileManager 
> defaultManager] attributesOfItemAtPath:[[NSBundle mainBundle] 
> pathForResource:@"Credits" ofType:@"rtf"] error:nil];
> NSLog(@"RTF file has following attributes %@", 
> fileAttributes);
> }
> else {
> NSLog(@"Nope, file not found");
> }
> }
>
> This is the crash log from the newest build (with the try/catch around that 
> line):
>
> > Performing @selector(showAboutBox:) from sender NSMenuItem 0x60634540
> > *** Terminating app due to uncaught exception 'NSInvalidArgumentException', 
> > reason: '*** -[__NSArrayM insertObject:atIndex:]: object cannot be nil'
> > terminating with uncaught exception of type NSException
> > abort() called
> >
> > Application Specific Backtrace 1:
> > 0   CoreFoundation  0x7fff206ea6af 
> > __exceptionPreprocess + 242
> > 1   libobjc.A.dylib 0x7fff204223c9 
> > objc_exception_throw + 48
> > 2   CoreFoundation  0x7fff2079ea9a -[__NSCFString 
> > characterAtIndex:].cold.1 + 0
> > 3   CoreFoundation  0x7fff2079c953 -[__NSArrayM 
> > insertObject:atIndex:].cold.2 + 0
> > 4   CoreFoundation  0x7fff20610421 -[__NSArrayM 
> > insertObject:atIndex:] + 1135
> > 5   UIFoundation0x7fff23c223ab 
> > __defaultTabStops_block_invoke + 161
> > 6   libdispatch.dylib   0x7fff203cd7c7 
> > _dispatch_client_callout + 8
> > 7   libdispatch.dylib   0x7fff203ce96b 
> > _dispatch_once_callout + 20
> > 8   UIFoundation0x7fff23c229d7 
> > -[NSMutableParagraphStyle setTabStops:] + 199
> > 9   UIFoundation0x7fff23c3c697 -[NSRTFReader 
> > defaultParagraphStyle] + 75
> > 10  UIFoundation0x7fff23c3c5be -[NSRTFReader 
> > _mutableParagraphStyle] + 112
> > 11  UIFoundation0x7fff23c36113 controlClass + 
> > 1757
> > 12  UIFoundation0x7fff23c356b4 -[NSRTFReader 
> > attributedString] + 76
> > 13  UIFoundation0x7fff23c311a6 
> > _NSReadAttributedStringFromURLOrData + 3213
> > 14  UIFoundation0x7fff23d46985 
> > -[NSAttributedString(NSAttributedStringUIFoundationAdditions) 
> > initWithURL:options:documentAttributes:error:] + 228
> > 15  AppKit  0x7fff23677d9a -[NSTextView 
> > readRTFDFromFile:] + 126
> > 16  MyAppHere 0x000105fa18a7 MyAppHere+ 
> > 227495
> > 17  AppKit  0x7fff230af7fd 
> > -[NSApplication(NSResponder) sendAction:to:from:] + 283
> > 18  AppKit  0x7fff231b2611 -[NSMenuItem 
> > _corePerformAction] + 413
>
>
> Any ideas what's going on? Other than the file not being found, why else 
> might the object at line 3 in the backtrace be nil...and more interestingly, 
> why is the exception not being caught?
>
> Thanks
> Mark
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> 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:

Re: Exception not being caught in try statement

[Mike Abdullah via Cocoa-dev]

This does seem quite surprising. However, here’s the thing: this code is very 
strange approach to take.

Number 1: Cocoa doesn’t support exceptions as an error-handling mechanism 
except where explicitly stated and supported. You’re trying to use them, which 
is asking for trouble. The system doesn’t guarantee proper handling of memory 
if an exception does throw.

Number 2: Your error handling approach is back-to-front. You’re trying an 
operation, seeing if it fails, then attempting to guess from the current state 
(which might have changed in the meantime) why it might have failed.

Instead, use the proper error APIs and approach:

1. Load the data from disk, e.g. +[NSData dataWithContentsOfURL:options:error:]

If that fails you can introspect the error to your heart’s content to find out 
what went wrong

2. Load the data into your text view. I’m not sure if there’s an API to do that 
in a single step or not, dunno.

I also note that your code explicitly is trying to read an RTFD which if memory 
serves can be a document *bundle* format, so perhaps at step 1 you’d have to go 
with a file wrapper. But the path you specify is .rtf so I’m guessing you 
really do have a basic file and can load it as data.

Mike.

> On 26 Mar 2021, at 11:11, Mark Allan via Cocoa-dev 
>  wrote:
> 
> Hi folks,
> 
> Some users are reporting a crash that I can't reproduce, and in an attempt to 
> gain additional diagnostics from a user, I wrapped the affected line in a 
> try/catch block.  For two users it resolve the crash, but for a third, it's 
> still crashing at the same point!
> 
> The crash occurs when a user attempts to open the "About" window from my 
> app's main menu item. I'm not using the standard about panel as there's a few 
> additional items I need to display, one of which is an NSTextView which I 
> populate with the contents of an RTF file from within the app bundle.
> 
> I've symbolicated the crash log to find it's happening when populating that 
> TextView. The line in question now reads as follows:
> 
>   @try {
>   [self.aboutBox.creditsTextView readRTFDFromFile:[[NSBundle 
> mainBundle] pathForResource:@"Credits" ofType:@"rtf"]];
>   } @catch (NSException *exception) {
>   NSLog(@"Error loading the contents of the text file for the 
> About Box. %@", exception);
>   //Check we have a file at the expected path 
>   if([[NSFileManager defaultManager] fileExistsAtPath:[[NSBundle 
> mainBundle] pathForResource:@"Credits" ofType:@"rtf"]]){
>   NSLog(@"Yes. Found the RTF credits file");
>   // check the attributes in case somehow there's no 
> permission to read the file
>   NSDictionary *fileAttributes = [[NSFileManager 
> defaultManager] attributesOfItemAtPath:[[NSBundle mainBundle] 
> pathForResource:@"Credits" ofType:@"rtf"] error:nil];
>   NSLog(@"RTF file has following attributes %@", 
> fileAttributes);
>   }
>   else {
>   NSLog(@"Nope, file not found");
>   }
>   }
> 
> This is the crash log from the newest build (with the try/catch around that 
> line):
> 
>> Performing @selector(showAboutBox:) from sender NSMenuItem 0x60634540
>> *** Terminating app due to uncaught exception 'NSInvalidArgumentException', 
>> reason: '*** -[__NSArrayM insertObject:atIndex:]: object cannot be nil'
>> terminating with uncaught exception of type NSException
>> abort() called
>> 
>> Application Specific Backtrace 1:
>> 0   CoreFoundation  0x7fff206ea6af 
>> __exceptionPreprocess + 242
>> 1   libobjc.A.dylib 0x7fff204223c9 
>> objc_exception_throw + 48
>> 2   CoreFoundation  0x7fff2079ea9a -[__NSCFString 
>> characterAtIndex:].cold.1 + 0
>> 3   CoreFoundation  0x7fff2079c953 -[__NSArrayM 
>> insertObject:atIndex:].cold.2 + 0
>> 4   CoreFoundation  0x7fff20610421 -[__NSArrayM 
>> insertObject:atIndex:] + 1135
>> 5   UIFoundation0x7fff23c223ab 
>> __defaultTabStops_block_invoke + 161
>> 6   libdispatch.dylib   0x7fff203cd7c7 
>> _dispatch_client_callout + 8
>> 7   libdispatch.dylib   0x7fff203ce96b 
>> _dispatch_once_callout + 20
>> 8   UIFoundation0x7fff23c229d7 
>> -[NSMutableParagraphStyle setTabStops:] + 199
>> 9   UIFoundation0x7fff23c3c697 -[NSRTFReader 
>> defaultParagraphStyle] + 75
>> 10  UIFoundation0x7fff23c3c5be -[NSRTFReader 
>> _mutableParagraphStyle] + 112
>> 11  UIFoundation0x7fff23c36113 controlClass + 
>> 1757
>> 12  UIFoundation0x7fff23c356b4 -[NSRTFReader 
>> attributedString] + 76
>> 13  UIFoundation0x7fff23c311a6 
>> _NSReadAttributedStringFromURLOrData + 

Re: Exception not being caught in try statement

[Rob Petrovec via Cocoa-dev]

Don’t forget to include a sample app that demonstrates the problem.

—Rob



> On Mar 26, 2021, at 12:02 PM, Gary L. Wade via Cocoa-dev 
>  wrote:
> 
> Try surrounding the call with beginEditing and endEditing on the text 
> storage. If it still happens, submit a feedback to Apple with the full crash 
> log.
> --
> Gary L. Wade
> http://www.garywade.com/
> 
>> On Mar 26, 2021, at 4:11 AM, Mark Allan via Cocoa-dev 
>>  wrote:
>> 
>> Hi folks,
>> 
>> Some users are reporting a crash that I can't reproduce, and in an attempt 
>> to gain additional diagnostics from a user, I wrapped the affected line in a 
>> try/catch block.  For two users it resolve the crash, but for a third, it's 
>> still crashing at the same point!
>> 
>> The crash occurs when a user attempts to open the "About" window from my 
>> app's main menu item. I'm not using the standard about panel as there's a 
>> few additional items I need to display, one of which is an NSTextView which 
>> I populate with the contents of an RTF file from within the app bundle.
>> 
>> I've symbolicated the crash log to find it's happening when populating that 
>> TextView. The line in question now reads as follows:
>> 
>>   @try {
>>   [self.aboutBox.creditsTextView readRTFDFromFile:[[NSBundle mainBundle] 
>> pathForResource:@"Credits" ofType:@"rtf"]];
>>   } @catch (NSException *exception) {
>>   NSLog(@"Error loading the contents of the text file for the About Box. 
>> %@", exception);
>>   //Check we have a file at the expected path 
>>   if([[NSFileManager defaultManager] fileExistsAtPath:[[NSBundle 
>> mainBundle] pathForResource:@"Credits" ofType:@"rtf"]]){
>>   NSLog(@"Yes. Found the RTF credits file");
>>   // check the attributes in case somehow there's no permission to 
>> read the file
>>   NSDictionary *fileAttributes =[[NSFileManager defaultManager] 
>> attributesOfItemAtPath:[[NSBundle mainBundle] pathForResource:@"Credits" 
>> ofType:@"rtf"] error:nil];
>>   NSLog(@"RTF file has following attributes %@", fileAttributes);
>>   }
>>   else {
>>   NSLog(@"Nope, file not found");
>>   }
>>   }
>> 
>> This is the crash log from the newest build (with the try/catch around that 
>> line):
>> 
>>> Performing @selector(showAboutBox:) from sender NSMenuItem 0x60634540
>>> *** Terminating app due to uncaught exception 'NSInvalidArgumentException', 
>>> reason: '*** -[__NSArrayM insertObject:atIndex:]: object cannot be nil'
>>> terminating with uncaught exception of type NSException
>>> abort() called
>>> 
>>> Application Specific Backtrace 1:
>>> 0   CoreFoundation  0x7fff206ea6af 
>>> __exceptionPreprocess + 242
>>> 1   libobjc.A.dylib 0x7fff204223c9 
>>> objc_exception_throw + 48
>>> 2   CoreFoundation  0x7fff2079ea9a -[__NSCFString 
>>> characterAtIndex:].cold.1 + 0
>>> 3   CoreFoundation  0x7fff2079c953 -[__NSArrayM 
>>> insertObject:atIndex:].cold.2 + 0
>>> 4   CoreFoundation  0x7fff20610421 -[__NSArrayM 
>>> insertObject:atIndex:] + 1135
>>> 5   UIFoundation0x7fff23c223ab 
>>> __defaultTabStops_block_invoke + 161
>>> 6   libdispatch.dylib   0x7fff203cd7c7 
>>> _dispatch_client_callout + 8
>>> 7   libdispatch.dylib   0x7fff203ce96b 
>>> _dispatch_once_callout + 20
>>> 8   UIFoundation0x7fff23c229d7 
>>> -[NSMutableParagraphStyle setTabStops:] + 199
>>> 9   UIFoundation0x7fff23c3c697 -[NSRTFReader 
>>> defaultParagraphStyle] + 75
>>> 10  UIFoundation0x7fff23c3c5be -[NSRTFReader 
>>> _mutableParagraphStyle] + 112
>>> 11  UIFoundation0x7fff23c36113 controlClass + 
>>> 1757
>>> 12  UIFoundation0x7fff23c356b4 -[NSRTFReader 
>>> attributedString] + 76
>>> 13  UIFoundation0x7fff23c311a6 
>>> _NSReadAttributedStringFromURLOrData + 3213
>>> 14  UIFoundation0x7fff23d46985 
>>> -[NSAttributedString(NSAttributedStringUIFoundationAdditions) 
>>> initWithURL:options:documentAttributes:error:] + 228
>>> 15  AppKit  0x7fff23677d9a -[NSTextView 
>>> readRTFDFromFile:] + 126
>>> 16  MyAppHere 0x000105fa18a7 MyAppHere+ 
>>> 227495
>>> 17  AppKit  0x7fff230af7fd 
>>> -[NSApplication(NSResponder) sendAction:to:from:] + 283
>>> 18  AppKit  0x7fff231b2611 -[NSMenuItem 
>>> _corePerformAction] + 413
>> 
>> 
>> Any ideas what's going on? Other than the file not being found, why else 
>> might the object at line 3 in the backtrace be nil...and more interestingly, 
>> why is the exception not being caught?
>> 
>> Thanks
>> Mark
> 
> ___
> 
> Cocoa-dev mailing 

Re: Exception not being caught in try statement

[Gary L. Wade via Cocoa-dev]

Try surrounding the call with beginEditing and endEditing on the text storage. 
If it still happens, submit a feedback to Apple with the full crash log.
--
Gary L. Wade
http://www.garywade.com/

> On Mar 26, 2021, at 4:11 AM, Mark Allan via Cocoa-dev 
>  wrote:
> 
> Hi folks,
> 
> Some users are reporting a crash that I can't reproduce, and in an attempt to 
> gain additional diagnostics from a user, I wrapped the affected line in a 
> try/catch block.  For two users it resolve the crash, but for a third, it's 
> still crashing at the same point!
> 
> The crash occurs when a user attempts to open the "About" window from my 
> app's main menu item. I'm not using the standard about panel as there's a few 
> additional items I need to display, one of which is an NSTextView which I 
> populate with the contents of an RTF file from within the app bundle.
> 
> I've symbolicated the crash log to find it's happening when populating that 
> TextView. The line in question now reads as follows:
> 
>@try {
>[self.aboutBox.creditsTextView readRTFDFromFile:[[NSBundle mainBundle] 
> pathForResource:@"Credits" ofType:@"rtf"]];
>} @catch (NSException *exception) {
>NSLog(@"Error loading the contents of the text file for the About Box. 
> %@", exception);
>//Check we have a file at the expected path 
>if([[NSFileManager defaultManager] fileExistsAtPath:[[NSBundle 
> mainBundle] pathForResource:@"Credits" ofType:@"rtf"]]){
>NSLog(@"Yes. Found the RTF credits file");
>// check the attributes in case somehow there's no permission to 
> read the file
>NSDictionary *fileAttributes =[[NSFileManager defaultManager] 
> attributesOfItemAtPath:[[NSBundle mainBundle] pathForResource:@"Credits" 
> ofType:@"rtf"] error:nil];
>NSLog(@"RTF file has following attributes %@", fileAttributes);
>}
>else {
>NSLog(@"Nope, file not found");
>}
>}
> 
> This is the crash log from the newest build (with the try/catch around that 
> line):
> 
>> Performing @selector(showAboutBox:) from sender NSMenuItem 0x60634540
>> *** Terminating app due to uncaught exception 'NSInvalidArgumentException', 
>> reason: '*** -[__NSArrayM insertObject:atIndex:]: object cannot be nil'
>> terminating with uncaught exception of type NSException
>> abort() called
>> 
>> Application Specific Backtrace 1:
>> 0   CoreFoundation  0x7fff206ea6af 
>> __exceptionPreprocess + 242
>> 1   libobjc.A.dylib 0x7fff204223c9 
>> objc_exception_throw + 48
>> 2   CoreFoundation  0x7fff2079ea9a -[__NSCFString 
>> characterAtIndex:].cold.1 + 0
>> 3   CoreFoundation  0x7fff2079c953 -[__NSArrayM 
>> insertObject:atIndex:].cold.2 + 0
>> 4   CoreFoundation  0x7fff20610421 -[__NSArrayM 
>> insertObject:atIndex:] + 1135
>> 5   UIFoundation0x7fff23c223ab 
>> __defaultTabStops_block_invoke + 161
>> 6   libdispatch.dylib   0x7fff203cd7c7 
>> _dispatch_client_callout + 8
>> 7   libdispatch.dylib   0x7fff203ce96b 
>> _dispatch_once_callout + 20
>> 8   UIFoundation0x7fff23c229d7 
>> -[NSMutableParagraphStyle setTabStops:] + 199
>> 9   UIFoundation0x7fff23c3c697 -[NSRTFReader 
>> defaultParagraphStyle] + 75
>> 10  UIFoundation0x7fff23c3c5be -[NSRTFReader 
>> _mutableParagraphStyle] + 112
>> 11  UIFoundation0x7fff23c36113 controlClass + 
>> 1757
>> 12  UIFoundation0x7fff23c356b4 -[NSRTFReader 
>> attributedString] + 76
>> 13  UIFoundation0x7fff23c311a6 
>> _NSReadAttributedStringFromURLOrData + 3213
>> 14  UIFoundation0x7fff23d46985 
>> -[NSAttributedString(NSAttributedStringUIFoundationAdditions) 
>> initWithURL:options:documentAttributes:error:] + 228
>> 15  AppKit  0x7fff23677d9a -[NSTextView 
>> readRTFDFromFile:] + 126
>> 16  MyAppHere 0x000105fa18a7 MyAppHere+ 
>> 227495
>> 17  AppKit  0x7fff230af7fd 
>> -[NSApplication(NSResponder) sendAction:to:from:] + 283
>> 18  AppKit  0x7fff231b2611 -[NSMenuItem 
>> _corePerformAction] + 413
> 
> 
> Any ideas what's going on? Other than the file not being found, why else 
> might the object at line 3 in the backtrace be nil...and more interestingly, 
> why is the exception not being caught?
> 
> Thanks
> Mark

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:

Re: Error reporting in Cocoa (was Re: Exception not being caught)

[A.M.]

On Mar 21, 2011, at 10:24 PM, Chris Hanson wrote:

 Ultimately, the solution will be to modify HessianKit -- or any other 
 framework that presents an RPC-style interface[1] -- to follow the Cocoa 
 convention of returning BOOL (or a non-nil/nil object reference) to indicate 
 success or failure, and to fill in an NSError passed by reference if the 
 caller desires additional failure details.
 
  -- Chris
 
 [1] Distributed Objects doesn’t work this way - it predates NSError and uses 
 exceptions, which results in exactly the problems discussed in this thread.  
 Often DO calls will wind up wrapped in an API that just does a @try/@catch 
 around the call and returns success/failure, for exactly this reason.

Hi Chris,

I am curious as to how you would propose to add error: handlers to DO calls 
considering that DO is meant to transparent and cannot modify method 
signatures. For example, assuming you were designing a new DO framework, how 
would you propose changing this:

int junk = [secretlyDistantObject calculate:4];

to allow for a socket timeout? Would you then wrap any API which could be 
potentially called by DO with the additional error: argument?

Cheers,
M___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Error reporting in Cocoa (was Re: Exception not being caught)

[Kyle Sluder]

On Tue, Mar 22, 2011 at 8:07 AM, A.M. age...@themactionfaction.com wrote:
 I am curious as to how you would propose to add error: handlers to DO calls 
 considering that DO is meant to transparent and cannot modify method 
 signatures. For example, assuming you were designing a new DO framework, how 
 would you propose changing this:

 int junk = [secretlyDistantObject calculate:4];

 to allow for a socket timeout? Would you then wrap any API which could be 
 potentially called by DO with the additional error: argument?

Good practice probably won't allow secretly distant objects to leak
into the rest of the app. But that doesn't solve your problem: how
does DO report DO errors without modifying message signatures?
Exceptions really are the only answer. As long as DO is internally
safe with respect to DO exceptions, this is okay. It's when you start
introducing foreign exceptions that implementation gets hairy.

Rick was attempting to handle exceptions in his client code that were
being thrown through HessianKit. Because of Cocoa's attitude towards
exceptions, this isn't guaranteed to work. The lack of exception
support across a forwarding boundary is a significant change in
language behavior that fails to fulfill the language's contract, but
fixing it won't actually solve Rick's problem, which is that he's
trying to throw exceptions through stack frames he doesn't own.

--Kyle Sluder
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Exception not being caught

[jonat...@mugginsoft.com]

On 21 Mar 2011, at 04:11, Rick Mann wrote:

 Can you give us the exception report?
 Is it an NSException instance?
 
 Yes. It is raised by this line of code:
 
[NSException raise:NSInvalidArchiveOperationException format:@Network 
 error domain:%@ code:%d, [requestError domain], [requestError code]];
As you are raising the exception then you could try raising the exception 
experimentally when the operation starts to help source the problem.
You mentioned break points earlier. What happens when the code runs outside of 
the development environment.

 
 This might indicate that your exception is not occurring on your main thread.
 
 It is most certainly NOT occurring on the main thread. Never said it was (in 
 fact, I figured the bit about NSOperation would imply it was not).
 
Now we know.
Have you tried using NSExceptionHandler? It might provide some insight.

If the problem persists you could post more code.

If it's a fundamental issue it should be demonstrable in a short test project.

Regards

Jonathan Mitchell

Developer
Mugginsoft LLP
http://www.mugginsoft.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Exception not being caught

[Rick Mann]

On Mar 21, 2011, at 2:50 AM, jonat...@mugginsoft.com wrote:

 As you are raising the exception then you could try raising the exception 
 experimentally when the operation starts to help source the problem.
 You mentioned break points earlier. What happens when the code runs outside 
 of the development environment.

Without the breakpoint, the network pipe doesn't break, and it runs fine. I'll 
try raising the exception deliberately.

 Have you tried using NSExceptionHandler? It might provide some insight.

That appears to be a Mac OS X-only facility, and I failed to mention this was 
iOS.

-- 
Rick

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Exception not being caught

[Greg Parker]

On Mar 20, 2011, at 9:11 PM, Rick Mann wrote:
 On Mar 20, 2011, at 12:45 PM, jonat...@mugginsoft.com wrote:
 On 20 Mar 2011, at 19:17, Rick Mann wrote:
 I have some code, called from a subclass of NSOperation, that throws an 
 exception pretty reliably if I put a breakpoint elsewhere in the code (it 
 is code that does an HTTP request, and it's getting a broken pipe, and 
 raising an exception to report it; the breakpoint (in another thread) seems 
 to trigger this behavior).
 
 My NSOperation subclass wraps the call to the network code in a @try/catch 
 block. But when this exception is raised, the app terminates due to an 
 uncaught exception.
 
 2011-03-20 18:41:13.233 MissionClock[17979:7e03] *** Terminating app due to 
 uncaught exception 'NSInvalidArchiveOperationException', reason: 'Network 
 error domain:NSURLErrorDomain code:-1005'
 *** Call stack at first throw:
 (
   0   CoreFoundation  0x015be5a9 
 __exceptionPreprocess + 185
   1   libobjc.A.dylib 0x01712313 objc_exception_throw 
 + 44
   2   CoreFoundation  0x01576ef8 +[NSException 
 raise:format:arguments:] + 136
   3   CoreFoundation  0x01576e6a +[NSException 
 raise:format:] + 58
   4   MissionClock0x00010920 
 -[CWDistantHessianObject(Private) sendRequestWithPostData:] + 426
   5   MissionClock0x000115ad 
 -[CWDistantHessianObject forwardInvocation:] + 77
   6   CoreFoundation  0x0152fa04 ___forwarding___ + 
 1124
   7   CoreFoundation  0x0152f522 
 _CF_forwarding_prep_0 + 50
   8   MissionClock0x0001aef8 -[GetMissionListOp 
 main] + 722
   9   Foundation  0x00128b76 
 -[__NSOperationInternal start] + 747
   10  Foundation  0x001287ca 
 startOperations_block_invoke_2 + 106
   11  libdispatch_sim.dylib   0x01bf1289 
 _dispatch_call_block_and_release + 16
   12  libdispatch_sim.dylib   0x01bf458a 
 _dispatch_worker_thread2 + 252
   13  libSystem.B.dylib   0x92b46d41 _pthread_wqthread + 
 390
   14  libSystem.B.dylib   0x92b46b86 start_wqthread + 30
 )

You can't currently throw an exception across a forwarded call. When the 
exception unwinder hits the forwarding frame, it stops and the exception goes 
uncaught. You'll need to put your exception handler at a different level.


-- 
Greg Parker gpar...@apple.com Runtime Wrangler


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Exception not being caught

[Rick Mann]

On Mar 21, 2011, at 2:03 PM, Greg Parker wrote:

 On Mar 20, 2011, at 9:11 PM, Rick Mann wrote:
 On Mar 20, 2011, at 12:45 PM, jonat...@mugginsoft.com wrote:
 On 20 Mar 2011, at 19:17, Rick Mann wrote:
 I have some code, called from a subclass of NSOperation, that throws an 
 exception pretty reliably if I put a breakpoint elsewhere in the code (it 
 is code that does an HTTP request, and it's getting a broken pipe, and 
 raising an exception to report it; the breakpoint (in another thread) 
 seems to trigger this behavior).
 
 My NSOperation subclass wraps the call to the network code in a @try/catch 
 block. But when this exception is raised, the app terminates due to an 
 uncaught exception.
 
 2011-03-20 18:41:13.233 MissionClock[17979:7e03] *** Terminating app due to 
 uncaught exception 'NSInvalidArchiveOperationException', reason: 'Network 
 error domain:NSURLErrorDomain code:-1005'
 *** Call stack at first throw:
 (
  0   CoreFoundation  0x015be5a9 
 __exceptionPreprocess + 185
  1   libobjc.A.dylib 0x01712313 objc_exception_throw 
 + 44
  2   CoreFoundation  0x01576ef8 +[NSException 
 raise:format:arguments:] + 136
  3   CoreFoundation  0x01576e6a +[NSException 
 raise:format:] + 58
  4   MissionClock0x00010920 
 -[CWDistantHessianObject(Private) sendRequestWithPostData:] + 426
  5   MissionClock0x000115ad 
 -[CWDistantHessianObject forwardInvocation:] + 77
  6   CoreFoundation  0x0152fa04 ___forwarding___ + 
 1124
  7   CoreFoundation  0x0152f522 
 _CF_forwarding_prep_0 + 50
  8   MissionClock0x0001aef8 -[GetMissionListOp 
 main] + 722
  9   Foundation  0x00128b76 
 -[__NSOperationInternal start] + 747
  10  Foundation  0x001287ca 
 startOperations_block_invoke_2 + 106
  11  libdispatch_sim.dylib   0x01bf1289 
 _dispatch_call_block_and_release + 16
  12  libdispatch_sim.dylib   0x01bf458a 
 _dispatch_worker_thread2 + 252
  13  libSystem.B.dylib   0x92b46d41 _pthread_wqthread + 
 390
  14  libSystem.B.dylib   0x92b46b86 start_wqthread + 30
 )
 
 You can't currently throw an exception across a forwarded call. When the 
 exception unwinder hits the forwarding frame, it stops and the exception goes 
 uncaught. You'll need to put your exception handler at a different level.

Thanks for the info, Greg! I hope I can find a place to put the handler.

-- 
Rick


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Exception not being caught

[Kyle Sluder]

On Mon, Mar 21, 2011 at 2:03 PM, Greg Parker gpar...@apple.com wrote:
 You can't currently throw an exception across a forwarded call. When the 
 exception unwinder hits the forwarding frame, it stops and the exception goes 
 uncaught. You'll need to put your exception handler at a different level.

Does this limitation exist on the desktop as well?

--Kyle Sluder
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Exception not being caught

[Greg Parker]

On Mar 21, 2011, at 2:06 PM, Kyle Sluder wrote:
 On Mon, Mar 21, 2011 at 2:03 PM, Greg Parker gpar...@apple.com wrote:
 You can't currently throw an exception across a forwarded call. When the 
 exception unwinder hits the forwarding frame, it stops and the exception 
 goes uncaught. You'll need to put your exception handler at a different 
 level.
 
 Does this limitation exist on the desktop as well?

I'm pretty sure it fails on any platform that uses the modern ABI (iOS and 
64-bit Mac), but I can't find the bug report at the moment.

(The problem is that the forwarding machinery is hand-written assembly, and 
nobody added hand-written exception unwind tables to match. With zero-cost 
exceptions, the unwinder cannot process a frame without its unwind tables.)


-- 
Greg Parker gpar...@apple.com Runtime Wrangler


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Exception not being caught

[Rick Mann]

On Mar 21, 2011, at 2:03 PM, Greg Parker wrote:

 On Mar 20, 2011, at 9:11 PM, Rick Mann wrote:
 On Mar 20, 2011, at 12:45 PM, jonat...@mugginsoft.com wrote:
 On 20 Mar 2011, at 19:17, Rick Mann wrote:
 I have some code, called from a subclass of NSOperation, that throws an 
 exception pretty reliably if I put a breakpoint elsewhere in the code (it 
 is code that does an HTTP request, and it's getting a broken pipe, and 
 raising an exception to report it; the breakpoint (in another thread) 
 seems to trigger this behavior).
 
 My NSOperation subclass wraps the call to the network code in a @try/catch 
 block. But when this exception is raised, the app terminates due to an 
 uncaught exception.
 
 2011-03-20 18:41:13.233 MissionClock[17979:7e03] *** Terminating app due to 
 uncaught exception 'NSInvalidArchiveOperationException', reason: 'Network 
 error domain:NSURLErrorDomain code:-1005'
 *** Call stack at first throw:
 (
  0   CoreFoundation  0x015be5a9 
 __exceptionPreprocess + 185
  1   libobjc.A.dylib 0x01712313 objc_exception_throw 
 + 44
  2   CoreFoundation  0x01576ef8 +[NSException 
 raise:format:arguments:] + 136
  3   CoreFoundation  0x01576e6a +[NSException 
 raise:format:] + 58
  4   MissionClock0x00010920 
 -[CWDistantHessianObject(Private) sendRequestWithPostData:] + 426
  5   MissionClock0x000115ad 
 -[CWDistantHessianObject forwardInvocation:] + 77
  6   CoreFoundation  0x0152fa04 ___forwarding___ + 
 1124
  7   CoreFoundation  0x0152f522 
 _CF_forwarding_prep_0 + 50
  8   MissionClock0x0001aef8 -[GetMissionListOp 
 main] + 722
  9   Foundation  0x00128b76 
 -[__NSOperationInternal start] + 747
  10  Foundation  0x001287ca 
 startOperations_block_invoke_2 + 106
  11  libdispatch_sim.dylib   0x01bf1289 
 _dispatch_call_block_and_release + 16
  12  libdispatch_sim.dylib   0x01bf458a 
 _dispatch_worker_thread2 + 252
  13  libSystem.B.dylib   0x92b46d41 _pthread_wqthread + 
 390
  14  libSystem.B.dylib   0x92b46b86 start_wqthread + 30
 )
 
 You can't currently throw an exception across a forwarded call. When the 
 exception unwinder hits the forwarding frame, it stops and the exception goes 
 uncaught. You'll need to put your exception handler at a different level.

Hrm. This is actually a bit of a pickle. HessianKit implements the Hessian RPC 
API. It does so by having the client declare a protocol (and a mapping from 
Obj-C-to-Java method signatures), and the providing an implementation for the 
selector. In this case, my code is actually calling a selector that results in 
an invocation of a method on my server.

There really is no place for me to put an exception handler. I could modify 
HessianKit, and trap exceptions in the forwarding code, but there's no way to 
report the error back to my calling code.

-- 
Rick

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Exception not being caught

[Rick Mann]

On Mar 21, 2011, at 2:19 PM, Greg Parker wrote:

 On Mar 21, 2011, at 2:06 PM, Kyle Sluder wrote:
 On Mon, Mar 21, 2011 at 2:03 PM, Greg Parker gpar...@apple.com wrote:
 You can't currently throw an exception across a forwarded call. When the 
 exception unwinder hits the forwarding frame, it stops and the exception 
 goes uncaught. You'll need to put your exception handler at a different 
 level.
 
 Does this limitation exist on the desktop as well?
 
 I'm pretty sure it fails on any platform that uses the modern ABI (iOS and 
 64-bit Mac), but I can't find the bug report at the moment.
 
 (The problem is that the forwarding machinery is hand-written assembly, and 
 nobody added hand-written exception unwind tables to match. With zero-cost 
 exceptions, the unwinder cannot process a frame without its unwind tables.)

I just reported a new bug for it:

 9164577

Thanks,
-- 
Rick


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Exception not being caught

[Laurent Daudelin]

On Mar 21, 2011, at 14:19, Greg Parker wrote:

 (The problem is that the forwarding machinery is hand-written assembly, and 
 nobody added hand-written exception unwind tables to match. With zero-cost 
 exceptions, the unwinder cannot process a frame without its unwind tables.)

Hand-written assembly? Really?

-Laurent.
-- 
Laurent Daudelin
AIM/iChat/Skype:LaurentDaudelin 
http://www.nemesys-soft.com/
Logiciels Nemesys Software  
laur...@nemesys-soft.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Exception not being caught

[Greg Parker]

On Mar 21, 2011, at 2:43 PM, Laurent Daudelin wrote:
 On Mar 21, 2011, at 14:19, Greg Parker wrote:
 (The problem is that the forwarding machinery is hand-written assembly, and 
 nobody added hand-written exception unwind tables to match. With zero-cost 
 exceptions, the unwinder cannot process a frame without its unwind tables.)
 
 Hand-written assembly? Really?

Yep. The forwarding machinery needs to pull parameters off the stack for 
arbitrary method signatures. You can't do that in C.


-- 
Greg Parker gpar...@apple.com Runtime Wrangler


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Exception not being caught

[Steve Steinitz]

Hi Johnathan

On 21/03/11, Rick Mann  Jonathan Mitchell wrote:


My NSOperation subclass wraps the call to the network code in a
@try/catch block. But when this exception is raised, the app
terminates due to an uncaught exception.



Exceptions on the main thread of a Cocoa application do not typically
rise to the level of the uncaught exception handler because the global
application object catches all such exceptions.

This might indicate that your exception is not occurring on your main thread.

Check out the section entitled Controlling a Program's Response to Exceptions.


That is an interesting reference, but the behavior I see doesn't 
seem to exactly fit a threading hypothesis.


I've set up an uncaught exception handler delegate (a subclass 
of NSExceptionHandlerDelegate).  When Apple's code throws 
exceptions from, say,


+[NSObject(NSObject) doesNotRecognizeSelector:]
+[NSObject(NSObject) doesNotRecognizeSelector:]
___forwarding___
_CF_forwarding_prep_0

(probably not a separate thread)

or Core Data's

_PFFaultHandlerLookupRow
-[NSFaultHandler fulfillFault:withContext:]
_PF_FulfillDeferredFault
-[NSManagedObject valueForKey:]
-[NSFunctionExpression expressionValueWithObject:context:]
-[NSComparisonPredicate evaluateWithObject:substitutionVariables:]
_filterObjectsUsingPredicate
-[NSArray(NSPredicateSupport) filteredArrayUsingPredicate:]

(maybe a separate thread?)

my local @catch blocks are not invoked - instead, my 
NSExceptionHandlerDelegate subclass catches them.


The former is easy enough to simulate for testing but the latter 
needs a real error (doesn't it?).  My latest stab-in-the-dark 
try is to put one or two of the following at the end of 
troublesome @try blocks:


[[NSRunLoop mainRunLoop] runUntilDate:[NSDate distantPast]];

I've used those elsewhere (e.g. waiting for NSArrayController 
newObject to do its thing - don't ask :) and have noticed that 
they can throw @catch-able exceptions from the Apple frameworks.


That nastiness failing, it would be handy to have a bullet-proof 
way to @catch any exception originating from a @try block - 
non-main thread, alternate universe or otherwise.


Cheers,

Steve Steinitz

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Error reporting in Cocoa (was Re: Exception not being caught)

[Chris Hanson]

On Mar 21, 2011, at 2:19 PM, Rick Mann wrote:

 You can't currently throw an exception across a forwarded call. When the 
 exception unwinder hits the forwarding frame, it stops and the exception 
 goes uncaught. You'll need to put your exception handler at a different 
 level.
 
 Hrm. This is actually a bit of a pickle. HessianKit implements the Hessian 
 RPC API. It does so by having the client declare a protocol (and a mapping 
 from Obj-C-to-Java method signatures), and the providing an implementation 
 for the selector. In this case, my code is actually calling a selector that 
 results in an invocation of a method on my server.
 
 There really is no place for me to put an exception handler. I could modify 
 HessianKit, and trap exceptions in the forwarding code, but there's no way to 
 report the error back to my calling code.

That’s a bit of an issue anyway, for which it would probably be worth modifying 
HessianKit:  Regardless of one’s feelings on the topic, exceptions are not an 
appropriate mechanism for handling either control flow or error reporting in 
Cocoa or Cocoa Touch code.

The reason is that if your exception crosses any stack frame you don’t fully 
control, all bets are off when it comes to the state of your program.  The 
frameworks have all been written with the assumption that exceptions are only 
for catastrophic (non-recoverable) failures, and that the only way to respond 
to an exception is to terminate the application as gracefully as possible.

When writing code to interoperate with Cocoa and Cocoa Touch, everyone needs to 
follow the same pattern; this is an area where (as you’ve found) impedance 
mismatch will cause problems.

Ultimately, the solution will be to modify HessianKit -- or any other framework 
that presents an RPC-style interface[1] -- to follow the Cocoa convention of 
returning BOOL (or a non-nil/nil object reference) to indicate success or 
failure, and to fill in an NSError passed by reference if the caller desires 
additional failure details.

  -- Chris

[1] Distributed Objects doesn’t work this way - it predates NSError and uses 
exceptions, which results in exactly the problems discussed in this thread.  
Often DO calls will wind up wrapped in an API that just does a @try/@catch 
around the call and returns success/failure, for exactly this reason.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Error reporting in Cocoa (was Re: Exception not being caught)

[Rick Mann]

On Mar 21, 2011, at 7:24 PM, Chris Hanson wrote:

 The reason is that if your exception crosses any stack frame you don’t fully 
 control, all bets are off when it comes to the state of your program.  The 
 frameworks have all been written with the assumption that exceptions are only 
 for catastrophic (non-recoverable) failures, and that the only way to respond 
 to an exception is to terminate the application as gracefully as possible.

Not sure I agree that this is a good reason. Prior to Mac OS X, I wrote a lot 
of Carbon code with callbacks in C++. I understood the need to install a top 
(callback)-level exception handler to ensure the exceptions weren't propagated 
back into unaware code. I did this frequently and successfully.

Cocoa's approach effectively forbids exceptions as a convenient and elegant 
exceptional-condition-handling mechanism, yet the occasional use within Cocoa 
itself means I still have to deal with the consequences.

Moreover, since exceptions did work across forward invocations prior to Cocoa 
Touch and 64-bit Mac OS X, I think it is reasonable to assume they should still 
work.

In the meantime, I've modified HessianKit to catch exceptions and return them 
as a return parameter, and all my instances of calling RPC methods now check 
their return parameter to see if it's an exception.

What I had before was better: not only could I catch exceptions in HessianKit 
(like network errors), I was also able to catch exceptions thrown in the Java 
server. It was pretty cool.

-- 
Rick

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Exception not being caught

[jonat...@mugginsoft.com]

On 20 Mar 2011, at 19:17, Rick Mann wrote:

 I have some code, called from a subclass of NSOperation, that throws an 
 exception pretty reliably if I put a breakpoint elsewhere in the code (it is 
 code that does an HTTP request, and it's getting a broken pipe, and raising 
 an exception to report it; the breakpoint (in another thread) seems to 
 trigger this behavior).
 
 My NSOperation subclass wraps the call to the network code in a @try/catch 
 block. But when this exception is raised, the app terminates due to an 
 uncaught exception.
 
 Any idea why?
 
 TIA,
 Rick
 
Can you give us the exception report?
Is it an NSException instance?

The Exception Programming Topics states (amongst lots of other good and 
relevant stuf):

Exceptions on the main thread of a Cocoa application do not typically rise to 
the level of the uncaught exception handler because the global application 
object catches all such exceptions.

This might indicate that your exception is not occurring on your main thread.

Check out the section entitled Controlling a Program’s Response to Exceptions.

Regards

Jonathan Mitchell

Developer
Mugginsoft LLP
http://www.mugginsoft.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Exception not being caught

[Rick Mann]

On Mar 20, 2011, at 12:45 PM, jonat...@mugginsoft.com wrote:

 
 
 On 20 Mar 2011, at 19:17, Rick Mann wrote:
 
 I have some code, called from a subclass of NSOperation, that throws an 
 exception pretty reliably if I put a breakpoint elsewhere in the code (it is 
 code that does an HTTP request, and it's getting a broken pipe, and raising 
 an exception to report it; the breakpoint (in another thread) seems to 
 trigger this behavior).
 
 My NSOperation subclass wraps the call to the network code in a @try/catch 
 block. But when this exception is raised, the app terminates due to an 
 uncaught exception.
 
 Any idea why?
 
 TIA,
 Rick
 
 Can you give us the exception report?
 Is it an NSException instance?

Yes. It is raised by this line of code:

[NSException raise:NSInvalidArchiveOperationException format:@Network 
error domain:%@ code:%d, [requestError domain], [requestError code]];

 This might indicate that your exception is not occurring on your main thread.

It is most certainly NOT occurring on the main thread. Never said it was (in 
fact, I figured the bit about NSOperation would imply it was not).

Here's the trace:

2011-03-20 18:41:13.233 MissionClock[17979:7e03] *** Terminating app due to 
uncaught exception 'NSInvalidArchiveOperationException', reason: 'Network error 
domain:NSURLErrorDomain code:-1005'
*** Call stack at first throw:
(
0   CoreFoundation  0x015be5a9 
__exceptionPreprocess + 185
1   libobjc.A.dylib 0x01712313 objc_exception_throw 
+ 44
2   CoreFoundation  0x01576ef8 +[NSException 
raise:format:arguments:] + 136
3   CoreFoundation  0x01576e6a +[NSException 
raise:format:] + 58
4   MissionClock0x00010920 
-[CWDistantHessianObject(Private) sendRequestWithPostData:] + 426
5   MissionClock0x000115ad 
-[CWDistantHessianObject forwardInvocation:] + 77
6   CoreFoundation  0x0152fa04 ___forwarding___ + 
1124
7   CoreFoundation  0x0152f522 
_CF_forwarding_prep_0 + 50
8   MissionClock0x0001aef8 -[GetMissionListOp 
main] + 722
9   Foundation  0x00128b76 
-[__NSOperationInternal start] + 747
10  Foundation  0x001287ca 
startOperations_block_invoke_2 + 106
11  libdispatch_sim.dylib   0x01bf1289 
_dispatch_call_block_and_release + 16
12  libdispatch_sim.dylib   0x01bf458a 
_dispatch_worker_thread2 + 252
13  libSystem.B.dylib   0x92b46d41 _pthread_wqthread + 
390
14  libSystem.B.dylib   0x92b46b86 start_wqthread + 30
)
terminate called after throwing an instance of 'NSException'
Program received signal:  “SIGABRT”.


-- 
Rick

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com