meeting log January 30, 2001

[linas@linas.org]

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.