Add reject (partial function) method to MonadError

[wogan]

Partial functions are a convenient method for expressing ensure.

In ApplicativeError handleError has another method recover which accepts PartialFunction. This is similar but for the reverse direction. If you can think of a better name than ensureP I'm open to it - perhaps reject, guard or guarantee.

[wogan]

Oh hang on tests still need attention. I will revisit this after I have fixed them.

[kailuowang]

Thanks for this. The method seems useful, but I do agree that ensureP might give a false impression given the other ensure methods. reject might be a good choice.
The other issue is that, due to our commitment to maintaining binary compatibility, we can't add new methods to any public trait. So this new method might have to go to MonadErrorOps as a mere syntax extension
https://github.com/typelevel/cats/blob/master/core/src/main/scala/cats/syntax/monadError.scala

[wogan]

Thanks for taking a look. I've renamed it to reject and removed it from MonadError directly (leaving only the syntax extension.

Re: binary compatibility, mea cupla, I forgot adding a method to a trait isn't safe prior to Scala 2.12.

[codecov-io]

Codecov Report

Merging #2194 into master will increase coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #2194      +/-   ##
==========================================
+ Coverage   94.78%   94.78%   +<.01%     
==========================================
  Files         332      332              
  Lines        5697     5699       +2     
  Branches      214      214              
==========================================
+ Hits         5400     5402       +2     
  Misses        297      297

Impacted Files	Coverage Δ
core/src/main/scala/cats/syntax/monadError.scala	100% <100%> (ø)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 246b0e0...f91e792. Read the comment docs.

[kailuowang]

There is this trick that avoids calling isDefinedAt and then apply of the PartialFunction, maybe worthwhile to copy here, just a thought. Also, instead of F.pure(a) shall we just return fa?

[wogan]

I'm thinking of doing F.flatMap(fa)(a => pf.andThen(F.raiseError[A]).applyOrElse(a, _ => fa)), though that does create a new "AndThen" object. Is avoiding the allocation important?

[kailuowang]

that might be a good balance between readability and performance.