deprecate domain.dispose()

[othiym23]

Almost nobody uses it correctly, every time somebody tries to use it @isaacs tells them they shouldn't be using it, and its semantics are somewhere between undefined and actively dangerous under unusual circumstances. Better documentation on how to explicitly recover from errors in domains would be a better substitute.

[isaacs]

I support this plan. Let's wrap it in a util.deprecate() in master, and update the docs add some stuff for error recovery.

[isaacs]

Along with deprecating it, we should make it literally do nothing except set domain._disposed=true. The other stuff was a bad idea.

[OrangeDog]

Can we have some clarification as to why?

If I have a domain with lots of http connections attached to it, and one of them fails, then I want to abort everything as continuing is pointless. However, how do I get a list of all the the things to destroy if the domain's error handler was added before all the request/response objects were bound?

I thought the whole point of domains was to have all your error handling in one place, where you can give useful error responses to your clients, rather than having to duplicate the logic in every single place I/O is happening, and strongly couple the whole codebase in order to clean up related operations.

[othiym23]

The concept of dispose isn't terrible, but the implementation is heuristic and messy, and can't really be fixed because a function can't know at error time what the correct disposition is for all of a domain's members. Look at the code being removed and you'll see how brute force it is.

Ideally you'd have added code to deal with resources that need cleanup on shutdown to the domain's error handler, and if you want something like the old behavior, you can still access the list of the domain's associated resources via this.members and do whatever you like with them.

[jasnell]

Appears to have been done. Closing