Abort with fatal error when error-handling fails

[jasongin]

If we encounter another error while handling an error, the best thing to do would be to abort with a fatal error message. We'll need a napi_fatal_error() or similar API for that, which doesn't exist yet. Currently the error-handling code just has asserts, which are only helpful in debug mode.

See also:

• Fix reporting of API error messages #43 (comment)
• Make Error a persistent reference #32 (comment)
• Can't use node::FatalError() abi-stable-node#232

[gabrielschulhof]

We've been down this road before. How can we abort portably without replicating node::FatalError()?

[jasongin]

Previous discussion was about being able to call node::FatalError() (or equivalent) in the implementation of some functions in node_api.cc. But that wasn't really necessary since they could return error codes instead.

In this case, if N-API functions fail when handling an error in the C++ wrapper, then the options are:

• Silently ignore the error on release builds (assert on debug builds)
• Throw some other kind of C++ exception (not expected by the caller, and if N-API isn't working then the caller can't do anything reasonable to handle it)
• Abort in some other way such as std::abort() (which wouldn't provide any diagnostic information).

The suggestion here is to expose a fatal error function directly as napi_fatal_error(), so that native addons (and the C++ wrapper) can call it. Now, we'll still have the problem that node::FatalError() doesn't exist on older versions of Node. So, for those versions at least, we may have to replicate it. But I think that's OK, if the new API is justified.

Now, all this may be a waste of effort since napi_get_last_error_info() and napi_create_error() are unlikely to fail for any reason other than invalid args. That's why I originally thought just assertions would be sufficient, since any error is more likely to be just a coding mistake during development.

[jasongin]

This was done in #70