# Panic Room
This is a little experiment in non-unwind panic handling.
The idea is to bolt something like an arena on to sj/lj such that:
- You can compile with panic=abort but..
- Within a "room" it never actually gets to abort, it recovers
- You can allocate, take, borrow and mut-borrow stuff in the room
- Everything allocated gets destroyed on success _or_ panic-recover
- If that stuff has destructors they'll all run too, like normal
It's a sort of miniature semi-transaction, similar to catch-unwind, but without
any actual unwinding, just sj/lj. A strange mutant relative of SEH.
Considerations:
- I'm not actually sure there's a reason to connect memory allocation to
control this way. Maybe the two pieces should remain separate. I think it
is possibly convenient to entangle the arena stack, jmp_buf stack, panic
handlers and destructors all together, but I might be imagining it.
Limitations:
- Absent access to a single internal API, it can't reset the panic number, so
it will forever think it's still panicking. This is just a number in the
stdlib. It should be adjustable by people who want to take their life into
their own hands. Please send me a patch if you know how to access it.
- The "arena" isn't an arena at all, it's a vec-refcell-option-box-dyn-any
thing. Just enough to sketch the right API. If you wanted it to perform like
a real arena you'd need much more unsafe code I suspect. As it is I only use
unsafe on sj/lj.
- Everyone thinks sj/lj is fundamentally unsafe and horrible. Which, ok, sure,
but unwinding is almost as bad _and_ it generates tons more code for landing
pads and makes you have to wonder which code paths are going to unwind and
run destructors on what half-constructed state. With this crate, dtors only
run on happy paths in your code and on sad paths _on objects you allocated
in the room_ and _at the end of the room's life_; the idea is to let you
think less-hard about dtors from unwinds in the middle of your happy paths
(and also not to codegen landing pads). Your code is therefore "a little
more atomic", though of course it can still stop mid-execution due to a
longjmp.
- In exchange for not thinking about dtors running until the end, your objects
will typically live longer (until the end!) unless you call Room::take on a
handle and drop the result. Which you can do to force a dtor to run early.