There are always problems with software! They crash and/or do the things you say, when that was not what you wanted. Even in IF software. We want to avoid those problems as much as possible.

In a compiled environment (having a compiler to analyse the source code and convert that to something that the interpreter can run), there are five levels of problems to cater for. The goal with the Alan Langauge and its compiler has been that there should be very little chance that the *player* should get into trouble, whatever the problem is:

1. compiler bugs - errors in the implementation of the compiler causing it to run amoc, crash or generate erroneous output.
   This type will only affect authors, but also see type #2 below.
2. interpreter bugs - errors in the implementation of the interpreter causing it to run amoc or crash.
   This type will unfortunately hit the player, but there is very little to be done about that, except to avoid bugs. Alan comes with about 1200 automatic test cases for the compiler and interpreter that are run through every build, from very specialized tests to larger games. Even for snapshots, yes, actually every rebuild, they get run. This is a strong and fast safety net against introduction of bugs.
3. author coding errors - multiplying a string with a number, accessing attributes that don't exist, starting scripts for instances that are not actors, etc.
   The Alan language and its compiler is carefully designed to make this type of errors near to impossible. E.g. it does not allow you to add or multiply anything that is not known to be a number. It prohibits accessing attributes that it does not know exist. This is a basic design principle for the Alan language.
4. author logical errors - logical glitches, missed tests, printing wrong things, printing things where the player can't see them.
   The game might become illogical, unwinnable, bad and so on, but the player should not have the game crash on him, which, except for a few cases, is guaranteed to not happen.
5. player errors - unknown commands, words, restoring from non-existing files, running games that don't exist etc.
   This is a natural part of the communication between the game and the player, and should not really be considered 'errors'.

Types 1 and 2 are only caused by yours truly and they are, hopefully, very rare. I appreciate any reports on those. The more precise, the better. The perfect bug report is an short, succinct, and to the point, example with full source, a set of commands to exhibit the actual behaviour and a description of the expected behaviour. Preferably without the import of any external library. If possible. Such a bug report goes directly to the test suite to ensure it can never happen again. And of course also to my heart.