Re: Proper way to throw an exception in an iOS application...
Re: Proper way to throw an exception in an iOS application...
- Subject: Re: Proper way to throw an exception in an iOS application...
- From: Andreas Grosam <email@hidden>
- Date: Sun, 18 Mar 2012 12:37:34 +0100
On Mar 17, 2012, at 10:43 PM, Quincey Morris wrote:
> I also have to admit that at one point I tried -- and distinctly failed -- to force the (released) app to terminate on any uncaught-by-my-code exception. I never figured out what I was doing wrong, but I expect I'll learn someday.
I think what you are talking about is the default behavior of *Mac OS X Cocoa Apps* (not iOS!):
The global Application object catches all those uncaught Exceptions at the top level event handler and "handles" them by printing a message to the console and then continues event handling. Other means to recover properly are not done of course thus the app is left in a possibly corrupt state.
This behavior cannot be changed that easily, since there is no "hook" where you could possibly override a method. You would need to duplicate the complete event handling mechanism of NSApplication. There is also no way to use an AppDelegate's method to override this behavior.
I guess, at the moment there are probably running many Mac OS X apps out there which unnoticeably entered a corrupt state due to an uncaught exception and are behaving incorrectly, without giving the user nor the developer a chance to notify this.
Due to AppKits default behavior and since it is incredible cumbersome to fix it (which would calling abort() in the simplest approach), we should be very careful when considering to throw exceptions in our code - library for instance, since this will likely make things worse for the application.
Andreas
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden