Skip to content

Conversation

@jsor
Copy link
Member

@jsor jsor commented Dec 22, 2016

Would be great if anyone from the async-interop team (@trowski, @kelunik, @bwoebi) could have a look at the implementation.

Closes #64

UnhandledRejectionException::nullOrResolve($reason),
null
);
});
Copy link

Choose a reason for hiding this comment

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

Both $onResolved calls should be wrapped with try / catch blocks and be forwarded to the error handler, currently the one of Loop, once the PR is merged, to the promise error handler: async-interop/promise#19

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, but since we're requiring ^0.2.0 and do not require async-interop/event-loop there is no other way at the moment.

Copy link

Choose a reason for hiding this comment

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

I just fixed my patch, so we can merge the PR soon and have a new release hopefully.

$onResolved(
UnhandledRejectionException::nullOrResolve($this->reason),
null
);
Copy link

Choose a reason for hiding this comment

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

Same here, needs a try / catch then.

if ($promiseOrValue instanceof AsyncInteropPromise) {
return new Promise(function ($resolve, $reject) use ($promiseOrValue) {
$promiseOrValue->when(function ($reason = null, $value = null) use ($resolve, $reject) {
$reject($reason ? $reason : $value);
Copy link

Choose a reason for hiding this comment

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

Are both null here fine?

Copy link
Member Author

@jsor jsor Dec 22, 2016

Choose a reason for hiding this comment

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

I haven't found anything in the specification which defines how the callbacks must be invoked and if none, only $reason or both arguments are required.

Copy link

Choose a reason for hiding this comment

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

The specification states:

Any implementation MUST at least provide these two parameters.

But what I was rather asking here is whether $reject is fine with null being passed?

Copy link
Member Author

Choose a reason for hiding this comment

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

Copy link

Choose a reason for hiding this comment

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

I just wasn't sure because of UnhandledRejectionException::nullOrResolve. RejectedPromise seems to miss a check for AsyncInteropPromise in __construct btw.

Copy link
Member Author

Choose a reason for hiding this comment

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

I just wasn't sure because of UnhandledRejectionException::nullOrResolve.

nullOrResolve was actually wrong. In case of rejection without a reason, it would call the when() callbacks with null as first argument signalling success instead of failure. This is fixed in 8073b04.

RejectedPromise seems to miss a check for AsyncInteropPromise in __construct btw.

Good catch, fixed in 8c68ff6

}

/**
* Implementations MAY fail upon resolution with an AsyncInteropPromise,
Copy link

Choose a reason for hiding this comment

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

If they MAY fail, that means we can't rely on it?

Copy link
Member Author

Choose a reason for hiding this comment

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

Copy link

Choose a reason for hiding this comment

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

Oh, right. fail in the sense of being rejected.

@jsor
Copy link
Member Author

jsor commented Dec 30, 2016

Superseded by #78

@jsor jsor closed this Dec 30, 2016
@jsor jsor deleted the 2.x-async-interop branch January 7, 2017 16:12
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.

3 participants