Skip to content

react: return domain-specific errors (DO NOT MERGE, reference for #434 #464 merge ONLY) #463

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

Closed
wants to merge 6 commits into from
Closed

Conversation

petertseng
Copy link
Member

@petertseng petertseng commented Mar 16, 2018

Closes #462.
Closes #464 by mutual exclusion.

Note to reviewers: Since this will inevitably conflict with #434, I chose to make all commits on top of #434. This assumes that #434 is getting merged before this one.

You should ignore the commit from #434 in your review of this PR.

If you would instead prefer the changes described in this PR be merged before #434 (perhaps you can review this one very quickly but require more time to review #434), you must instead review #464. Then #434 will rebased on #464.

I have no particular preference on whether the five commits comprising this PR should be squashed (but please do not squash them together with #434).

**Problem statement**:

Consider a test with two `set_value` calls and which expects that a
callback has, ultimately, been called with the two values, one for each
`set_value`.

The tests currently do not check that one value was added during each
`set_value` call. For all we know, maybe an implementation:

* magically manages to predict the future and calls the callback twice
  on the first `set_value` call, with the correct value.
* calls the callback zero times on the first `set_value` call, but twice
  on the second `set_value` call.

To more precisely define the `set_value` expectations, this commit uses
a `Cell`-based implementation to test callbacks.
Instead of encouraging `()` as an Err type, we'd prefer to encourage
informative errors. In this case, there is only one failure mode (so we
do not need a separate error type) but there is a parameter (exactly
which cell is invalid) so we'll keep Result to designate the invalid
cell.

As discussed in #444
A subtask of #462
Instead of encouraging `()` as an Err type, we'd prefer to encourage
informative errors. In this case, there is only one failure mode and it
requires no extra information (there is only one cell specified) so
Option is sufficient.

As discussed in #444
A subtask of #462
Now that it's simplified to use Option, we can simply map into the
`get_mut`.
@petertseng petertseng changed the title react: Return domain-specific errors react: return domain-specific errors (#464 and #434 together) Mar 16, 2018
Instead of encouraging `()` as an Err type, we'd prefer to encourage
informative errors. In this case, there are multiple failure modes so we
need to have a specific enum for it.

As discussed in #444
A subtask of #462
@petertseng petertseng changed the title react: return domain-specific errors (#464 and #434 together) react: return domain-specific errors (assumes #434 is merged before this PR) Mar 16, 2018
@petertseng
Copy link
Member Author

No need to review this one, this one'll be used as reference for how I rebase whichever one gets merged second.

@petertseng petertseng closed this Mar 16, 2018
@petertseng petertseng changed the title react: return domain-specific errors (assumes #434 is merged before this PR) react: return domain-specific errors (DO NOT MERGE, reference for #434 #464 merge ONLY) Mar 16, 2018
Instead of encouraging `()` as an Err type, we'd prefer to encourage
informative errors. In this case, there are multiple failure modes so we
need to have a specific enum for it.

As discussed in #444
A subtask of #462
@petertseng petertseng reopened this Mar 16, 2018
@petertseng petertseng closed this Mar 16, 2018
@petertseng petertseng deleted the react-errs-and-exp branch April 4, 2018 20:35
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.

1 participant