Re: [AD] 4.3 error handling

[Chris <chris.kcat@xxxxxxxxxx>]

On Thursday 08 June 2006 18:07, Peter Wang wrote:
> If you think setjmp/longjmp don't have many gotchas, I'd tend to think
> you've not used them much.

Honestly, no, I haven't. I have used them in APEG though, where I set a setjmp 
point at the beginning of the processing functions and have the processing 
code (which can be several function calls deep in speed-sensitive code) jump 
back to that, and properly return with an error. I've not had any problems 
with it.

> > And I'd say it makes user code much simpler. Having to check return
> > values makes it much harder because you gotta know which ones can error,
> > what the failure value is,
>
> I have nothing against making return values consistent.

Not always possible. Imagine a function that returns an unsigned number, and 
everything in between, including 0 and ~0, is a valid return. What would 
indicate an error? Sure, you could check the al_error() value (assuming you 
properly cleared it before hand), but TLS access is comparitively slow, which 
would be no good for speed-sensiive code. With setjmp/longjmp you only need 
to access the TLS once to set a setjmp point outside of the speed sensitive 
code, and the TLS variables never need to be touched until there's an error 
and longjmp reads it to jump back (where speed isn't as much of a concern 
anymore).

> > Given that, the question shouldn't be "why use it?", it should be "why
> > not use it?", IMO. I'm willing to believe there could be a problem with
> > this method, which is why I brought it up for discussion and have been
> > trying to get many opiinions on it, but so far, the only real problem
> > cases brought up are caused by user error.
>
> You might say the same of users not checking return values.

Most of the time, yes. But there are plenty of cases where you may not want to 
check return values, mainly for speed reasons.

> > This helps newbies by providing nicer information for uncaught errors (no
> > more 'why is Windows closing my program and saying "the address can't
> > be 'read'"?'), it helps users that like it by allowing them to use a
> > familiar method, and with both of that, it still allows you to use the
> > method of checking return values, if you wish.
>
> I can't believe you think longjmping is more familiar or easier for
> newbies.

longjmp'ing itself my not be, but a newbie doesn't have to know about it to 
get Allegro to catch an error for them (and in fact you can't have a setjmp 
point set for Allegro to automatically catch it for you). And with the way 
it's presented through the try/catch macros, it does help clear some of the 
potential problems someone would face using setjmp/longjmp directly.

> It's the rare cases that need the most thought.  Avoiding problems due
> to "sloppy coding" by not encouraging them in the first place is part of
> good design.

I'm not sure what you mean here. Are you saying it should be okay for a user 
to make sloppy code because we should take care of it for them?