For Vista certification, is any handling of unanticipated errors prohibited (other than throwing them)?
Let's say an application has to process a large number of files. If an unanticipated error occurs when processing one of those files, I wouldn't want that to prevent the application from processing the rest of them. Could we report the error through WER, but also handle it?
Jason or others will probably comment on the "legal" aspects of the question, but I'll throw in some comments on technical aspects, hoping that they make some sense to you.
If you follow Microsoft's recommendations for handling crashes, an application is not expected to catch crashes itself; instead, it is supposed to delegate crash reporting to the OS. Also, the app can register itself for automatic restarts so that it can "restore" itself into some safe state before the crash. From a purely technical point of view, this makes a lot of sense since apps tend to become instable after a crash, so chances are you'll make things worse by trying to continue, instead of letting the app crash.
From a usability point of view, however, other approaches might actually be preferrable sometimes, such as the one you're describing. Whether or not your approach is at least somewhat safe, depends on the nature of crashes, and the impact which each of the files you're processing has on the global state of the application.
Let's assume a scenario where you read a file, parse it, build a per-file data structure in memory, and then produce some output on the disk using the parsed data structure. Only very few "global" data structures are changed in the process, and their integrity can be verified in case some unexpected crash occurs. In such a scenario, trying to catch, say, an access violation may actually be viable since your crash handler could remove the per-file data from memory or invalidate them, and check the integrity of the rest of your data before allowing the user to proceed.
We had a similar scenario; in our app, we automatically roll back to a previous state of the internal model when we detect a crash. This reduces the probability of data corruption when allowing the user to proceed after the crash (but doesn't eliminate it completely, of course).
Claus
Thanks for your comments, Claus.
The question was primarily about the legality of handling such errors in the context of Vista certification. However, I'd agree that we would always need to consider the potential negative consequences of doing so.
John
The following forum thread suggests we can handle unanticipated errors as long as WER is allowed to report them too:
http://forums.microsoft.com/msdn/showpost.aspx?postid=1029239&siteid=1&sb=0&d=1&at=7&ft=11&tf=0&pageid=0
Confirmation or otherwise would be appreciated.
Thanks.
Since an application may be in a corrupted state and may further corrupt the data that it is processing we do not recommend continuing after unexpected exceptions. You may want to automatically register the application for restart (RegisterApplicationRestart API) and continue the task that got interrupted before the crash. This approach may be more reliable from a application data validity point of view.
Thanks
Thanks, Kinshuman.
That still sounds like a recommendation rather than whether handling unanticipated errors is legal with respect to Vista certification.
Any other thoughts?
Hi John,
In respect to Vista Certification (I had a chat about this with Brad Sullivan who is the PM of that program) as long as you use WER, you can handle your own excpetions although it is not recommended.
I have asked Brad to comment in this forum on Logo Certification and the WER requirement since it is not a technical issue but rather a program specific question.
Kind Regards,
-Jason
