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

[LirongMa]

Issue #50353

• closes #xxxx (Replace xxxx with the GitHub issue number)
• Tests added and passed if fixing a bug or adding a new feature
• All code checks passed.
• Added type annotations to new arguments/methods/functions.
• Added an entry in the latest doc/source/whatsnew/vX.X.X.rst file if fixing a bug or adding a new feature.

[jbrockmendel]

@mroeschke is there a way to address the code smell of parsing error messages without making a ton of new public exceptions?

[mroeschke]

I agree with @jbrockmendel that ideally we don't want to just define a new exception subclass to solve this issue.

For now, parsing an exception message to raise the same exception type with a new message seems OK (but not ideal). I think it would be more worthwhile to target areas where we parse the error message and perform a different behavior or raise a new error type. For this class of behavior, ideally we can restructure internal code to return True/False or iron out the tree of functions that call other functions that may raise Exceptions.

All that being said, this is issue is very non-trival

[LirongMa]

I agree with @jbrockmendel that ideally we don't want to just define a new exception subclass to solve this issue.

For now, parsing an exception message to raise the same exception type with a new message seems OK (but not ideal). I think it would be more worthwhile to target areas where we parse the error message and perform a different behavior or raise a new error type. For this class of behavior, ideally we can restructure internal code to return True/False or iron out the tree of functions that call other functions that may raise Exceptions.

All that being said, this is issue is very non-trival

Got it. Let me see what I can do.