McEs, A Hacker Life: Throwing Exceptions with POSIX/ISO C

Saturday, April 01, 2006

Throwing Exceptions with POSIX/ISO C

After showing pass-by-reference in C, I've been thinking about how to do a clean implementation of exceptions in C.
So here is my POSIX/ISO C implementation of C++/Java/Python-style exceptions, written with glib flavour for taste. I couldn't get rid of the final g_try_end, and don't think can be got rid of. Leave comment if you can!

I plan to integrate this with glib after adding the thread-private stuff (-:.

/* header */

#include <glib.h>
#include <setjmp.h>

void g_exception_set_error (GError *err);
GError *g_exception_get_error (void);

void g_exception_set_jmp_buf (jmp_buf *jmpbuf);
jmp_buf *g_exception_get_jmp_buf (void);

G_GNUC_NORETURN void g_exception_throw (GError *err, int depth);

#define g_try_begin \
  { \
    int __g_except_depth; \
    jmp_buf __g_except_jmp_buf; \
    GError  *__g_except_error = NULL; \
    jmp_buf *__g_except_jmp_buf_save = g_exception_get_jmp_buf (); \
    g_exception_set_jmp_buf (&__g_except_jmp_buf); \
    if (!(__g_except_depth = setjmp(__g_except_jmp_buf)) || \
 (g_exception_set_jmp_buf (__g_except_jmp_buf_save), \
  __g_except_error = g_exception_get_error (), \
  FALSE)) \
      {

#define g_catch(Domain, Code, err) \
      } \
    else if ((!(Domain+0) || (Domain+0) == __g_except_error->domain) && \
      (!(  Code+0) || (  Code+0) == __g_except_error->code  )) \
      { \
 GError *err = __g_except_error;

#define g_try_end \
      } \
    else \
      g_raise; \
    g_exception_set_error (NULL); \
    g_exception_set_jmp_buf (__g_except_jmp_buf_save); \
  }

#define g_throw(err) \
  G_STMT_START { \
    GError *__g_except_throw_error = (err); \
    if (__g_except_throw_error) \
      g_exception_throw (__g_except_throw_error, 1); \
  } G_STMT_END

#define g_raise \
  G_STMT_START { \
    if (__g_except_error) \
      g_exception_throw (__g_except_error, __g_except_depth + 1); \
  } G_STMT_END



/* implementation */

static GError  *_g_except_error_current;
static jmp_buf *_g_except_jmp_buf_current;

void
g_exception_set_error (GError *err)
{
  if (_g_except_error_current)
    g_free (_g_except_error_current);
  _g_except_error_current = err;
}

GError *
g_exception_get_error (void)
{
  return _g_except_error_current;
}

void
g_exception_set_jmp_buf (jmp_buf *jmpbuf)
{
  _g_except_jmp_buf_current = jmpbuf;
}

jmp_buf *
g_exception_get_jmp_buf (void)
{
  return _g_except_jmp_buf_current;
}

void
g_exception_throw (GError *err, int depth)
{
  jmp_buf *target = g_exception_get_jmp_buf ();

  if (!target)
    g_error ("Uncaught exception (depth %d): %s", depth, err ? err->message : "(null)");

  g_exception_set_error (err);
  longjmp (*target, depth);
}



/* test case */

static void
my_read_file (const char *filename)
{
  GError *err = NULL;
  GIOChannel *stream;

  stream = g_io_channel_new_file (filename, "r", &err);
  g_throw (err);

  /* ... */

  g_io_channel_shutdown (stream, TRUE, &err);
  g_throw (err);
}

int
main (int argc, char **argv)
{
  g_try_begin {

    if (argc > 1)
      my_read_file (argv[1]);

  } g_catch (G_FILE_ERROR, G_FILE_ERROR_ACCES, e) {

    g_warning ("Oh oh: %s; ignoring", e->message);

  } g_catch (,, e) {

    g_message ("The message is: %s; chaining up", e->message);
    g_raise;

  } g_try_end

  return 0;
}

(the feed is probably broken again, check my blog page for syntax-highlighted source.)

¶ 4:43 AM

Comments:

Great Stuff - we reallt need stuff like this to improve the quality and robustness of our c code.

One potential showstopper is - is it compatible with high level languages? (IE if I call a gobject in say python or mono and it generates an exception, will they be able to handle it natively?

# posted by

Anonymous : April 01, 2006 5:23 AM

Since core glib doesn't throw any exceptions, it's up to application code to make sure the exceptions are correctly handled. The pygtk glue can for example do a g_try when passing control to native code and upon catching an exception, raise a similar Python exception, yes.

# posted by

behdad : April 01, 2006 5:35 AM

Will there be a try..finally construct too?

(or even better a try..catch..finally block like c# does)

# posted by

Anonymous : April 01, 2006 6:42 AM

I thought about it too. A try..finally is trivial. try..catch..finally gets hard in the case that you raise or throw in your catch block. It's not impossible, you just need to set another try around the catch blocks to trap throws and run the finally block. Will look into it.

# posted by

behdad : April 01, 2006 6:45 AM

Ok, added a simple g_finally support. It works as try..finally, and also as try..catch..finally as long as you don't raise or throw in the catch blocks. The linked code is the latest version.

# posted by

behdad : April 01, 2006 7:03 AM

Nice work behdad, but I can't stop making a few comments:

first of all, why not add a cleanup stack to this scheme to avoid leaking memory and resources when an exception is thrown ?. Yes, of course, this is a shameless plug to my paper on the subject :-)

second, the implementation doesn't work in multi-threaded contexts. I assume that you know that, but the "global" values in the implementation should really be thread-local.

finally, I have a bit of experience with using such a scheme in real (i.e. big and complex) code, even though it's not something I'm going to release. All I can say is that your *biggest* issue is that developers *will* constantly need to know wether a function might throw or not.

Iv tried many schemes, and now believe that the simplest way to do that is to use a naming convention (e.g. like the one used in EPOC). Personally, I use a capital X at the end of any function that may throw, as in:

g_mallocX, g_array_appendX, etc...

same goes with callback type declarations, and macros (suffixed with _X, as in G_DO_STUFF_X)

it doesn't look very nice at first, but it's something you'll get used to very quickly, and it beats having to read the documentation everytime you're unsure about what a given function does (which means every 5 minutes, if you're like me).

Hope this helps.

# posted by

Anonymous : April 01, 2006 8:05 AM

Haven't you seen CEXCEPT, Behdad?

http://cexcept.sourceforge.net/

# posted by

Anonymous : April 01, 2006 8:19 AM

You may also want to check out David Turners
paper on exception handling in C:
http://turnerdavid.neuf.fr/papers/reliable-c.html

# posted by

Anonymous : April 01, 2006 10:05 AM

See also the C exceptions that were part of DEC's (and I think also HP's) DCE pthreads. The package name was CMA (Common Multithread Architecture).

There's a lot of serious quality prior art here.

# posted by

Anonymous : June 06, 2006 11:20 PM

About Me

Twitter Updates