From error-handling to structured concurrency

https://lobste.rs/rss Hits: 23
Summary

How should we think about error-handling in concurrent programs? In single-threaded programs, we’ve mostly converged on a standard pattern, with a diverse zoo of implementations and concrete patterns. When an error occurs, it is propagated up the stack until we find a stack frame which is prepared to handle it. As we do so, we unwind the stack frames in-order, giving each frame the opportunity to clean up or destroy resources as appropriate. This pattern clearly describes the explicit exception-handling mechanisms in many modern languages (C++, Python, Java), all of which also have mechanisms for cleanup on frame unwind (RAII, finally blocks, Python context managers). But it also describes the standard pattern in Rust (Result returns, the ? operator, and calling drop on unwind), as well as Go (the classic if err != nil { return err } pattern and defer for cleanup), and even most modern C code, via patterns like goto error pattern (c.f. examples in the Linux kernel). From today’s vantage, that description may seem so general as to be contentless, but that has not always been so. Some other (mostly-abandoned) error-handling approaches include Lisp’s “restarts” mechanism, longjmp in C, “trap” mechanisms like UNIX signals, and the infamous on error clause in Visual Basic. “Unwinding” is also predicated on having a structured call stack, a concept which also had to be invented and popularized. Today I want to ask: how should we update this pattern for concurrent programs, where there is no single stack? How do we organize our code to handle error conditions, in the presence of multiple concurrent tasks? Unhandled errors 🔗︎ Perhaps the simplest case for error-handling is when an error arises, and no code explicitly handles it. In a single-threaded program, we expect the error to “bubble up” to the entrypoint, and terminate the program, hopefully with a useful error message and/or stack trace. In concurrent program with multiple tasks, it’s less obvious what should happen....

First seen: 2026-03-23 17:08

Last seen: 2026-03-24 15:31