Introduce ResponseParsingException and throw this exception in …#825
Introduce ResponseParsingException and throw this exception in …#825tandhika wants to merge 10 commits intothephpleague:masterfrom
Conversation
…ctProvider::parseResponse() if necessary
|
This PR aims at resolving issue #626 |
|
The failed test was due to a bug in json_decode of php5.6, which accepts empty string as a valid json. I'll fix the test and resubmit the PR |
… empty string as a valid json
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #825 +/- ##
===========================================
Coverage 100.00% 100.00%
- Complexity 180 184 +4
===========================================
Files 20 21 +1
Lines 464 476 +12
===========================================
+ Hits 464 476 +12
🚀 New features to boost your workflow:
|
|
I have fixed some broken changes after merging from current master. |
src/Provider/AbstractProvider.php
Outdated
| $e | ||
| ); | ||
| // for any other content types | ||
| if ($this->mayThrowResponseParsingException) { |
There was a problem hiding this comment.
Maybe we always throw the exception, no matter what?
I know this suggestion is somewhat of a BC break, but if you have ResponseParsingException extend UnexpectedValueException, then anyone catching that exception will start catching the new exceptions and can decide what to do about them.
@shadowhand, @stevenmaguire, thoughts?
There was a problem hiding this comment.
I like your suggestion. I can implement the changes if no objection coming from @shadowhand and @stevenmaguire
…f response body cannot be parsed as JSON
|
So, I have incorporated reviewer suggestions into the last commit, but I kept the BC until there is a need to change that as well. Thx @ramsey for the suggestions. If I should squash all my commits, please let me know. |
…AbstractProvider::parseResponse() if necessary