Even isolation and recovery at the process level does not guarantee that a multi-process application will have no invalid state! By the time invalid state is detected in one process and a panic happens, the invalid state may have already propagated to another process via IPC messaging.
And even taking down an entire multi-process application doesn't fully protect against invalid state, if that invalid state has wound up in persistent storage.
All recoveries from panics are ultimately heuristics.
Your goal should be for your software to behave correctly regardless of persistent state. That is, all persistent states are valid, or else that's a grave bug.
If the situation is "Program fails when restoring from state X" the priority for "Don't fail when restoring from state X" is higher than for "Don't cause whatever happened that results in state X".
Example: Let's say your code believes 'foo' is supposed to be a file with an XML structure in it. A user reports that something went wrong and now the program crashes, the file 'foo' is now exactly 4096 bytes (one page on most architectures) of binary noise.
Correct priority: #1 Make the program work when 'foo' is not an XML file. If possible (maybe 'foo' is storing animated profile pictures for a chat program) it should carry on, if that's impractical (maybe 'foo' defines which model of X-ray machine we're hooked up to, best not to press on without knowing) it should give a clear error explaining what's wrong.
#2 only after fixing #1 figure out how 'foo' gets corrupted and try to solve that.
Nitpick: this isn't really about persistent state specifically, but any shared (and especially mutable) state, including but not limited to state shared across multiple temporally-nonoverlapping instances of the same program. Eg, compare when 'foo' is provided as input or fetched across a network.
And even taking down an entire multi-process application doesn't fully protect against invalid state, if that invalid state has wound up in persistent storage.
All recoveries from panics are ultimately heuristics.