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

Investigate whether a PotentialRecovery class makes sense #7

Open
theangrydev opened this issue Oct 23, 2016 · 3 comments
Open

Investigate whether a PotentialRecovery class makes sense #7

theangrydev opened this issue Oct 23, 2016 · 3 comments

Comments

@theangrydev
Copy link
Owner

Like the PotentialFailure class but for sad recoveries

@tjheslin1
Copy link

How would this work? I imagine you'd define a HappyPath type you could flow back into and a SadPath type in which you would stay in?

@theangrydev
Copy link
Owner Author

Just like HappyPath.attempt(ActionThatMightFail<Happy, Sad> actionThatMightFail) can go from happy to sad based on the PotentialFailure<Sad> result of the ActionThatMightFail, I can imagine a SadPath.attempt(ActionThatMightRecover<Happy, Sad> actionThatMightRecover) that can go from sad to happy based on a PotentialRecovery<Happy> result of the ActionThatMightRecover.

It would probably just be a copy-paste job to implement, based around the existing happy attempt method and everything it depends on. There might be a better name than "attempt" too I can't think of one right now though.

What do you think?

@tjheslin1
Copy link

"attempt" is good. I would avoid "retry" as I can imagine uses other than retrying.

I've heard you use "recover" before which I think is general enough but is a hint at its intended usage.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants