This is a POC for #1557.

Besides adding the extra functionality, I think it cleans up the massive function .end() a little. It removes the need for continueWithResponseBody to have an error first signature.

The area where I question this logic is around error handling, but this has roots in the current code. My question is, what should happen to errors from inside user provided reply functions?

Current logic:

Throw an error without accepting a callback arg

nock('http://example.com').get('/').reply((path, requestBody) => {
  throw Error('boom!')
})

http.get('http://example.com', res => {
  console.log(res)
})

Error: boom!
    at Interceptor.nock.get.reply [as fullReplyFunction] (./nock/test.js:7:9)
    at end (./nock/lib/request_overrider.js:339:43)
    at ./nock/lib/request_overrider.js:141:9
    at OverriddenClientRequest.RequestOverrider.req.write (./nock/lib/request_overrider.js:115:9)
    at OverriddenClientRequest.RequestOverrider.req.end (./nock/lib/request_overrider.js:137:11)
    at Object.module.get (./nock/lib/common.js:114:11)

Throw an error with accepting a callback arg

nock('http://example.com').get('/').reply((path, requestBody, callback) => {
  throw Error('boom!')
})

http.get('http://example.com', res => {
  console.log(res)
})

Error: boom!
    <same stack trace as above>

Passing an error to the callback

nock('http://example.com').get('/').reply((path, requestBody, callback) => {
  callback(Error('boom!'))
})

http.get('http://example.com', res => {
  console.log(res)
})

IncomingMessage<statusCode: 500>
data event -> buffer -> toString: 
Error: boom!
    <same stack trace as above>

With proposed logic

• Throw an error without accepting a callback arg: stays the same
• Throw an error with accepting a callback arg: Returns a 500 instead of bubbling up.
• Passing an error to the callback: stays the same

New use case: throw an error inside an async function (or return a rejecting promise)

nock('http://example.com').get('/').reply(async (path, requestBody) => {
  throw Error('boom!')
})

http.get('http://example.com', res => {
  console.log(res)
})

IncomingMessage<statusCode: 500>
data event -> buffer -> toString: 
Error: boom!
    <same stack trace as above>

So it's kinda the same 🤷‍♂. I wish all these scenarios did one or the other.
In general, I question why we sometimes want errors to result in valid responses with 500 status codes, instead of letting the user defined function catch errors and return the 500 manually. But that might be out of scope for this topic and I'm overthinking it.