Skip to content

react: return domain-specific errors #464

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

Merged
merged 5 commits into from
Apr 4, 2018
Merged

react: return domain-specific errors #464

merged 5 commits into from
Apr 4, 2018

Conversation

petertseng
Copy link
Member

@petertseng petertseng commented Mar 16, 2018

Closes #462.

Details are in individual commit messages.

I have no particular preference on whether the five commits comprising this PR should be squashed.

@@ -11,6 +11,12 @@ pub enum SetValueError {
ComputeCell,
}

#[derive(Debug, PartialEq)]
pub enum RemoveCallbackError {
NonexistentCell,
Copy link
Member Author

Choose a reason for hiding this comment

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

note: It apparently is the case that we never test the NonexistentCell case. That can be dealt with later.

@petertseng petertseng changed the title react: return domain-specific errors react: return domain-specific errors (assumes #434 is merged after this PR) Mar 16, 2018
@petertseng petertseng changed the title react: return domain-specific errors (assumes #434 is merged after this PR) react: return domain-specific errors Mar 16, 2018
@petertseng
Copy link
Member Author

I decided to dispense with any reviewer-facing considerations on which of #464 or #463 to review. I decide to offer only this PR #464 for review, and I will rebase either this PR or #434 accordingly, now that I have #463 as a reference for what the final product should look like.

// Check all dependencies' validity before modifying any of them,
// so that we don't perform an incorrect partial write.
if !dependencies.iter().all(|&id| id < self.cells.len()) {
return Err("Nonexistent input");
if let Some(&invalid) = dependencies.iter().find(|&dep| *dep >= self.cells.len()) {
Copy link
Member Author

Choose a reason for hiding this comment

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

There is in fact not a specific reason I wrote find(|&dep| *dep >= self.cells.len()) as opposed to one of these two alternatives:

find(|&&dep| dep >= self.cells.len())
find(|dep| **dep >= self.cells.len())

I really don't know what I'm doing and which is better, so I need help on that.

coriolinus
coriolinus previously approved these changes Apr 4, 2018
@petertseng
Copy link
Member Author

Last reviewed: ff451ea

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`.
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
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
Copy link
Member Author

This merge was more involved. I'll ask for a re-review on this one to make sure I didn't screw anything up.

@petertseng petertseng dismissed coriolinus’s stale review April 4, 2018 19:22

This merge was more involved. I'll ask for a re-review on this one to make sure I didn't screw anything up.

@@ -206,10 +206,10 @@ fn removing_a_callback_multiple_times_doesnt_interfere_with_other_callbacks() {
let output = reactor.create_compute(&[input], |v| v[0] + 1).unwrap();
let callback = reactor.add_callback(output, |v| cb1.callback_called(v)).unwrap();
assert!(reactor.add_callback(output, |v| cb2.callback_called(v)).is_some());
// We want the first remove to be Ok, but we don't care about the others.
// We want the first remove to be Ok, but the others should be errors.
Copy link
Member Author

Choose a reason for hiding this comment

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

strictly speaking, this line shouldn't be in this PR; it's been wrong ever since I did 2602332 as the last commit right before merging #191

Copy link
Member

@coriolinus coriolinus left a comment

Choose a reason for hiding this comment

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

This still looks correct to me.

@petertseng
Copy link
Member Author

Thanks for that!

@petertseng petertseng merged commit 2711a07 into exercism:master Apr 4, 2018
@petertseng petertseng deleted the react-errs branch April 4, 2018 19:46
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.

2 participants