Clean up on Deno.exit()

[phil294]

window.onunload and window.addEventListener "unload" work fine for when a script normally ends. But when

• an uncaught exception is thrown
• Deno.exit() is called
• (process is stopped, e.g. SIGINT - should be fixed with Signal Handlers #2339)

it seems, there is no way to do any clean up action. Is this intended?

Thanks and much love to all contributors.

[kevinkassimo]

IMO we should treat these 3 scenarios as different "emergency exits", and they each might have independent implications. It might be better to treat them independently:

• uncaught exception could have its own listener, like that of process.on("uncaughtException", ...) in Node.js, allowing getting a handle to the error.
• Might be reasonable to have Deno.exit() or SIGINT invoke onunload that unlistens itself when starting running.

[hayd]

Related: it'd be nice to configurably change exit's behavior to throw.
(This is a problem for deno-lambda.)

[marcosc90]

This causes FileHandler from std/log to miss logs if you send a SIGINT.

[ahuggins-nhs]

Can confirm this is still an issue. Not sure where in the code to look yet as far as what can be done to fix.

Similar pattern on Node "just works":

process.on('exit', () => console.log('Hello, world!'))
process.exit() // Console outputs "Hello, world!".

Equivalent in Deno just does... nothing?

window.onunload = () => console.log('Hello, world!')
Deno.exit() // Nothing to see here, move along...

EDIT:
It is somewhat possible to work around this for intentional exits. I'm adding something like the following to a library I'm working on for mocha in deno:

    try {
      window.dispatchEvent(new Event('unload'))
    } catch (error) {}
    Deno.exit(1)

Does not take care of anything unintended by a library author or signal interrupts from the user/os. But it's a workaround.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.