DEPR: deprecate raise_on_error in .where/.mask in favor of errors=
closes #14968

> But more in general, can you actually give a use case ? I mean a small example where you see the effect of the keyword?
I haven't been able to make one, and it also seems you didn't have to change any test (the one test you changed, there the keyword has no effect at all). Just wondering, probably I am missing something, but if not I would rather deprecate completely without adding alternative.

this really doesn't change anything; just had to fix some actual calls that causes the deprecation warning. The point of this is make things consistent. In the future I actually do want to change the defaults I think (and make 'coerce') possible. This is just conforming things a bit. I know this PR is not changing things, it is just converting the previous situation to a new more consistent one. That is fine. But if it is really a useless keyword, it is also an opportunity to clean things up, and to not just translate the mistakes (?) of the previous keyword to the new one.

Maybe I am missing something, but so my question still is: is there a case `errors='ignore'` actually does something? 
If it currently has no effect, we shouldn't add the new `errors` keyword, but just deprecate the old `raise_on_errors`. Or if adding the new one, have `errors='raise'` as the only option.
 > Maybe I am missing something, but so my question still is: is there a case errors='ignore' actually does something?
If it currently has no effect, we shouldn't add the new errors keyword, but just deprecate the old raise_on_errors. Or if adding the new one, have errors='raise' as the only option.

We DO need this, it is just not fully working ATM; it was turned off a while back. We need the option to raise, or ignore where the dtype is actually changing (rather than just do it, or in some cases coerce), this is a very common choice which we do in lots of places.

