Assertions getting corrupted

[Shachar Shemesh]

On 26/10/17 09:27, Jonathan M Davis wrote:
> since almost no one ever derives from Throwable,
> and I don't think it's really intended that anyone do so much as it is
> possible (and I'm not sure why you would)
Here's where we're doing it.

Our product will often have several fibers essentially working for one 
common sub-component. Trouble is, with our product being distributed the 
way it is, it might be possible to simply kill that subcomponent. When 
that happens, we want to kill all the fibers that belong to that 
subcomponent.

The solution is composed of several layers. First, we have a mechanism 
for injecting an exception into another fiber. This means that any 
function that may send a fiber to sleep, by definition, may also throw.

We also have a FiberGroup, where we can assign fibers to the group. This 
way, when the component goes down, we just kill the group, and it sends 
an exception to all fibers that kills them.

This leaves just one problem. What happens if someone catches that 
exception? We want all fibers to actually exit when we do that, and we 
rely on that happening. Obviously, this is not meant for malicious 
coders, so we /could/ mandate the following pattern:

catch(FiberGroupExit ex) {
   throw ex;
} catch(Exception ex) {
   ...
}

The problems with this pattern are huge. For one thing, you'd have to 
remember to put it anywhere you're catching an Exception. It's also 
quite verbose.

Another solution is to have every other exception inherit not from 
Exception, but from some subclass of it. Problem is, this does not 
include exceptions defined in phobos, libraries, and pretty much 
anything else. It's also quite easy to forget.

The solution we came up with was for FiberGroupExit to not inherit from 
Exception, but directly from Throwable. This means you can catch 
Exception as usual, but injecting a FiberGroupExit (or a ReactorExit) 
unconditionally terminates your fiber, while running all proper cleanups.

Running the cleanups is important, as the process remains running. It 
makes no sense for scope(exit) not to clean up merely because a fiber is 
quitting.

Hope this clears up a few things.

Shachar