Improving Information Gain from Fatal Exceptions

Observations

• During testing, especially during open beta, fatals and asserts are common mechanisms for catching bugs. Because the programmer does not have the luxury of witnessing each crash it is important that the error messages reported by the fatal system are informative and helpful for the programmer looking at the bug postmortem.
• Typical assert messages report only the assert command with the file and line numbers. Ideally, the message would report a stack trace and other important memory dumps.
• During beta testing, it is reasonable to release _DEBUG versions of the product which contain debugging symbols. It is possible to parse this information on the fly during an assert (without a debugger) and generate a symbolic stack trace.
• External playtesters during open beta are often tempted to ignore problems and crashes under the theory that "someone else will report it" or because they think that one crash is like any other. Thus, it is highly desirable that the application make it very convenient to send a crash report.
• Open betas generate many hundreds of duplicate bugs. It would be nice if assert reports both generated enough information to be helpful while still being consistent enough to enable automated redundancy sorting.

Proposal

• We should standardize on a fatal system which includes the ability to generate symbolic stack traces.
• The dialog box should allow the player to send the bug report to an email system with one click if possible. The dialog box should include an edit area for the player to add a description of what happened.
• The dialog box should be easy to integrate into existing code and be easily translated into foreign languages.

Technical Details

• I have written a implementation of this proposal and posted it on my web page: http://www.mine-control.com/zack under the title "zassert"
• The following is a screen shot from the assertion code at the above address.