Hapi: Remove domains

Created on 15 Sep 2017  Â·  10Comments  Â·  Source: hapijs/hapi

breaking changes

Most helpful comment

@mtharrison there are no good solutions for the edge cases where a handler throws inside another tick (e.g. you throw inside a timer). Even domains didn't really solve the problem of throwing in every resource pool and some people had to manually bind the request.domain to their handlers. It was a mess to support with monthly new issues about domains not playing well with something.

I've decided the best path forward is to go all in on async/await and let people decide what they want to do about calling code in their handlers that doesn't follow the promises contract. I looked into bringing domains back into v17 but I just don't want to add that for the few edge cases left.

All 10 comments

Means we'll have to catch exceptions in prereqs, plugins, route handlers ourselves?

Not exactly– the idea is to use async/await as the foundation for error handling rather than domains.

Domains is not intended for normal error handling. It is mainly there to catch unexpected issues that can appear in production, giving you a chance to handle it gracefully.

@kanongil yes, that's what I meant... whether I should start worrying that unhandled exceptions will start killing our servers.

But I guess I was wrong as per @devinivy

The approach has limitations– there is an ongoing conversation about it if you have any thoughts :)

@devinivy where is the conversation? Was there any reasonable alternative proposed for how to deal with uncaught exceptions bringing your app down?

At the time I wrote that there was chatter in here and on the hapi hour slack. I was anticipating more conversation on this issue, though. Now that hapi is based on async/await in v17, the majority of runtime exceptions (including those that would formerly be uncaught) should turn into rejections that the framework will handle for you. As for the exceptions that cannot be handled this way, there is no proposed solution that I know of. It was noted in hapi hour that when node's async-hooks API becomes stable, that might be a viable option.

@mtharrison there are no good solutions for the edge cases where a handler throws inside another tick (e.g. you throw inside a timer). Even domains didn't really solve the problem of throwing in every resource pool and some people had to manually bind the request.domain to their handlers. It was a mess to support with monthly new issues about domains not playing well with something.

I've decided the best path forward is to go all in on async/await and let people decide what they want to do about calling code in their handlers that doesn't follow the promises contract. I looked into bringing domains back into v17 but I just don't want to add that for the few edge cases left.

@hueniverse that makes sense. It was an imperfect solution to the problem anyway but caused lots of trouble. Thanks for the clarification.

This thread has been automatically locked due to inactivity. Please open a new issue for related bugs or questions following the new issue template instructions.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

kevinsimper picture kevinsimper  Â·  4Comments

hovmand picture hovmand  Â·  3Comments

arb picture arb  Â·  4Comments

mateeyow picture mateeyow  Â·  5Comments

DrMabuse23 picture DrMabuse23  Â·  5Comments