STYLE: Prohibit parsing exeption messages in `try/except` code flows

[mroeschke]

There are a few spots in the code base where we parse exception message to rewrite a new exception message or dictate fallback behavior e.g.

try:
    ...
except ValueError as err:
    if "Message1" in str(err):
         raise ValueError(message_other) from err
    elif "Message2" in str(err):
         return True

% grep -R --include="*.py" "in str(err)"
./pandas/compat/pickle_compat.py:        if msg in str(err):
./pandas/core/resample.py:            if "Must produce aggregated value" in str(err):
./pandas/core/dtypes/cast.py:            if "cannot supply both a tz and a timezone-naive dtype" in str(err):
./pandas/core/dtypes/missing.py:                if "boolean value of NA is ambiguous" in str(err):
./pandas/core/groupby/generic.py:                    if "No objects to concatenate" not in str(err):
./pandas/core/internals/blocks.py:        elif "'value.closed' is" in str(err):
./pandas/core/frame.py:            if "shape mismatch" not in str(err):
./pandas/core/apply.py:            if "All arrays must be of the same length" in str(err):
./pandas/core/indexes/base.py:            if "index must be specified when data is not list-like" in str(err):
./pandas/core/indexes/base.py:            if "Data must be 1-dimensional" in str(err):

This signals that the exception and message is significant to ops behavior and is more brittle to rewriting exception message in general. IMO we should be using exception subclasses instead. Thoughts?

[jbrockmendel]

Sounds like good practice

[vyasr]

FWIW we are actively trying to do this for cudf as well.

[luke396]

take

[LirongMa]

take