views:

59

answers:

1

One of the crash reporter frameworks I've found does it like this: If there exist crash reports in the ~/Library/Logs/CrashReporter folder for the app, it determines that a crash occurred before. Then it allows the user to send the developer the crash log. And the finally, it deletes those logs.

It is this deletion that is bothering me. It's not acceptable to me. Maybe the user wants to look at those logs later. It is simply rude to the user to just delete his crash logs.

So I'm looking for a better way to determine the crash.

It doesn't really work to store the last read crash logs in the user defaults or the user data, because that would mean that if the user deletes the data and defaults (which he has a right to do whenever he or she wishes), and then launches the app, it will be detected as crashed the last time it was quit. So this doesn't work.

Any ideas?

+1  A: 

Write to a file every time you exit. Read that file every time you open the program. Write a specific integer to the file every time the program is exited that is read every time the program is started.

For example if a 0 is written to a file that may signify a non-crash. Anything else signifies a crash.

Hmm? And where would I write this file? Are you sure the app gets sent willQuit or such notification methods before it *crashes*? And even if it did, does any of these willQuit methods actually have a parameter saying that the app is crashing or not crashing?
Enchilada
Oooh, I think I get you. You mean just put a SuccessfulQuit in the user defaults, that is always set to 1 on successful quit, is 0 by default, and gets set to -1 after the app finishes launching. And then if it is actually -1 upon launching it means that I must have crashed. Something like that?
Enchilada
Yes, and reading/writing the file in a location is up to you.
Yes, I was just thinking about putting it in the user defaults. No need for any extra file, if I'm understanding this correctly.
Enchilada