I don't think its a big deal to add the kw. Sure I can prob only allow 'raise' for now. Though we DO need it in a couple of places. # [Codecov](https://codecov.io/gh/pandas-dev/pandas/pull/17744?src=pr&el=h1) Report
> Merging [#17744](https://codecov.io/gh/pandas-dev/pandas/pull/17744?src=pr&el=desc) into [master](https://codecov.io/gh/pandas-dev/pandas/commit/3fae8dd84b5c7f835d7138b0f5ee3af841fab472?src=pr&el=desc) will **decrease** coverage by `0.04%`.
> The diff coverage is `84.61%`.

[![Impacted file tree graph](https://codecov.io/gh/pandas-dev/pandas/pull/17744/graphs/tree.svg?width=650&height=150&src=pr&token=eZ4WkYLtcO)](https://codecov.io/gh/pandas-dev/pandas/pull/17744?src=pr&el=tree)

```diff
@@            Coverage Diff             @@
##           master   #17744      +/-   ##
==========================================
- Coverage   91.24%    91.2%   -0.05%     
==========================================
  Files         163      163              
  Lines       49962    49973      +11     
==========================================
- Hits        45588    45576      -12     
- Misses       4374     4397      +23
```

| Flag | Coverage Δ | |
|---|---|---|
| #multiple | `89% <84.61%> (-0.03%)` | :arrow_down: |
| #single | `40.25% <30.76%> (-0.08%)` | :arrow_down: |

| [Impacted Files](https://codecov.io/gh/pandas-dev/pandas/pull/17744?src=pr&el=tree) | Coverage Δ | |
|---|---|---|
| [pandas/core/panel.py](https://codecov.io/gh/pandas-dev/pandas/pull/17744?src=pr&el=tree#diff-cGFuZGFzL2NvcmUvcGFuZWwucHk=) | `96.94% <ø> (ø)` | :arrow_up: |
| [pandas/core/computation/expressions.py](https://codecov.io/gh/pandas-dev/pandas/pull/17744?src=pr&el=tree#diff-cGFuZGFzL2NvcmUvY29tcHV0YXRpb24vZXhwcmVzc2lvbnMucHk=) | `0% <ø> (ø)` | :arrow_up: |
| [pandas/core/frame.py](https://codecov.io/gh/pandas-dev/pandas/pull/17744?src=pr&el=tree#diff-cGFuZGFzL2NvcmUvZnJhbWUucHk=) | `97.74% <100%> (-0.1%)` | :arrow_down: |
| [pandas/core/series.py](https://codecov.io/gh/pandas-dev/pandas/pull/17744?src=pr&el=tree#diff-cGFuZGFzL2NvcmUvc2VyaWVzLnB5) | `94.89% <100%> (ø)` | :arrow_up: |
| [pandas/core/sparse/frame.py](https://codecov.io/gh/pandas-dev/pandas/pull/17744?src=pr&el=tree#diff-cGFuZGFzL2NvcmUvc3BhcnNlL2ZyYW1lLnB5) | `94.78% <100%> (ø)` | :arrow_up: |
| [pandas/core/ops.py](https://codecov.io/gh/pandas-dev/pandas/pull/17744?src=pr&el=tree#diff-cGFuZGFzL2NvcmUvb3BzLnB5) | `91.76% <75%> (ø)` | :arrow_up: |
| [pandas/core/generic.py](https://codecov.io/gh/pandas-dev/pandas/pull/17744?src=pr&el=tree#diff-cGFuZGFzL2NvcmUvZ2VuZXJpYy5weQ==) | `92.03% <81.81%> (-0.07%)` | :arrow_down: |
| [pandas/core/internals.py](https://codecov.io/gh/pandas-dev/pandas/pull/17744?src=pr&el=tree#diff-cGFuZGFzL2NvcmUvaW50ZXJuYWxzLnB5) | `94.37% <83.33%> (ø)` | :arrow_up: |
| [pandas/io/gbq.py](https://codecov.io/gh/pandas-dev/pandas/pull/17744?src=pr&el=tree#diff-cGFuZGFzL2lvL2dicS5weQ==) | `25% <0%> (-58.34%)` | :arrow_down: |
| [pandas/plotting/\_converter.py](https://codecov.io/gh/pandas-dev/pandas/pull/17744?src=pr&el=tree#diff-cGFuZGFzL3Bsb3R0aW5nL19jb252ZXJ0ZXIucHk=) | `63.38% <0%> (-1.82%)` | :arrow_down: |
| ... and [1 more](https://codecov.io/gh/pandas-dev/pandas/pull/17744?src=pr&el=tree-more) | |

------

[Continue to review full report at Codecov](https://codecov.io/gh/pandas-dev/pandas/pull/17744?src=pr&el=continue).
> **Legend** - [Click here to learn more](https://docs.codecov.io/docs/codecov-delta)
> `Δ = absolute <relative> (impact)`, `ø = not affected`, `? = missing data`
> Powered by [Codecov](https://codecov.io/gh/pandas-dev/pandas/pull/17744?src=pr&el=footer). Last update [3fae8dd...552437b](https://codecov.io/gh/pandas-dev/pandas/pull/17744?src=pr&el=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).
 this should be much cleaner now. final thoughts...... @jorisvandenbossche @TomAugspurger  I am fine with having the keyword, I would just update the actual docstring (of the user facing where and mask) to not be misleading (as the current explanation is not correct).

I didn't follow the earlier discussion (https://github.com/pandas-dev/pandas/pull/16821), but just to clarify: what is the idea with `errors` keyword in the future? You say you would like to change this? But to what? 
Because the linked PR actually changed it to not error anymore if a non-matching dtype value is inserted, but to convert to object. > I didn't follow the earlier discussion (#16821), but just to clarify: what is the idea with errors keyword in the future? You say you would like to change this? But to what?
Because the linked PR actually changed it to not error anymore if a non-matching dtype value is inserted, but to convert to object.

well the problem is we are effectively always ``errors='coerce'`` now (even though we don't call it that), and never ``errors='raise```, eg. say you do a ``.where()`` (or lots of other ops like ``.fillna``, ``.setitem`` etc.) on something which would change the dtype, e.g. assign a ``Timestamp`` to an integer array.

Now we just up-convert to ``object``, but providing an option to ``coerce`` or ``raise`` is palable, and in fact you *really* want the default to be ``raise`` (and actually do it rather than up-converting), which is almost always an accident) updated.