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: Lon Giese <email@hidden>
- Date: Mon, 15 May 2006 19:16:35 -0700
For what I am doing nothing is getting corrupted. The bad access
exception prevented that. I don't think signal handlers will help me
either, thats low level stuff, when I need high level information about
why the app tried to write to protected space. I have users all over
the world and to simply call and tell me the app crashed is not good
enough... When the app opens a certain file it crashes, but when the
app is opening thousands of files automatically I need to know which
file made it crash, and let the app continue on, skipping over the
unlucky file. I suppose I could log to disk every file that it attempts
to open but thats wacky, were talking thousands of files. I know it's
my fault the app is crashing, but were talking an alpha release and
still working out the bugs. Even so, there are literally hundreds of
different types of files my app opens and new types being created daily
by hackers. There should/must be a way to handle this type of exception
in a more Mac like way...
On May 15, 2006, at 6:49 PM, John Stiles wrote:
You need to look into signal handlers. Crashes like "reading a bad
pointer" or "writing into unallocated memory" aren't handled by the
Cocoa infrastructure—nor should they be. I doubt you will find
something which does what you want. Once an app has corrupted its
heap, overrun its stack, or done some other crash-inducing thing,
there is often very little you can do to recover gracefully.
On May 15, 2006, at 6:43 PM, Lon Giese wrote:
Any exception handling experts on the List? I would really appreciate
any help
I am trying to make the mac more mac like... When the OS generates an
exception it simply crashes the program. That's not good enough.
I have scoured the documentation and the archives and still confused
how to catch the "uncaught exceptions". I want to handle the
exceptions BEFORE they become "uncaught exceptions". This seems like
it should be pretty basic stuff, and not be so mysterious.
it seems that OS raised exceptions are handled totally differently
than an exception raised manually with NSException, but How?
This is not what I want - I want to handle the exception:
Setting NSExceptionHandlingMask causes the application to optionally
(a) print a descriptive log and a stack trace to the console when
such an error occurs, or (b) handle the error in such a way as to
prevent the resulting abrupt termination, or both. The mask is
constructed by summing values corresponding to the types of errors to
be logged or handled:
and I don't want the thread TERMINATED:
System-level exceptions and runtime errors are handled by converting
them into NSExceptions. NSExceptions generated in this manner contain
a stack trace in their userInfo under the key NSStackTraceKey.
Uncaught NSExceptions are handled by terminating the thread in which
they occur. NSExceptions in an application's main thread are caught
by NSApplication's top-level handlers.
This works perfectly, and ideally, just what I want: the handler is
called and control is passed back to the calling method. -
IF I raise the exception myself!
NS_DURING
// manually raised exception
[NSException raise:@"myException" format:@"This is an manually
raised exception"];
NS_HANDLER
NSRunAlertPanel(@"Error Panel", @"%@", @"OK", nil, nil,
localException);
NS_ENDHANDLER
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
Adding the following 3 lines is no help either - the bad access
exception totally ignores all three handlers
the manually raised exception calls all the handlers - including the
two delegate handlers.
Calling delegate handlers is not ideal either - it a generic way of
handling exceptions - much better for my needs to handle the
exception in the method it occurred in.
(the docs say this should handle "uncaught exceptions")
NSExceptionHandler *defaultExceptionHandler = [NSExceptionHandler
defaultExceptionHandler];
[defaultExceptionHandler
setExceptionHandlingMask:NSLogAndHandleEveryExceptionMask];
[defaultExceptionHandler setDelegate:self];
NS_DURING
NSObject *noGoodObject = (NSObject *)3;
Class aClass = [noGoodObject class]; // bad access exception is
raised
NS_HANDLER
NSRunAlertPanel(@"Error Panel", @"%@", @"OK", nil, nil,
localException);
NS_ENDHANDLER
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
This email sent to email@hidden
_______________________________________________
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