Skip to content

Conversation

@dereuromark
Copy link
Member

Possible solution of #11514
We convert it back to the PHP5 exception where needed as the constructor for ExceptionRenderer exceptions Exception which is not compatible with PHP7.
Removing the typehint here can only be done in a non-patch version as the eco system could implement them still as such.

@codecov-io
Copy link

codecov-io commented Dec 7, 2017

Codecov Report

Merging #11518 into master will decrease coverage by 0.01%.
The diff coverage is 100%.

Impacted file tree graph

@@             Coverage Diff              @@
##             master   #11518      +/-   ##
============================================
- Coverage     93.38%   93.36%   -0.02%     
- Complexity    13028    13034       +6     
============================================
  Files           436      436              
  Lines         32775    32848      +73     
============================================
+ Hits          30606    30669      +63     
- Misses         2169     2179      +10
Impacted Files Coverage Δ Complexity Δ
src/Error/Middleware/ErrorHandlerMiddleware.php 90.9% <100%> (ø) 26 <0> (ø) ⬇️
src/Http/Client/Message.php 0% <0%> (ø) 7% <0%> (+3%) ⬆️
src/Http/Client/Response.php 93.72% <0%> (+0.72%) 58% <0%> (+3%) ⬆️

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 e7f5da5...248bb55. Read the comment docs.

@markstory
Copy link
Member

Any chance we could add a test for the scenario this is handling?

@ADmad
Copy link
Member

ADmad commented Dec 9, 2017

I added a test.

@dereuromark
Copy link
Member Author

Thank you for helping with the test case :)


if ($this->getConfig('skipLog')) {
foreach ((array)$this->getConfig('skipLog') as $class) {
if ($unwrapped instanceof $class) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do tests need to be updated for logging fixes?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is basically just a copy and paste of the old error handler. But could sure be added.
Would probably be better to follow @saeideng s advice and re-use more common code instead of duplicating in the long run. But for now out of scope of the bugfix.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually this change isn't necessary at all. logException() never get's Error instance wrapped inside PHP7ErrorException. The wrapping is only done inside getRenderer() when passing the exception instance to ExceptionRender's constructor.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you 100% sure? I am also referring to any outside or custom handler extending the middleware?
With the above change I just wanted to make double sure nothing goes wrong if it ever would get such an exception passed.

Copy link
Member

@ADmad ADmad Dec 10, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The unwrapping is surely not needed inside logException() with current state of middleware code. If some extending middleware needs it (I don't see why) then it's up to them to update their code as required.

Copy link
Member Author

@dereuromark dereuromark Dec 10, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you are mistaken. The incoming one can very well be PHP7+ or a wrapped one afaik. The wrapping currently only happens inside getRenderer() and thus does not affect the variable inside handleException(), that is correct. But it could already be passed wrapped, correct? And that means that the logging should be aware of both versions.
As such you should revert as that code piece is very well required and should stay both for the class itself as for any extension to function properly.

Short version: It doesnt hurt to keep IMO.
But I am fine either way.

@dereuromark dereuromark merged commit 4b10e9c into master Dec 10, 2017
@dereuromark dereuromark deleted the bugfix/php7exceptions branch December 10, 2017 23:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants