Skip to content
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

Avoid hidding exceptions thrown in HttpClient\Request error handlers #31

Merged
merged 3 commits into from Oct 5, 2015

Conversation

arnaud-lb
Copy link
Contributor

then() catches exceptions, which is not desirable when its result is not returned.

The following code throws an exception in the 'error' event handler. However, the exception is caught because the event is fired in a then() callback.

This PR fixes this by changing a then to a done.

$requestData = new RequestData('GET', 'http://www.example.com');
$request = new Request($this->connector, $requestData);

$request->on('error', function () {
    throw new \Exception();
});

$request->end();

Actual use case:

$requestData = new RequestData('GET', 'http://www.example.com');
$request = new Request($this->connector, $requestData);

$deferred = new Deferred();

$request->on('error', function ($err) use ($deferred) {
    $deferred->reject($err);
});

$deferred->done(); // Throws an exception if the deferred is rejected.
                   // Without the PR, the exception is caught.

$request->end();

@clue
Copy link
Member

clue commented Jun 7, 2015

Thanks for spotting! These could certainly introduce some subtle and hard to trace issues.

Afaict you're trying to throw an Exception in the data (or error) event handler? I'm not quite sure this has been tested extensively. Also, I'm not quite sure how this should be handled ideally.

Can you provide a simple gist that exhibits this?

@arnaud-lb
Copy link
Contributor Author

Hi @clue,

Afaict you're trying to throwanExceptionin thedata(orerror`) event handler? I'm not quite sure this has been tested extensively. Also, I'm not quite sure how this should be handled ideally.

I guess the request/response shouldn't be considered to be in a consistent state after that :)

But at least, the exception should be allowed to unwind and eventually trigger a visible error if not caught by user code.

I'm not quite sure this has been tested extensively

I'm guilty, I didn't planned for that when I wrote reactphp/http-client :)

Can you provide a simple gist that exhibits this?

Sure ! Here it is: https://gist.github.com/arnaud-lb/71cf44ab2564b810b463

As you can see, I'm not throwing an exception myself. (And at first, one wouldn't think that the exception is thrown in the error event handler; but it is.)

However, I'm expecting to at least see exceptions that are thrown.

The problem disappears after merging both reactphp/dns#26 and #31.

Thanks!

@WyriHaximus
Copy link
Member

Going to review and test this tonight and get back to it here, thanks for spotting 👍

@WyriHaximus
Copy link
Member

LGTM 👍 , @clue do you want to check, merge and tag reactphp/dns#26 first before signing this one off or should I go ahead and merge and tag this one first?

@clue
Copy link
Member

clue commented Sep 7, 2015

Thanks for the background @arnaud-lb!

LGTM 👍

@WyriHaximus both PRs LGTM, so feel free to review the other one and push either one forward 👍

@WyriHaximus WyriHaximus self-assigned this Sep 20, 2015
@WyriHaximus WyriHaximus added this to the v0.4.7 milestone Sep 20, 2015
@clue
Copy link
Member

clue commented Sep 23, 2015

Ping @arnaud-lb, can you update this to require react/promise: ~2.2?

Otherwise LGTM 👍

@jsor
Copy link
Member

jsor commented Sep 24, 2015

LGTM 👍

WyriHaximus added a commit that referenced this pull request Oct 5, 2015
Avoid hidding exceptions thrown in HttpClient\Request error handlers
@WyriHaximus WyriHaximus merged commit aff6a16 into reactphp:master Oct 5, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants