On 31 May 2018 at 02:41, Steven D'Aprano <steve@pearwood.info> wrote:

Since error messages are rarely part of the exception API, testing for
them is fragile and prone to errors. For example, what if the message
changes to "no money" or "out of funds" or "insufficient funds" or
"keine Mittel"? Since the error message is not part of the API, that can
happen at any time, without warning.

The messages are from constraint triggers in the database.

I'm the author of them.

The obvious way to do that is to create BeyondLimit and NoFunds
subclasses of DatabaseError. Why can't you do that?

Because I'm not the author of DatabaseError.

It's an ORM exception or a database driver class exception,

something I'd need to monkeypatch to change.

That seems like a backwards way to do it to me. If you're the author of
the exception class, why not just subclass your exceptions the regular
way and get a real subclass?

I agree. Problem is: I'm not the author of the exception class,

and I'm not raising/throwing their exception instances.

On 31 May 2018 at 04:19, Terry Reedy <tjreedy@udel.edu> wrote:

As Stephen said, messages are intentionally not part of the defined API. [...]

We could check error numbers instead of meaningful strings.

I'm thinking on technical error keys in either way.

Previously to classes like FileNotFoundError, we would need to check

an OSError errno. There were no alternative:

Python users are not the author of "everywhere that raises OSError".

Another example is urllib.error.HTTPError.

We can have a specific handler code for a given HTTP error code.

Yet we don't change urllib.request.urlopen to raise something else

for that specific error code.

On 31 May 2018 at 06:29, Stephan Houben <stephanh42@gmail.com> wrote:

"[...] The exception matching machinery ignores the __instancecheck__ mechanism."

The __subclasscheck__ gets bypassed, as well.

Danilo J. S. Bellini
---------------
"It is not our business to set up prohibitions, but to arrive at conventions." (R. Carnap)