Skip to main content

Simplest Exceptions Handler Macros for C

More adventures in C, I revisited my exception handler implementation libex. I realized there's an even simpler version that's more efficient if we give up the requirement that exceptions can be propagated to callers:

#define TRY
#define THROW(E) goto E
#define CATCH(E) goto FINALLY_H; E:

This implementation requires only a single exception handling block per function, which is probably good idea as a general rule. Usage looks like:

static void foo(size_t sz) {
  char* x;
  TRY {
    x = (char*)malloc(sz);
    if (x == NULL) THROW(ENoMem);
    // do something with x
  } CATCH(ENoMem) {
    // handle out of memory
    if (x != NULL) free(x);

Unlike libex, this version is actually compatible with break and continue, although using them runs the risk of skipping the FINALLY handler. An almost equally simple version of exception handlers which ensures that break/continue cannot skip the FINALLY block wraps everything in a loop:

#define TRY do {
#define THROW(E) goto E
#define CATCH(E) goto FINALLY_H; E:
#define FINALLY } while(0); FINALLY_H:

This ensures that any break or continue statements executed within the TRY or CATCH blocks immediately exit to the FINALLY handler.

Of course, abort() and exit() invocations will also bypass FINALLY, so if you intend to use these macros, I suggest using them only as a way to organize your code in a more structured fashion.


Popular posts from this blog

Software Transactional Memory in Pure C#

Concurrent programming is a very difficult problem to tackle. The fundamental issue is that manual locking is not composable , which is to say that if you have two concurrent programs P0 and P1 free of deadlocks, livelocks and other concurrency hazards, and you try to compose P0 and P1 to create a program P2, P2 may not be free of concurrency hazards. For instance, if P0 and P1 take two locks in different orders, then P2 will deadlock. Needless to say, this is a serious problem because composition is the cornerstone of all programming. I've been toying with some ideas for software transactional memory (STM) in C# ever since I started playing with FRP and reactive programming in general. The problem in all of these domains is fundamentally about how to handle concurrent updates to shared state, and how to reconcile multiple, possibly conflicting updates to said state. Rx.NET handles concurrency essentially by removing the identity inherent to shared state. An IObservable<T&g

async.h - asynchronous, stackless subroutines in C

The async/await idiom is becoming increasingly popular. The first widely used language to include it was C#, and it has now spread into JavaScript and Rust. Now C/C++ programmers don't have to feel left out, because async.h is a header-only library that brings async/await to C! Features: It's 100% portable C. It requires very little state (2 bytes). It's not dependent on an OS. It's a bit simpler to understand than protothreads because the async state is caller-saved rather than callee-saved. #include "async.h" struct async pt; struct timer timer; async example(struct async *pt) { async_begin(pt); while(1) { if(initiate_io()) { timer_start(&timer); await(io_completed() || timer_expired(&timer)); read_data(); } } async_end; } This library is basically a modified version of the idioms found in the Protothreads library by Adam Dunkels, so it's not truly ground bre

Why we are likely NOT living in a simulation

I typically keep this blog about computer science, but I also dabble in a bit of philosophy. I was initially struck by Bostrom's simulation argument when I first read it years ago. Over the years, I've cycled a few times between disputing what I believed were some of its assumptions, and cautious acceptance after realizing my mistake. The simulation argument in its simplest form is that one of the following must be true: simulations of humans can't be built, or simulations of humans won't be built, or we are almost certainly living in a simulation I think this argument is absolutely valid, so one of those outcomes is true. Claiming #3 is most likely is what's known as the simulation hypothesis , and has such proponents as Elon Musk. Sabine Hossenfelder recently argued against the simulation hypothesis by basically asserting that #1 above is plausible, but I actually think #2 is the most likely case. For reference, Bostrom calls future civilizations capable of r