Assertion Errors

About Asserts

An “assertion” in programmer jargon refers to a debug command that alerts the tester of a program that something is wrong. In most cases, an assertion is not an error message but a warning shot, an early indication that there is a bug in the code. Therefore, most assertions in most programs are debugging tools.

However, Dromed is an in-house level editor. Because of this, making a clear distinction between programmer errors and user errors was overkill. For Looking Glass, this was a non-issue; a programmer was always available in the next room. But the fan is left out in the cold without a coat. In practice, most of the assertions you will ever see in Dromed are error messages rather than bug alerts on steroids; to paraphrase Mahk, Dromed ain’t buggy, but as a software program it’s a piece of s–t. Being a fan puts you in the perplexing position of having to decipher these error messages, an endeavor complicated beyond description by the dispersal of Looking Glass across the four winds. Let’s see if we can’t help ourselves.

Handling Asserts

If you’re a programmer, you already know how to handle an assertion error. All I have to say to you in that case is as follows: don’t be afraid of the debugger. I repeat: the debugger is your friend. You must be keenly aware of how to use the second option on assert dialog boxes to find out what the problem is, research it, and avoid causing it in the future. Trust me when I say that you’ll reduce the number of crashes significantly if you research assertions properly.

If you aren’t a programmer, my first piece of advice to you is that you browse the OFFICIAL DOCUMENTATION. Do it now, because the amount of insight it will provide you cannot be equaled by any other single piece of information about Dromed. Simply put, the reason for this is that the authors of the official documentation had access to the source code and (arguably, more importantly) to the programmers. Nothing will beat that.

Once you have read the documentation, and, hopefully, reduced the amount of unfamiliar errors significantly, all that remains is to understand how to control an Assertion before your level becomes ice after the ice age. The first thing you want to do is get a debugger. Microsoft’s WINDBG is one that you could definitely handle, but if WinDbg doesn’t exist for your version of Windows, you will want to get another debugger; NUMEGA’S tools are widely acclaimed. Install it. I will not be teaching you assembly, so it doesn’t much matter which debugger you get, as long as the one you do can display assembly code and export some important symbolic information that you can then pass on to programmers.

There are two flavors of assertion failures. The first one, conventional in the circles of software development, is the more difficult to decipher. You are provided with three pieces of information: the source code file name, the line number, and the programming expression which failed. When you encounter this error, immediately select “Retry.” Windows 98 will display the “illegal operation” dialog box and Windows 2000 will display the “unhandled exception” dialog box. In the former, click “Debug”; in the latter, click “Cancel”. Your debugger will load. Copy the instructions below for your reference and follow my lead closely.

1. Find a way to show the call-stack window in your debugger. If you can’t find it in the View menu, open the help file and search for ‘opening the call stack’.
2. When the call stack window is on your screen, it will contain a list of names in a format similar to “DROMED!FunctionName(…)”. The one at the top will undoubtedly be “KERNEL32!DebugBreak”. Under it will be “DROMED!CriticalMessage”. Copy the whole call stack into the clipboard and save it.
3. Add a thorough description of what led to the error to the bottom of the call stack and post the information on the forum.
4. Find the “Run” command in the debugger and see if you can continue without crashing. Note whether you can or can’t in your report. Be warned: if you crash, the debugger will activate automatically. Simply select the ‘Stop Debugging’ command to break out of the program.

After you post informaiton about the assertion on the forum, we may have enough to reproduce the error and recognize it, and you’ll be doing yourself and everyone else a big favor.

The other kind of assertion you will encounter is the error-message assertion. Those assertions are usually not worth debugging. Record relevant information and read the error message carefully. Then, click “Cancel” and cross your fingers hoping that you have made the right choice. It’s the best one, to be sure. Next try, make sure you take a different path to avoid the assertion. If it pops up anyway, it’s probably your end, not your means, that’s suspect.

Conclusion

Assertions are a bitch. Out of an otherwise tolerable user interface, they stand out as a definite and indisputable quirk. But if you are to ride this camel, it would be wise to become familiar with them. Please send all inquiries about assertions and debugging Dromed to ME.


About this entry