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: Bill Bumgarner <email@hidden>
- Date: Mon, 15 May 2006 19:35:49 -0700
On May 15, 2006, at 7: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...
"Bad access exception" definitely means that something bad has
already happened -- the stack is corrupted, the heap is corrupted,
the program wrote to beyond the end of a buffer (more heap
corruption), or the like.
This is not a runtime exception per se. It is lower level; it can
happen in a pure assembly language app and, as John Stiles said, the
damage has already been done and there is no real way to recover.
Even if you could validate all the data managed by your app (a very
very hard task), there is no way to validate data structures
maintained by the Foundation, AppKit or other frameworks-- their
structure is opaque.
Now, none of this is to say that solving the problems you define
above is impossible. It isn't, you just have to approach it from a
"prevent the bad access exception" frame of mind. Or, if you can't
prevent it, then log enough information somewhere such that the
situation can be avoided in future sessions.
For example, if your application is crashing because it is reading a
corrupt file, then whatever parser you are using to read the file is
not robust enough for your application's needs. This may be due to
a bug in the parser or it may be because the parser was not designed
to operate in a fail safe mode (which often requires significantly
more CPU and memory than operating in a "hope the data is OK" mode).
If you can't fix the parser (or, as is the case here, you are in
development mode and are shaking out bugs), then you can make the app
store the name of the last file parsed somewhere persistent -- ~/
Library/Application Support/ or /tmp/ or the user defaults
database. Once everything is successfully parsed, store the
success. Upon initiating a new parse session, check the stored
value and see if the app died without success. More likely than
not, the problematic file will be the last one.
There is the off chance that a corrupted file might cause corruption
in the heap/stack without actually crashing your app. It may be that
the last file in the parse log is actually not corrupt and that a
previous file is actually the cause of the problem.
If at all possible, make your parser robust. If not possible, move
the parser out to an external task that you can monitor from your
app. That way, if the parser crashes, you can easily offer recovery
options from the sane working conditions within your uncrashed and
isolated application's runtime.
b.bum
_______________________________________________
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