-
Notifications
You must be signed in to change notification settings - Fork 52
Exceptions thrown in chained promises are wrapped #47
Comments
@joelwurtz Can I get your opinion on this? |
That's because we only allow HttpException / ResponseInterface in our promise chain, if you want to deal with others types you have to return your own promise implementation (or an existing one) that does not limit you to those types. However there is indeed some errors, (like relying on \Exception instead of \Throwable), and also we should return HttpException (and not \RuntimeException | \UnexpectedValueException) |
Not according to https://github.com/php-http/promise/blob/1cc44dc01402d407fc6da922591deebe4659826f/src/Promise.php#L64-L66. I don't understand the reasoning for limiting the type. You're suggesting turning it back into a Guzzle (or whatever) promise? |
Has this moved forward at all? Having issues with request exceptions on promises not being rejected and not being catched by
Line 203 of the promise(Stack trace #1) is
|
Actual Behavior
When chaining a promise and throwing an exception, the exception is wrapped inside an
Exception
with the messageInvalid exception returned from Guzzle6
.Expected Behavior
That my exception is thrown directly.
Steps to Reproduce
... results in a
RuntimeException
with the messageInvalid exception returned from Guzzle6
(with myException
asprevious
).Possible Solutions
The exception wrapping only makes sense when the actual request is being made (anything beyond that is not Guzzle). Either then return a different promise type in
Promise::then()
guzzle6-adapter/src/Promise.php
Line 79 in a56941f
guzzle6-adapter/src/Promise.php
Lines 64 to 68 in a56941f
(Related, this will also hide any fatal errors (eg
TypeError
) behind the meaningless 'Reason returned from Guzzle6 must be an Exception' exception.)The text was updated successfully, but these errors were encountered: