Error handling is of particular importance to game programming—or any programming, for that matter. It is important that the API in use is able to indicate where errors or other types of unstable events are occurring.
One nice feature that OpenAL and JOAL provide is a single method that returns an error state in the application. Whenever an application wants to make a check for an error, it makes a call to the al.alGetError() method. This method returns any of the valid error enumerations used for OpenAL when an error is discovered within the current rendering context. The current list of error messages that OpenAL and JOAL can return is shown in Table 4.4.
Error Name | Description |
---|---|
AL_NO_ERROR | There is not currently an error |
AL_INVALID_NAME | A bad name (ID) was passed to an OpenAL function |
AL_INVALID_ENUM | An invalid enum value was passed to an OpenAL function |
AL_INVALID_VALUE | An invalid value was passed to an OpenAL function |
AL_INVALID_OPERATION | The requested operation is not valid |
AL_OUT_OF_MEMORY | The requested operation resulted in OpenAL running out of memory |
These error enums can be used with the OpenAL defined AL_TRUE and AL_FALSE, which serve as direct Boolean enumerations. Most of the error messages are self-explanatory. An example of how the alGetError() method can be used to check the status when generating a Buffer follows:
al.alGenBuffers(1, buffer); if(al.alGetError() != AL.AL_NO_ERROR) return AL.AL_FALSE;
Good programs check for errors immediately after the creation of Buffers and Sources or loading audio data, as demonstrated in the previous code.
One other note—the most recently released version of JOAL also implements a new Exception class named the OpenALException that is designed to catch initialization errors regarding the AL and ALC objects. Creation of the Alut and ALC classes require the setting of try/catch blocks to initialize.