views:

95

answers:

5

If my program doesn't tear down correctly, the system becomes unstable. There is no workaround really. So, should my program crash and not tear down correctly, then I need to tell the user when he tries to run it again that the system was left in an unstable state. Is the right way to do this is to create a lock file when I start and delete it when I exit correctly. If I start and that file exists, then I know I crashes previously. Is this the right approach?

+2  A: 

Yes, yes it is.

John Kugelman
i agree but i would periodicly write to that file the programs current state or location for posibile recovery or detailed error message about where it crashed
Christopher Kelly
I just realized that if the program crashes but in the meantime there was a reboot, then I would need to disregard the lock file. Is there any way to know if the computer has been rebooted?
Memb
A: 

Just so you take it into account, but the lock file might not be deleted for circumstances independent of your app, .e.g. network error, file system error, o.s error.

So depending on your requirements, if it's absolutely critical to know if the current state is valid, you would probably need to determine the validity by examining all the dependant variables and states, instead of just relying on the lock file. Otherwise, it can be an easy way to monitor the exit status. Just don't rely on it to determine whether or not you should relaunch the missiles.

JRL
Good point. I think I will write a flag my settings file instead just to make life easier. Thanks
Memb
+3  A: 

Two things that may be useful:

  • The Application Recovery and Restart API can be used on Vista and Win7. You can specify a recovery function that the OS will call for you so the user will be notified
  • Create an unhandled exception filter where you can try to perform some of the really critical recovery should you experience a crash elsewhere. This will work on XP too. I've used this technique before to close drivers that otherwise would hang if not closed properly.
the_mandrill
+1  A: 

If your program crashed and the machine was rebooted, would things still be in an unstable state? If not, then a lock file is not the approach you wish to take since the file will still exist after rebooting. Try a solution using the global atom table.

// Test if the application has crashed since the last reboot
ATOM myAtom = GlobalFindAtom ("MySecretName");
if (myAtom != 0)
{
  // We crashed on last run, inform user and exit
  // ...
  exit (0);
}

// Create a global atom which will be destroyed only on clean termination
myAtom = GlobalAddAtom ("MySecretName");

// Run your main program here
// ...

// Clean termination, delete the atom
GlobalDeleteAtom (myAtom);
Stephen Nutt
A: 

Microsoft Word (PPT/Excel also) follow a similar approach. A hidden file is created when a document is opened in write mode and as soon as the application exits normally it is deleted. The file may have lot more info like auto-saving document every 'x' mins etc. but the point is that your point is valid :-)

Aayush Puri