Changed error handling logic to stop after error has been handled

[philprime]

Changed run error middlewares so that it conforms to the behaviour stated in the documentation

middleware1 = {
  onError: (handler) => {
    handler.response = { error: handler.error };
    return Promise.resolve();
    // Resolves to a falsy value
  }
}
middleware2 = {
  onError: (handler) => {
    return Promise.resolve(handler.error)
  }
}
handler.use(middleware1).use(middleware2);

middleware2 should not be called.

Relevant issues:

• Error that gets handled by middleware is still passed on to next moddleware #485

[codecov]

Codecov Report

Merging #497 into master will not change coverage by %.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##            master      #497   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           20        20           
  Lines          547       550    +3     
  Branches       112       113    +1     
=========================================
+ Hits           547       550    +3     

Impacted Files	Coverage Δ
src/middy.js	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2931123...f55511f. Read the comment docs.

[lmammino]

Hello @philprime!
Thanks a lot for taking the time to address this and apologies again for the delay with my review.

At first glance, this looks good and more consistent with what is documented here.

I am ok for merging this, but I prefer to do it after #504 so that I can release it together with few other pending PRs.

Meanwhile, I'd love to get @willfarrell or @dkatavic review as well here :)

[dkatavic]

Should there be there instead of theres?

[dkatavic]

This was merged while inspecting the code, ignore it

[lmammino]

I did mess up with this one a little. I will do another commit to properly release this on 0.x and also fix this typo. So totally valuable comment :) Thanks

[lmammino]

(i will also fix in the port to 1.0)

[lmammino]

We should port this one to 1.0.0-beta, realized only now this was targeting master :(

[lmammino]

This fix will be released shortly in 0.35.0 and in 1.0.0-beta.11

[lmammino]

I am revisiting this in the context of v1 (which includes a http-response-serializer that also works with the default HTTP error handler).

This PR breaks the original intended design (and therefore compatibility with some middlewares).

As per the docs:

When a middleware handles the error and creates a response, the execution is still propagated to all the other error middlewares and they have a chance to update or replace the response as needed. At the end of the error middlewares sequence, the response is returned to the user.

This is needed for instance in the case of the HTTP error handler which will format the error in a correct response for the lambda HTTP integration. If this is combined with the response serializer it must be possible to convert this response to XML or other formats.

I will have to revert this on master