Re: App Will Not Terminate After Uncaught Excpetion
Re: App Will Not Terminate After Uncaught Excpetion
- Subject: Re: App Will Not Terminate After Uncaught Excpetion
- From: Andreas Grosam <email@hidden>
- Date: Thu, 16 Dec 2010 20:24:50 +0100
On Dec 16, 2010, at 5:32 PM, Nick Zitzmann wrote:
> See <https://github.com/omnigroup/OmniGroup/blob/master/Frameworks/OmniAppKit/OAApplication.m> for one such example.
Thank you very much, this is exactly what I'm looking for! :)
On Dec 16, 2010, at 5:55 PM, Nick Zitzmann wrote:
>
> On Dec 16, 2010, at 9:40 AM, Jean-Daniel Dupas wrote:
>>
>> Le 16 déc. 2010 à 17:32, Nick Zitzmann a écrit :
>>>
>>> On Dec 16, 2010, at 6:38 AM, Andreas Grosam wrote:
>>>
>>>> In Cocoa, exceptions are considered fatal errors, and code is usually not exception safe.
>>>
>>> [citation needed]
>>
>> From "Introduction to Exception Programming Topics for Cocoa"
>>
>> “Important: You should reserve the use of exceptions for programming or unexpected runtime errors such as out-of-bounds collection access, attempts to mutate immutable objects, sending an invalid message, and losing the connection to the window server. You usually take care of these sorts of errors with exceptions when an application is being created rather than at runtime.
>
> Yes, but fatal errors are usually the type that can bring down the entire program, such as running out of memory or dividing by zero. An out-of-bounds exception often doesn't have to kill the program. Of course, if the developer wants it to kill the program, then they can override -[NSApplication run] to catch the exception and quit.
>
> Nick Zitzmann
> <http://www.chronosnet.com/>
It's not relevant whether the exception is a fatal error or (ab)used as a messaging mechanism. The very fact that an exception is thrown in a framework which is not exception-safe and the fact that this exception made its way through till the top of the event-handling routine makes it very likely that the application is left in a corrupted state.
The current behavior in Cocoa would entail a level of "strong exception safety"(see below).
From "Exceptions and the Cocoa Frameworks" in Apple Documentation:
"The Cocoa frameworks are generally not exception-safe. The general pattern is that exceptions are reserved for programmer error only, and the program catching such an exception should quit soon afterwards."
About Exception Safety (http://en.wikipedia.org/wiki/Exception_handling):
A piece of code is said to be exception-safe, if run-time failures within the code will not produce ill effects, such as memory leaks, garbled stored data, or invalid output. Exception-safe code must satisfy invariants placed on the code even if exceptions occur. There are several levels of exception safety:
1) Failure transparency, also known as the no throw guarantee: Operations are guaranteed to succeed and satisfy all requirements even in presence of exceptional situations. If an exception occurs, it will not throw the exception further up. (Best level of exception safety.)
2) Commit or rollback semantics, also known as strong exception safety or no-change guarantee: Operations can fail, but failed operations are guaranteed to have no side effects so all data retain original values.[2]
3) Basic exception safety: Partial execution of failed operations can cause side effects, but invariants on the state are preserved. Any stored data will contain valid values even if data has different values now from before the exception.
4) Minimal exception safety also known as no-leak guarantee: Partial execution of failed operations may store invalid data but will not cause a crash, and no resources get leaked.
5) No exception safety: No guarantees are made. (Worst level of exception safety)
Regards
Andreas_______________________________________________
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