Matthias Görgens wrote:
If the target of the call isn't in an appropriate state, isn't that a bug in the constructor that it allows you to construct objects that are in an invalid state? You should fix the object so that it is never in an invalid state rather than blaming the caller. You can't really do that with files that have been closed. Unless you disallow manual closing of files altogether. That being said, I'd suggest that people raise custom exception, so your callers can catch exactly what they want to handle. An generic exception like ValueError or the proposed InvalidStateError could be thrown by almost anything you call in your block, instead of just what you actually intend to catch.
I didn't say that I was talking about a file. In fact, today, I'm talking about an object that manages a subprocess. If a caller tries to call a method of the manager to interact with the subprocess when the subprocess has not yet been started or after it has been terminated, then I want to raise an appropriate exception. I am raising a custom exception, and it annoys me that it has to simply inherit from Exception when I think that an invalid state condition is a common enough kind of issue that it should have a standard exception class in the hierarchy.