Older interpreters, such as ITF, are extremely curt when an error condition is reached (for example, an illegal opcode). It was assumed that Infocom's shipped story files were bug-free, which is mostly true, so that errors could only arise through a bug elsewhere in the interpreter.
In debugging Inform games, though, many error conditions can arise and it is extremely helpful to report these as fully as possible. These include:
As mentioned in S 3, it's helpful to screen out any illegal ZSCII characters between 0 and 31 which are accidentally printed: crashes can be very mysterious when they cause interpreters to send control codes to the terminal.
In addition, an interpreter might provide options for keeping track of maximum stack usage and the typical number of opcodes executed between each read from the keyboard. (But watching these is a time-wasting activity, so they should be options.)
Finally, infinite loops fairly often happen, as in any programming language. On a system without pre-emptive multi-tasking, this may lock up the whole machine, as the usual way that porters implement multi-tasking is to return control to the host operating system only when the keyboard is read. This can be avoided by providing a point in the code which could return control to the OS from time to time (say, every 2000 instructions).
A number of post-Infocom games have been released which contain errors, most often trying to perform illegal operations on object 0. Many interpreters silently ignored these errors, which can make it very to notice and track down bugs.
It is desirable for modern interpreters to be able to notify players about these bugs, but this can also ruin gameplay. It is highly recommended, then, that interpreters have four levels of error checking, selectable by the user (through a command-line or menu option, or similar):
Contents / Preface / Overview
Section 1 / 2 / 3 / 4 / 5 / 6 / 7 / 8 / 9 / 10 / 11 / 12 / 13 / 14 / 15 / 16
Appendix A / B / C / D / E / F