REF: de-duplicate Categorical _validate_foo_value
- [ ] closes #xxxx
- [x] tests added / passed
- [x] Ensure all linting tests pass, see [here](https://pandas.pydata.org/pandas-docs/dev/development/contributing.html#code-standards) for how to run them
- [x] whatsnew entry

TypeError is "more correct" for these anyway, and we come within striking distance of sharing with datetimelike.
> TypeError is "more correct" for these anyway

release note? I think we normally add when changing the exception type (but not always for just a change in message)

Can you also explain why TypeError is "more correct". > release note? I think we normally add when changing the exception type (but not always for just a change in message)

Just pushed with note

> Can you also explain why TypeError is "more correct".

My reasoning is that TypeError makes more sense than ValueError here because it is determined solely by the dtype.  By contrast, ValueError would make sense if we had a valid-for-the-dtype value that was an incompatible shape.  KeyError is only being replaced in a few places, and it just doesn't make sense at all in these non-indexing/lookup contexts.
 > release note? I think we normally add when changing the exception type (but not always for just a change in message)

Just pushed with note

> Can you also explain why TypeError is "more correct".

My reasoning is that TypeError makes more sense than ValueError here because it is determined solely by the dtype.  By contrast, ValueError would make sense if we had a valid-for-the-dtype value that was an incompatible shape.  KeyError is only being replaced in a few places, and it just doesn't make sense at all in these non-indexing/lookup contexts.
 @simonjayhawkins is it time to move whatsnew notes for existing PRs to the 1.4 file? > @simonjayhawkins is it time to move whatsnew notes for existing PRs to the 1.4 file?

not sure @jreback ?

I started that task after we branched but was asked not to milestone things. Without being able to add milestones doing that task seemed pointless so I stopped.

If a PR has a release note then we need to assess whether we will be backporting or ask the contributor to move the release note.

If a PR doesn't have a release note then moving release note is not applicable and unless it's CI related then we probably are not backporting to 1.3.x

This PR is titled as a refactor. but has a change in behavior so probably needs a change in title as well.


 > If a PR has a release note then we need to assess whether we will be backporting or ask the contributor to move the release note.

it's not just release notes, we also need to check PRs for versionadded and versionchanged tags. let's target 1.4 with this will have to re-loook can you rebase thanks, makes sense