3 ms·
I think an approximation to this in C++ would be to have some thread-local objects called condition handlers that you set using some RAII construct (so, somethi
by kmill 5y ago
I think an approximation to this in C++ would be to have some thread-local objects called condition handlers that you set using some RAII construct (so, something that will replace the current condition handler and then later restore it when you leave the current scope), and then when some function experiences an exceptional circumstance, it calls some methods on the appropriate condition handler object. The condition handler is free to throw an exception itself if it wants to destructively unwind the stack, but it can also do other things.
It's through these condition handler objects that the caller can bidirectionally communicate with callees before they return.
In other words, it's like the visitor pattern, but rather than passing the visitor directly you do so through a thread-local variable, and also these visitors are designed to be composable.
A more modern version of this, straight from the ivory tower, are effects handlers, which I expect we'll see in more languages as time goes on. The cool thing about effects handlers is that they make it easier to reason about all these nonlocal effects due to some well-thought-out restrictions. They also have some good compositionality properties, and they appear to be able to be compiled down to code that doesn't need special runtime support (beyond what functional programming languages already provide). The example I'm somewhat familiar with is Koka: https://koka-lang.github.io/koka/doc/book.html#sec-handlers https://koka-lang.github.io/koka/doc/book.html#sec-handlers