This issue depends on issue #4
With respect to exceptions, we have to follow the model of Node.js. which seems to be the following:
- if exception is uncaught - it brings down the whole Node (but unlike .js - only one Node, and NOT everybody in the same process).
- we have to implement
uncaughtException handler the same way .js does it - in particular, it will allow ignoring exceptions
- I disagree with the rationale in Node.js doc on
uncaughtException being bad - while it does stand for stateless stuff, it is all about the relative cost of losing the state vs risk of being in a bad state - in particular, if multi-level integrity checks are present (which they SHOULD be), chances of corruption being uncaught by other levels have been seen to be slim.
- with respect to CPU-level exceptions (memory corruption etc.) - at least when safemem is on, they SHOULD NOT get to uncaughtException handler, crashing the whole process instead.
This issue depends on issue #4
With respect to exceptions, we have to follow the model of Node.js. which seems to be the following:
uncaughtExceptionhandler the same way .js does it - in particular, it will allow ignoring exceptionsuncaughtExceptionbeingbad- while it does stand for stateless stuff, it is all about the relative cost of losing the state vs risk of being in abadstate - in particular, if multi-level integrity checks are present (which they SHOULD be), chances of corruption being uncaught by other levels have been seen to be slim.