Re: [AD] 4.3 error handling

[Elias Pschernig <elias@xxxxxxxxxx>]

On Wed, 2006-06-07 at 20:09 -0700, Chris wrote:
> On Wednesday 07 June 2006 19:36, Jon Rafkind wrote:
> > As an alternative what
> > about adding the return code to an accumulator and checking if that is
> > non-zero at the end of some block of code. If its non-zero, an error
> > occurred.
> 
> That's even uglier. And you're not acocunting the create functions (which will 
> return NULL on failure or a valid object on success). The idea is to let the 
> user deal with the errors if they want, or to let them whip code together 
> quickly that'll properly abort with a useful message when there's a problem 
> (and since abort raises a SIGABRT, a debugger can properly catch it and 
> backtrace uncaught errors, not catch a SIGSEGV several lines later that may 
> be no where near the source of the error).
> 
> > This would only work if subsequent lines of code wouldnt crash 
> > the program if the previous lines failed for whatever reason.
> 
> That's it, too. Just about everything in that code snippet would prevent the 
> rest of the code in the try block from working. You'd have to resort to 
> checking each and every function, still.

Checking each function really isn't so bad though. Personally, something
like this:

int my_init(void)
{
    
    if(!al_audio_init()) goto error;

    if(!mixer_init()) goto error;

    voice = al_voice_init();
    if (!voice) goto error;

    printf("Initialization ok!\n");
    return 0;

error:
    printf("Error: %s\n", al_get_error());
    return -1;
}

- just simple C code, without any #defines or hacks, looks just as clean
as a try{} catch{} block. If you don't want gotos, you could use a
while(1) and break statements. Still, the code flow is as clear as with
try/catch in both cases. And, for C coders, maybe even clearer.

> >     - C++ users can as well use a proper C++ wrapper, which can use
> > real exceptions.
> 
> I don't see why this is a con. The code doesn't interfere with this
> (if anything, it makes it easier).

It wouldn't make it significantly easier - but my point is, the try{}
catch{} would mostly be liked by C++ users and not by C users, and C++
users would be served much better with a complete C++ wrapper. Which
then of course would throw exceptions on errors :)

-- 
Elias Pschernig