Re: [AD] 4.3 error handling redux

[Peter Wang <tjaden@xxxxxxxxxx>]

On 2006-07-25, Chris <chris.kcat@xxxxxxxxxx> wrote:
> Here's another attempt at an error handling API. Since setjmp/longjmp won't 
> work, and I can't think of any other method to jump out of a user-defined 
> block, I just went with callbacks. It comes with three callbacks, 
> AL_ERROR_ABORT (default), AL_ERROR_WARN, and AL_ERROR_IGNORE. The user can 
> supply their own handler if they wish, and use the function 
> al_error_set_handler (any consensus on function name conventions yet?). 
> al_error is used to retrieve the last error code, along with optionally 
> grabbing a descriptive string of the problem. Getting the error with that 
> function will clear it. al_error_set is exposed because some user error 
> handlers and/or addons may want to check the error themselves, before passing 
> it back down to user code.

Does this mean that if I don't want to use any fancy callbacks, I call
al_error_set_handler(AL_ERROR_IGNORE) at the start of the program and
check every function call with al_error()?  Would the error code get
cleared if the function succeeds, or is it left untouched?


As for naming, I would go for:

    al_set_error()
    al_set_error_handler()
    al_get_error()

For the enumerations:

    AL_ERROR_OK,
    AL_ERROR_INVALID_PARAM,
    AL_ERROR_INVALID_OBJECT,
    ...
    (goes like AL_EVENT_*, AL_KEY_*, AL_KEYMOD_*, etc.)

I would have two versions of al_get_error(): one that returns a code
only, and one that returns the string also.

AL_ERROR_OK (or AL_ERROR_NONE) should be defined in the documentation as
zero so users can depend on it.

Peter