Re: [AD] 4.3 error handling

[Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx>]

On Thursday 08 June 2006 12:59 pm, Robert Ohannessian wrote:
> So, C "exceptions" using setjmp don't really work like C++ exceptions,
> have lots of gotchas, don't interoperate and (to make them work
> correctly) complicate the user code much more than just checking for
> return values.
>
> Why is this thread still alive?
>
> If you want Allegro to throw exceptions, write your own C++ wrapper that
> checks for errors and throws.
>
> There is no value in adding fake exceptions to Allegro as long as
> Allegro still needs to function from C.

They arnt reallt exceptions. just imo, a handy way of handling errors. You 
argue, but provide no alternatives besides the crapy method we have now, of 
saying non -1 is an error, and you get to figure it out by yourself, and oh, 
make sure you clean up properly!

> > -----Original Message-----
> > From: alleg-developers-bounces@xxxxxxxxxx [mailto:alleg-
> > developers-bounces@xxxxxxxxxx] On Behalf Of Chris
> > Sent: Thursday, June 08, 2006 2:58 AM
> > To: alleg-developers@xxxxxxxxxx
> > Subject: Re: [AD] 4.3 error handling
> >
> > On Wednesday 07 June 2006 23:52, Peter Wang wrote:
> > > They are completely independent in my example, e.g. API1 = graphics
> > > library, API2 = network library.  The _user_ is using both
>
> libraries,
>
> > > but neither library knows or cares about the other.
> >
> > As they shouldn't. A graphics library wouldn't call network functions,
>
> and
>
> > vice versa. I don't see what the problem is. The graphics library
>
> would
>
> > jump
> > to its catch on error, and the network lib would jump to its catch on
> > error
> > (just like using C++, the libs would/should throw an object of a type
> > specific to their libraries). You just need to make sure that
>
> regardless
>
> > of
> > whichever one it jumps to, it cleans up all relevant code.
> >
> > eg:
> >
> > try1 {
> >    api1a();
> >    try2 {
> >       api2();
> >    }
> >    catch2 {
> >       api1_throw();
> >    }
> >    api1b();
> > }
> > catch1 {
> >    cleanup1();
> >    cleanup2();
> > }
> >
> > Or alternatively, disable API2's throwing and check its return value
> > manually
> > (something you can't do with C++ exceptions). Whichever you want.
> >
> > > If you really must, expose a setjmp/longjmp
> > > interface.  But do NOT try to make it look like a try-catch system
> > > because they are only superficially similar.
> >
> > The way I see it, 'al_catch' is pretty much 'catch(AL_ERROR err)' in
>
> C++;
>
> > just
> > without the implicit variable creation. It wouldn't catch anything
>
> other
>
> > than
> > an Allegro error, which can only be thrown with 'al_throw(err);'
>
> (which
>
> > would
> > be 'throw (AL_ERROR)err;'). As such, something like
> >
> > throw "foo"; /* a non-Allegro throw */
> >
> > would never be caught by
> >
> > catch(AL_ERROR err) /* al_catch */
> >
> > because it's not the same type. Just make it a point to note that
> > Allegro's
> > exceptions aren't C++ exceptions and can't catch them, and vice versa.
> >
> > But, as I said, I'll concede that trying to make it look like C++
> > try/catch
> > *may* be a bit too much. A less transparent method would be acceptable
>
> (as
>
> > long as it's not /too/ opaque :P). But the basic idea is a good one,
>
> IMO,
>
> > and
> > should be considered.
> >
> >
> > --
> > https://lists.sourceforge.net/lists/listinfo/alleg-developers
>
> ---------------------------------------------------------------------------
>-------- This email message is for the sole use of the intended recipient(s)
> and may contain confidential information.  Any unauthorized review, use,
> disclosure or distribution is prohibited.  If you are not the intended
> recipient, please contact the sender by reply email and destroy all copies
> of the original message.
> ---------------------------------------------------------------------------
>--------

-- 
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx