ENH: move an exception and add a prehook to check for exception place…
- [x] closes #27656.
- [x] [Tests added and passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#writing-tests) if fixing a bug or adding a new feature
- [x] All [code checks passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit).

This is a follow up from my last MR: https://github.com/pandas-dev/pandas/pull/47901. I'm new to prehooks, so I may have went in the wrong direction for the prehook. But, I was thinking of checking the files for class that inherit Exceptions and flagging them. Let me know if another approach is preferred.

I also noticed some other exceptions while working on this.

- InvalidVersion. I tried moving this one, but got a circular import so I'm importing it in the errors.__init__.py instead.
- LossySetitemError, NoBufferPresent, and InvalidComparison are moved to errors.__init__.py.
- NotThisMethod. It seem like a code generated exception rather than a custom pandas one, so I'm importing it in the errors.__init__.py instead.

Looked pretty good. Could you fix the merge conflict and see if the Ci failures are related? > 



> Looked pretty good. Could you fix the merge conflict and see if the Ci failures are related?

Sounds good. I've merged main Awesome work on this @dataxerik! This will really help make sure users are able to publicly access Warnings and Exceptions in the future!  (just getting here from the notification that the issue was closed, so sorry for the late comment)

I _think_ that `InvalidComparison` is only used internally to raise certain cases which is then catched internally again to do something else or raise a public error. Assuming that's the case, we don't need to expose this exception class publicly? 

(the same might be true for `LossySetitemError`, didn't check in detail, cc @jbrockmendel) That's a fair point. 

Maybe we can clearly document the exceptions or warnings that are supposed to be internal? My concern is that overtime the "internal" exceptions or warnings may unintentionally become publicly thrown, and at least users could still catch them through `pandas.errors` > I think that InvalidComparison is only used internally to raise certain cases which is then catched internally again to do something else or raise a public error. Assuming that's the case, we don't need to expose this exception class publicly?

correct.  It should always be caught and re-raised.  Could clarify that in the docstring.

Ditto for LossySetitemError.