Game State Management - Building JavaScript Games for Phones, Tablets, and Desktop - page 264

You do this because otherwise, the user of the game-state manager could accidentally access the
array outside its range. However, the way you do it here probably isn't the most robust approach.
For one thing, when the index is too large or too small, you return null . This means the code using
this method needs to be aware that the method might return null . As a result, that same code has
to check this in an if instruction, to make sure you aren't trying to call a method on a null reference.
Another problem is that you don't avoid all array out-of-range mistakes this way. For example:
var oops = GameStateManager.get(3.4);
Of course, arrays can only be accessed using integer values, so if you don't handle passing
non-integer numbers, the program will crash. This can be avoided by accessing the array as follows:
return this._gameStates[Math.floor(id)];
But is this really what you want? If a user tries to access element 3.4 in the array (which obviously
doesn't exist), do you want to return an object, meaning you pretend the object at index 3.4 exists?
Perhaps it's better to let the user know that this isn't possible, and stop the execution of the method.
There are other examples of situations that merit a proper way to handle errors. Sometimes these
situations occur not because of a bug in the program, but because something happened that is out
of the programmer's control. For example, perhaps the player of your game has the excellent idea
to disable the network adapter during the setup of an online game. Or, because of a virus wreaking
havoc on the server, some files that you expected to be there are corrupted. If you depend on
software developed by other companies, a new release could break your code because specs have
been changed. There are several ways to deal with these types of errors. One way is to do nothing
and let the program crash. This is a cheap solution for the game developer (initially, at least), but it
doesn't result in a very robust, user-friendly game. You could also maintain a list of error codes. If an
error occurs, the method would then return this error code, and the user would need to sift through
a large document detailing each error code and how to solve it. Yet another way is to not report the
error at all and try to work around it in the program. Although this sometimes is a good solution, in
many cases you simply can't work around an error. For example, if the network connection suddenly
is lost in a mass multiplayer online game, there isn't much you can do but report this to the player.
Most applications, including games, deal with errors by using exceptions . An exception is thrown
by a method, and the caller of the method has to deal with it. For example, look at the following
method definition:
GameStateManager_Singleton.prototype.get = function (id) {
if (id < 0 || id >=this._gameStates.length)
throw "game state id out of range";
else if (Math.floor(id) !== id)
throw "game state id should be an integer number";
else
return this._gameStates[id];
};