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

feat(timeout): remove errorToSend argument, always throw TimeoutError #2172

Merged
merged 1 commit into from
Dec 7, 2016
Merged

feat(timeout): remove errorToSend argument, always throw TimeoutError #2172

merged 1 commit into from
Dec 7, 2016

Conversation

benlesh
Copy link
Member

@benlesh benlesh commented Dec 5, 2016

The errorToSend argument did not make much sense, so we are removing it ahead of the 5.0 release. All timeout errors will be thrown as TimeoutError, which can be tested with an assertion against instanceof Rx.TimeoutError.

BREAKING CHANGE: timeout no longer accepts the errorToSend argument

related #2141

@benlesh
Copy link
Member Author

benlesh commented Dec 5, 2016

cc @kwonoj @jayphelps

@coveralls
Copy link

coveralls commented Dec 5, 2016

Coverage Status

Coverage decreased (-0.001%) to 97.685% when pulling 5854691 on blesh:timeout_fix into bd56b3c on ReactiveX:master.

@@ -97,6 +93,6 @@ class TimeoutSubscriber<T> extends Subscriber<T> {
}

notifyTimeout(): void {
this.error(this.errorToSend);
this.error(new TimeoutError());
Copy link
Member

@kwonoj kwonoj Dec 5, 2016

Choose a reason for hiding this comment

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

@Blesh I'd propose to create error object in ctor, allows bit easier stack to trace (was done in #2132)

Copy link
Member Author

Choose a reason for hiding this comment

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

Why allocate an object you don't need?

Copy link
Member

Choose a reason for hiding this comment

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

Not sure which object is unused, pr #2132 is simply changing where error object is created and pass into here. Would you elaborate bit what I'm missing?

Copy link
Member

Choose a reason for hiding this comment

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

@Blesh because if you do end up needing it, the stack trace is awful if we don't do it at the constructor call site. See #2132

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 see. Makes sense.

@benlesh
Copy link
Member Author

benlesh commented Dec 7, 2016

The coverage results seem to be just the unfortunate math of removing a few tests we didn't need. I'm not worried about it.

The `errorToSend` argument did not make much sense, so we are removing it ahead of the 5.0 release. All timeout errors will be thrown as `TimeoutError`, which can be tested with an assertion against `instanceof Rx.TimeoutError`.

BREAKING CHANGE: `timeout` no longer accepts the `errorToSend` argument

related #2141
@kwonoj
Copy link
Member

kwonoj commented Dec 7, 2016

LGTM

@benlesh benlesh merged commit 98ea3d2 into ReactiveX:master Dec 7, 2016
@coveralls
Copy link

coveralls commented Dec 7, 2016

Coverage Status

Coverage decreased (-0.001%) to 97.685% when pulling 5854691 on blesh:timeout_fix into bd56b3c on ReactiveX:master.

@benlesh benlesh deleted the timeout_fix branch December 16, 2016 03:15
@samal-rasmussen
Copy link
Contributor

Note to anyone else who was using the errorToSend argument to create a contextual error message.
You can use catch immediately after the timeout and check the error for instanceof TimeoutError like this to achive the same:

source.timeout(1000)
.catch((error) => {
  if (error instanceof TimeoutError) {
    throw new Error('Timeout error. Value of someLocalVariable was: ' + someLocalVariable);
  } else {
    throw error;
  }
});

Quite a lot more lines I know.

@samal-rasmussen
Copy link
Contributor

Also @benlesh why did the errorToSend argument not make any sense?

@lock
Copy link

lock bot commented Jun 6, 2018

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked as resolved and limited conversation to collaborators Jun 6, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants