I have not read the whole of this log yet. But the following caught my
eye, and I have to address dres' reservations:
An error stack is about as close as you can come to having exceptions in
C. Here's how it works. (This example uses macros, please pardon the
sin)
typedef enum { BadDog=23, ...} ErrType;
ErrType pop_error(void);
void push_error(ErrType);
void some_low_func (..)
{
if(something bad) { THROW (BadDog); }
}
void some_user_func(..)
{
TRY {
some_low_func();
}
CATCH {
case BadDog:
printf ("Bad Dog! Sit in the corner!!!\n");
break;
}
}
and the 'magic macros' that make this work:
#define THROW(ERR) { push_error(ERR); return; }
#define TRY /* no-op */
#define CATCH {ErrType e; while (e=pop_error()) { switch (e) {
I've got some parens matching problems here, and its a little
oversimplified, but its hopefully obvious now that C++/Java exceptions
are nothing more than an error stack with some syntatic sugar.
So dres: you said you wished for C exceptions?
--linas
> 16:19:14 <rlb> Linas has nearly convinced me that error stacks and error
>retrieval/pop func == good (as long as you're guaranteed to have thread-specific
>variables if/when you ever need to work right in a threaded envt).
> 16:19:39 <rlb> Anything else interesting up?
> 16:20:03 <dave_p> nothing from me
> 16:20:20 * dres wishes C had exceptions then we could do good error handling.
> 16:20:48 <rlb> dres: true, though the stack approach gets you much of what
>you need.
> 16:20:55 <dres> i don't like an error stack on principle, but i can see it
>being the best solution available.
> 16:21:17 <rlb> dres: as long as you have the thread-specific vars available
>for later, it's OK, I think.
> 16:21:24 <rlb> (as a general API).
> 16:22:04 <dres> it's not functional. it still requires you to return at least
>a true/false condition from all functions.
> 16:22:04 <rlb> dres: also it's potentially the most efficient option. opengl
>uses it for exactly that reason. You can try to draw a million polygons in a tight
>loop and then ask if anything went wrong at the end.
> 16:22:18 <dres> it separates the error from the occurence in unpredictable ways
> 16:22:25 <rlb> dres: keeps argument signatures smaller for those tight loops.
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
