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: John Pannell <email@hidden>
- Date: Mon, 15 May 2006 20:31:09 -0600
Hi Lon-
I think John was right on - once memory has been handled badly,
nothing can be counted on to work reliably, including a solution to
handle bad memory access.
It sounds like you might like the stack trace of crashes from your
users... you might be interested in Uli Kusterer's UKCrashReporter...
http://www.zathras.de/angelweb/sourcecode.htm#UKCrashReporter
Also, you might post to the list some snippet of your file opening/
reading code; perhaps someone will see your crasher plain as day (as
often happens to me when I post code :-).
Good luck! With new files being created each day by hackers,
whatever you are doing sounds fraught with danger!
John
On May 15, 2006, at 8:16 PM, Lon Giese wrote:
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:
40blizzard.com
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:
40positivespinmedia.com
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