Fix error handling post-migration to immutable messages #23
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Following the change to use immutable messages, error handlers largely stopped working. This was due to the fact that they were not receiving the current message instances -- and thus could not pull up-to-date data from them.
This patch does the following:
FinalHandler
now no longer accepts the request/response instances to the constructor, but rather expects them to__invoke
as the second and third methods -- just like normal error middleware, but without the final callable.Next
now passes the current request/response instances to error handlers.Next
now passes the current request/response instances to the final handler.Next
now also allows passing both the request and response when specifying an error.One upshot: unless you are performing processing AFTER calling
$next()
, you should return its return value to ensure the chain completes properly. This, in the end, is a more functional paradigm, as the chain and application no longer rely on side effects, but explicit return values.