I occasionally found situations where I want to raise an exception for
errors that can only arise because the developer made a mistake, for
example:

- an abstract method is supposed to be reimplemented and its execution
is supposed to leave some internal constraints of an object unchanged,
but these are instead violated.
- an impossible "else" condition after an if/elif, where the else
cannot simply happen unless someone really screwed up the internal
state of the object.

In general, when these cases happen, I use RuntimeError, but other
people may choose otherwise. I've also seen ValueError, plain
Exception or a specifically made subclass used in these cases.
Whatever the choice is, it generally lacks clarity of communication to
whoever receives it.
RuntimeError is a rather generic exception according to the
documentation, and you can only rely on the message, which relies on
writing something appropriate for the situation:

```
exception RuntimeError
Raised when an error is detected that doesn’t fall in any of the other
categories. The associated value is a string indicating what precisely
went wrong.
```

while it would be useful to communicate clearly to whoever is using or
modifying the code "listen, it's your mistake, you misunderstood how I
work or you ruined my internals, leading me to an impossible state".
Also, customers seeing this kind of exception would understand without
a doubt that the application is broken because of an internal error.

I tried some search on the mailing list but could not find anything at
a glance about this topic. Was this already discussed in the past?

Thanks

-- 
Kind regards,

Stefano Borini
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to