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

Concat error #564

Merged
merged 4 commits into from
Nov 27, 2017
Merged

Concat error #564

merged 4 commits into from
Nov 27, 2017

Conversation

nmccann
Copy link
Contributor

@nmccann nmccann commented Nov 22, 2017

Given that SignalProducer already supports concatenating a value or a signal, being able to concatenate an error seemed logical. I personally found this useful when implementing a signal that defaulted to an error if nothing matched a filter. For example:

filtered.concat(error: notFound).take(first: 1)

Checklist

  • Updated CHANGELOG.md.

Noah McCann added 2 commits November 22, 2017 15:36
Added a convenience method for concatenating an error to a
SignalProducer.
Copy link
Member

@NachoSoto NachoSoto left a comment

Choose a reason for hiding this comment

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

This seems sensible 👍
Can you add another test for concatenating an error to a failing producer? (Seems silly, but just to verify that obviously the original error is the one emitted).

@nmccann
Copy link
Contributor Author

nmccann commented Nov 24, 2017

@NachoSoto good test suggestion! Will add that shortly.

Added an additional test case to verify that the error of the
original signal is emitted - this ensures that concatenated error
doesn't override or silence the original error in some way.
expect(results[3].error) == .default
}

it("should emit own error when present") {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm not quite sure of the wording of this expectation. Thoughts?

Copy link
Member

Choose a reason for hiding this comment

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

"should not concat the error", perhaps?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I feel like that contradicts the earlier expectation - unless the reader looks at the implementation. However in my usage of Quick, I try to write expectations that could stand-alone without the implementation and still make sense.

Copy link
Member

Choose a reason for hiding this comment

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

“should not concat a subsequent error if the earlier producer has failed”?

Copy link
Contributor

Choose a reason for hiding this comment

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

"should not emit concatenated error to a failed producer"?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thank you for the help @andersio and @mdiep - I've settled on an alternative that I'm happy with.

Altered wording of expectation to clarify it's behaviour.
@andersio andersio merged commit e40a647 into ReactiveCocoa:master Nov 27, 2017
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