Fatal termination of the program might be the only safe bet if the internal state is compromised by a bad actor, I would be distrustful of claims to "cleanly" recover or try to "handle" errors that they actually can't handle. That's why long-running processes should be run under high availability supervision like daemontools or systemd.
I'm no expert on implementation details but the idea of Exceptions seems right to me, errors can't be ignored, they have to be handled or the program dies, which seems better to me than having your program jump the track and keep stupidly barreling along mowing through your data, driving through your living room window 8-)
Posted Nov 11, 2012 16:19 UTC (Sun) by paulj (subscriber, #341)
[Link]
If the internal state is compromised yes. However, you want to reject the bad actor's input before that happens. Parsing things with state machines and related automata, and cleanly rejecting invalid input (and dispensing with associated state) is not rocket science. (Note that method calls related to some piece of state can be viewed as inputs/transitions on an automaton).
Asserting and crashing should be a last resort in daemons that must provide shared-state services to multiple actors. While it is preferable to assert than to allow a security critical error, asserting itself may be a security critical error - handling errors cleanly is again preferable to the assert. A better approach is to have multiple layers of defence, with asserts against critical inconsistency errors at lower layers (e.g. forcing all IO through checked, bounded buffer abstractions), and well-defined automata at higher layers to provide clean error semantics (potentially multiple levels of such). You can't just restart, because of the shared-state. If you externalise the shared-state so that the code can be restarted, you still need to ensure that shared-state can never be manipulated into an inconsistent state.
All the world is a state machine, even the functional programming world. ;)