Rethink unhandled exception handling #14

Monkey-patch process._fatalException?
process.on('uncaughtExceptionMonitor') https://nodejs.org/api/process.html#process_event_uncaughtexceptionmonitor

Do we need to detect unhandledRejection, too?

Looks like C++ starts the process of triggering and (possibly) dying from an unhandled exception:
https://github.com/nodejs/node/blob/65234bbce024dec9d5490b17137abe381a979a28/src/node_errors.cc#L926-L1018

This JS code -- "global uncaught exception handler" -- receives fatal exceptions and fires the process events:
https://github.com/nodejs/node/blob/55745a1817152629ad492e9b8dd1e3bca49686b7/lib/internal/process/execution.js#L130-L201

This C++ reports fatal exceptions once it is clear that the exception is, indeed, fatal / unhandled.
https://github.com/nodejs/node/blob/65234bbce024dec9d5490b17137abe381a979a28/src/node_errors.cc#L280-L418

This issue talks a bit about the hidden private symbol upon which the "arrow message" is stored. "Arrow message" is the prefix with a caret pointing to the exact position in the code where the error occurred.

https://github.com/nodejs/node/issues/4835

node's internal JS has a setArrowMessage function which can set this message:
Used here: https://github.com/nodejs/node/blob/e2a6399be742f53103474d9fc1e56fadf7f90ccc/lib/internal/modules/cjs/loader.js#L1146

If the line includes this directive, node does not include certain info:

throw e; /* node-do-not-add-exception-line */