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

You may also want to check out David Turnerspaper ...

2006-04-01T10:05:00.000-05:00

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

Haven't you seen CEXCEPT, Behdad?http://cexcept.so...

2006-04-01T08:19:00.000-05:00

Haven't you seen CEXCEPT, Behdad?

http://cexcept.sourceforge.net/

Nice work behdad, but I can't stop making a few co...

2006-04-01T08:05:00.000-05:00

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.

Ok, added a simple g_finally support. It works as...

2006-04-01T07:03:00.000-05:00

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.

I thought about it too. A try..finally is trivial...

2006-04-01T06:45:00.000-05:00

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.

Will there be a try..finally construct too?(or eve...

2006-04-01T06:42:00.000-05:00

Will there be a try..finally construct too?

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

This is awesome stuff, we need more of these GNOME...

2006-04-01T05:44:00.000-05:00

This is awesome stuff, we need more of these GNOME recipes on a centralized place, so new (and old) GNOME developers can learn the good habits from there.

Great work and keep them coming Behdad!

Since core glib doesn't throw any exceptions, it's...

2006-04-01T05:35:00.000-05:00

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.

Great Stuff - we reallt need stuff like this to im...

2006-04-01T05:23:00.000-05:00

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?