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