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 [email protected] https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
