Re: More Mac like handling of OS raised exceptions
Re: More Mac like handling of OS raised exceptions
- Subject: Re: More Mac like handling of OS raised exceptions
- From: Greg Hurrell <email@hidden>
- Date: Tue, 16 May 2006 04:52:44 +0200
El 16/05/2006, a las 3:43, Lon Giese escribió:
this does nothing but crash the program! - handler is not called
NS_DURING
// OS raised exception
NSObject *noGoodObject = (NSObject *)3;
Class aClass = [noGoodObject class]; // bad access exception
is raised
NS_HANDLER
NSRunAlertPanel(@"Error Panel", @"%@", @"OK", nil, nil,
localException);
NS_ENDHANDLER
Technically this is not an exception. Exceptions are programmer
errors where the program says, "I didn't expect that to happen! I am
going to abort..." Exceptions are raised whenever a programmer
(either you, or another programmer in one of the frameworks you are
using) makes an assertion saying "I expect these conditions to be
true", and it turns out that they are not true... As you know, such
exceptions can be "caught" and dealt with.
The bad access example you use above is another animal entirely: this
is not a programmer assertion. This is the kernel stepping in and
saying "this is a fatal error". The kernel communicates this to the
process by means of a signal. As others have pointed out, the only
way to handle these signals is to install a signal handler. In
general there isn't much you can do from a signal handler. When you
get a SIGBUS or SIGSEGV signal it really is a crashing error, and
although you can catch the signal the truth is that you can't expect
to reliably recover fully from such errors. The only way to truly
avoid these errors (and make your app more "Mac-like" as you say) is
to eliminate the bugs that cause them.
Cheers,
Greg
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden