Allow opting out from automatic processing unhandled exceptions in handlers

[CarlosCortizasCT]

Scope

Improves an existing behavior

Compatibility

• This is a breaking change

Feature description

There's a breaking change introduced in the latest published version (2.3.0) related to how unhandled errors are manager in mock handlers.

This is a nice behaviour to have but I'm finding it difficult to refactor some of our tests where we needed to mock scenarios like a response timeout form the targeted server.
We were throwing an error from the http mock handler for this scenario and verify we correctly handle that scenario in our source code but, with the new behaviour, the error is not propagated and we get a 500 error response instead (which is not what happens in the real world).

I would like to ask if it would be possible for consumers to opt-out of the new behaviour.

In the PR which introduces the new change, I can see you're using the new InternalError class to differentiate between potential library errors and consumer errors so the formers can actually be propagated.
I'm not sure if you can, for instance, export another error class consumers can use to throw errors from a handler that won't be handled with the new behaviour.

Thanks!

[Lesstat]

I have the same problem. We used the ability to customize the network error via throwing an exception to test reacting to different network errors. Adding the ability to customize the error again (in some possibly new way) would be much appreciated.

Also, the documentation still contains this info:

Note that neither HttpResponse.error() nor Response.error() allow customizing the network error response. If you wish to customize it, consider throwing inside the response resolver—that will also produce a network error similar to the server throwing a runtime error.

This is not entirely correct, as the error returned is not a network error any longer, but a server error.

I could imagine an API like in the example below, as a very nice option.

http.get('/resource', () => {
  const customError = { some: 'error' };
  return HttpResponse.error(customError)
})

The behavior of HttpResponse.error() could stay the same.

[kettanaito]

HI, @CarlosCortizasCT. Thanks for raising this.

We were throwing an error from the http mock handler for this scenario and verify we correctly handle that scenario in our source code but, with the new behaviour, the error is not propagated and we get a 500 error response instead (which is not what happens in the real world).

This is the bit that needs changing. As @Lesstat has pointed out, unhandled exceptions in request handlers are not treated as server errors, resulting in 500 error responses.

You can migrate your previous logic (throwing an error) to produce the same behavior by responding to a request with Response.error() or HttpResponse.error():

http.get('/resource', () => HttpResponse.error())

This will be treated as a request/network error, just like unhandled exceptions were before the mentioned release.

Note that Response.error() doesn't accept any arguments.

Please let me know if that helps.

I'm not sure if you can, for instance, export another error class consumers can use to throw errors from a handler that won't be handled with the new behaviour.

We shouldn't expose the InternalError, it's for library's purposes only. It wouldn't work for your case anyway because it circumvents the request lookup entirely, so a thrown InternalError is neither a request error nor an error response. That breaks your app/test.

[CarlosCortizasCT]

Thanks a lot for the quick response @kettanaito.

I don't know why I didn't find that piece of information in the docs, but I'm leaving it here for reference in case anyone gets to this problem in the future

[kettanaito]

Worth reading:

• 2.3.0 Release notes (see the warning at the beginning of the notes, mentioning Response.error().
• Mocking network errors