Re: [AD] 4.3 error handling

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


On 2006-06-07, Chris <chris.kcat@xxxxxxxxxx> wrote:
> On Wednesday 07 June 2006 17:14, Peter Wang wrote:
> > On 2006-06-05, Chris <chris.kcat@xxxxxxxxxx> wrote:
> > > There's many times I wish I could just execute a string of commands and
> > > not have to check the return code of each one individually.
> >
> > Then you should use another language.  Please, keep it out of a C
> > library.
> 
> Surely I'd keep it to C++ if I could, but this won't work if Allegro itself 
> isn't C++:
> 
> try {
>    al_init();
> 
>    try {
>       al_more_code();
>    }
>    catch(AL_ERROR err) {
>       foo();
>    }
> }
> catch(AL_ERROR err) {
>    bar();
> }

That's just what you get for using a C library.

> > Imagine if every API reinvented its own (inferior) exceptions. 
> > Even if they all make it optional, it's a total mess.
> 
> If it's optional, you don't have to use it. It wouldn't effect your code at 
> all.

But I still need to think about it and it looks like a mess.

> (To note, I'm not saying this should move to C++. I'm just saying don't be 
> surprised when people start trying out clever "tricks" to get added 
> functionality. And when such "tricks" work, I don't really see a problem with 
> using them)

If people want to pull tricks in their own applications, fine, but
enshrining such tricks in an API is not a good idea.

Possibly a better error handling strategy to follow would be the cairo
API, which seems to be quite well designed for both C and language
bindings: http://www.cairographics.org/manual/bindings-errors.html
I don't know how nice it is in practice.

Peter





Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/