Catch errors thrown in ensure block

[jnicklas]

Closes #78

If an error ever occurrs in an ensure block, then that is a serious problem. We should inform the user that this is not good by printing a huge nasty warning to the console.

However, if such a situation does occur, at least it should not leave the process tree in an inconsistent state. Other exit hooks should still run, and other processes should still shut down. Currently if such an error does occur, it will blow the stack, and cause finalization to stop
abrubtly. This is very much not good.

Here we're rescuing any such errors, printing them to the console, but crucially we are NOT re-raising them. This allows us to proceed with finalization, which will leave the process tree in a more consistent state.

It's worth noting though that such a situation really is very undesirable. The Rust language does a hard abort of the process with an error exit code if a destructor panics, we cannot do something similar in effection, since we want to run in browsers, and browsers cannot hard-exit.

[frontsidejack]

A preview package of this pull request has been released to NPM with the tag catch-ensure-errors.
You can try it out by running the following command:

$ npm install effection@catch-ensure-errors

or by updating your package.json to:

{
  "effection": "catch-ensure-errors"
}

Once the branch associated with this tag is deleted (usually once the PR is merged or closed), it will no longer be available. However, it currently references effection@0.5.1-312a6d5 which will be available to install forever.

Generated by 🚫 dangerJS against 8ec127f

[jnicklas]

@cowboyd not sure why the type tests are failing. It looks unrelated to this PR though.

[cowboyd]

A very much needed change, and looks good to me. I added a suggestion to tweak the message to try and let folks know the consequences of a failed exit hook, and to reference the ensure() API since we don't use exit handlers

[cowboyd]

@cowboyd not sure why the type tests are failing. It looks unrelated to this PR though.

I'm guessing that it's because we have our TS config pointed to esnext which is a moving target..... which moved. Maybe if we peg it to es2019 or some fixed target?

[frontsidejack]

A preview package of this pull request has been released to NPM with the tag catch-ensure-errors.
You can try it out by running the following command:

$ npm install effection@catch-ensure-errors

or by updating your package.json to:

{
  "effection": "catch-ensure-errors"
}

Once the branch associated with this tag is deleted (usually once the PR is merged or closed), it will no longer be available. However, it currently references effection@0.5.1-2c504ef which will be available to install forever.

Generated by 🚫 dangerJS against 1ec6b7a

[frontsidejack]

A preview package of this pull request has been released to NPM with the tag catch-ensure-errors.
You can try it out by running the following command:

$ npm install effection@catch-ensure-errors

or by updating your package.json to:

{
  "effection": "catch-ensure-errors"
}

Once the branch associated with this tag is deleted (usually once the PR is merged or closed), it will no longer be available. However, it currently references effection@0.5.1-5826040 which will be available to install forever.

Generated by 🚫 dangerJS against 1ab9ce5

[jnicklas]