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 ApplicativeError #812

Merged
merged 1 commit into from
Jan 18, 2016

Conversation

travisbrown
Copy link
Contributor

This is a follow-up to a question I asked on Gitter a few days ago.

The basic idea is that it seems useful to be able to abstract over Validated[E, ?] as a context in which errors can be raised and handled, but Validated isn't monadic, so we can't provide a MonadError instance. None of the MonadError operations require monadic binding, though, and at least in the case of Validated[E, ?] there are reasonable implementations. The only MonadError law we lose is the left zero law.

This PR adds an ApplicativeError type class above MonadError, together with laws for ApplicativeError and an instance and tests for Validated. Current MonadError usage should be unaffected.

@codecov-io
Copy link

Current coverage is 89.11%

Merging #812 into master will increase coverage by +0.26% as of 66702c4

@@            master    #812   diff @@
======================================
  Files          166     168     +2
  Stmts         2296    2306    +10
  Branches        75      75       
  Methods          0       0       
======================================
+ Hit           2040    2055    +15
  Partial          0       0       
+ Missed         256     251     -5

Review entire Coverage Diff as of 66702c4

Powered by Codecov. Updated on successful CI builds.

@non
Copy link
Contributor

non commented Jan 18, 2016

Makes sense to me. Looks great! 👍

@adelbertc
Copy link
Contributor

Awesome possum 👍

adelbertc added a commit that referenced this pull request Jan 18, 2016
@adelbertc adelbertc merged commit 15a5e8d into typelevel:master Jan 18, 2016
@stew stew removed the in progress label Jan 18, 2016
rtyley added a commit to scanamo/scanamo that referenced this pull request Jul 23, 2024
The original implementation of the code to expose the `ConditionalCheckFailedException`
was introduced with PR #212 in May 2018, but I'm not sure why the multi-line implementation
was necessary - there's a discussion in PR #212, but I don't quite follow it: #212 (comment)

The Cats `recover` functionality I'm using here was added with `ApplicativeError` in
typelevel/cats#812 in January 2016, so it would have been available
for PR #212. Perhaps it was some consequence of us being on AWS SDK v1 at that point, and
having to use `AsyncHandler`?

This implementation is definitely much more similar to ones we've used elsewhere, ie
`ScalaFutureAdapter` and `PekkoInterpreter`.

If we had a `ClassTag` we could go even smaller and use `attemptNarrow`, which was added
to Cats with typelevel/cats#2863 in May 2019 - but even without that,
the implementation is much smaller.
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.

5 participants