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

add abilitity to instantiate a non-blocking Future from MonadError #1482

Closed
kevinschmidt opened this issue Dec 3, 2016 · 4 comments · Fixed by #1510
Closed

add abilitity to instantiate a non-blocking Future from MonadError #1482

kevinschmidt opened this issue Dec 3, 2016 · 4 comments · Fixed by #1510
Assignees

Comments

@kevinschmidt
Copy link

When abstracting functions to return MonadError, to use Future in production and Try in unit testing, it's impossible to get an async Future from any function of the Future implementation of MonadError - either Future.successful or Future.failed is called.

In cats versions before 0.7.x. Monad.pureEval would call Future.apply, as this function was removed, there is no way to use either MonadError or Monad in an abstract way to create an async Future, which makes it hard to wrap synchronised code blocks (e.g. Java, etc.) into abstract Monads.

I would expect MonadError.catchNonFatal to show this behaviour but it's implemented as try pure(a) catch {...} (in ApplicativeError) calling Future.successful. @alexknvl suggested on Gitter to specialise this function in FutureInstances as:

def catchNonFatal[A](a: => A)(implicit ev: Throwable <:< E): Future[A] = Future.apply(a)

This would makes sense to me. This issue is probably related to #1316.

@kevinschmidt kevinschmidt changed the title add abilitity instantiate a non-blocking Future from MonadError add abilitity to instantiate a non-blocking Future from MonadError Dec 3, 2016
@johnynek
Copy link
Contributor

johnynek commented Dec 3, 2016 via email

@kevinschmidt
Copy link
Author

Sounds good, will sent a PR.

@johnynek
Copy link
Contributor

johnynek commented Jan 2, 2017

@kevinschmidt I made #1510 so we can address this for 0.9.0. Does this look fine?

@kevinschmidt
Copy link
Author

@johnynek looks good! thx!

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 a pull request may close this issue.

3 participants