-
Notifications
You must be signed in to change notification settings - Fork 53
Make sure we catch all exceptions #35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -40,8 +40,10 @@ public function handleRequest(RequestInterface $request, callable $next, callabl | |
$journal->addSuccess($request, $response); | ||
|
||
return $response; | ||
}, function (Exception $exception) use ($request, $journal) { | ||
$journal->addFailure($request, $exception); | ||
}, function (\Exception $exception) use ($request, $journal) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. You need to add a typecheck here and only add the exception to the journal if it is an HTTP exception. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Are we happy with the Journal only accepting HTTPlug exceptions? Or should we try to find an other solution? |
||
if ($exception instanceof Exception) { | ||
$journal->addFailure($request, $exception); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. How can we see other exceptions then? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I guess we can't. Or we shouldn't. The journal is only meant to HTTP related exceptions. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Other exceptions should be handled by your code or logged/"handled" by the framework (end up in 500 usually). This Journal is to record HTTP messages and potential failures of them. This is the same questions as domain/http related exceptions. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ok, makes sense. :) |
||
} | ||
|
||
throw $exception; | ||
}); | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -3,7 +3,6 @@ | |
namespace Http\Client\Common; | ||
|
||
use Http\Client\Common\Exception\LoopException; | ||
use Http\Client\Exception as HttplugException; | ||
use Http\Client\HttpAsyncClient; | ||
use Http\Client\HttpClient; | ||
use Http\Promise\FulfilledPromise; | ||
|
@@ -79,7 +78,7 @@ public function sendRequest(RequestInterface $request) | |
$pluginChain = $this->createPluginChain($this->plugins, function (RequestInterface $request) { | ||
try { | ||
return new FulfilledPromise($this->client->sendRequest($request)); | ||
} catch (HttplugException $exception) { | ||
} catch (\Exception $exception) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. this is a BC break for custom plugins, right? before, their failure callback would accept only Http\Client\Exception, but now it could be called with \Exception. this will lead to a fatal error with parameter mismatch, where before it would be an exception that broke the chain of promises... There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. i do think its correct to do this, but maybe we need a BC layer for this. maybe an option to the PluginClient for this new behaviour, that is off by default. version 2 can then drop the option and always catch all exceptions. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. i don't think this is breaking because the rejected promise class always said that it could take things that weren't http plug exceptions There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If one have written an function HttplugException (just like we did in HistoryPlugin) it will fail with this update. But as @GrahamCampbell says, the rejected promise class always said it would be an \Exception. So: This is a bugfix, others may also suffer from this bug. But this is no BC break. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. hm, okay. but if our own classes did not adhere to what we said, we should make sure this will go into a minor version change and that the changelog is clear about it. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So: write ducumentation that explains that only HTTPlug exceptions can be thrown in the plugin. And that's it? What if a plugin cause a runtime exception? How is that handled? Should the next plugin see it? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Mergy mergy! There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The problem is that the used RejectedPromise accepts any kind of exceptions, so if an exception is thrown, the rejected promise will call the reject callback with any exception. IMO there are two/three ways:
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
No, or i do not maintain this xD, it will just be a nightmare to handle (also accepting this, say that we expect people not respecting httplug async standard... )
👍 and we must do the same for the FulfilledPromise, as actually it's accept anything, where we should only allow There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The PR is here php-http/httplug#116 |
||
return new RejectedPromise($exception); | ||
} | ||
}); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about throwables?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The RejectedPromise() takes a \Exception in its constructor. That's why we should use \Exception here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if we modified that to take a throwable?