On Fri, Sep 02, 2022 at 06:49:37AM +0800, 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.
Files are not *constructed* in a closed state, or at least `open` doesn't return file objects that have to be closed. They are returned in an open state. Files can be closed afterwards. A closed file is not *invalid*, it is just closed. Typical file APIs go back to the earliest days of computing, long before object oriented programming was a thing, and we're stuck with them. If we were designing file I/O from scratch today, we might not have any such concept of open and closed files. But regardless, we don't need an InvalidStateError exception for closed files, because (1) they're not invalid, and (2) we already have an exception for that, ValueError. As I mentioned in a previous post, perhaps that should have been some sort of IOError, but we're stuck with ValueError. -- Steve