Paul Moore wrote:

What's wrong with defining a custom exception? It's literally one line: `class InvalidStateError(Exception): pass`. Two lines if you want to put the `pass` on its own line. The built in exceptions are ones that are raised by the core interpreter. Even the stdlib doesn't get builtin exceptions, look at sqlite3.Error, for example. Defining a custom exception in the module alongside the function that raises it is both normal practice, and far more discoverable. Paul On Thu, 1 Sept 2022 at 22:42, Steve Jorgensen stevecjor@gmail.com wrote:

...

I frequently find that I want to raise an exception when the target of a call is not in an appropriate state to perform the requested operation. Rather than choosing between `Exception` or defining a custom exception, it would be nice if there were a built-in `InvalidStateError` exception that my code could raise. In cases where I want to define a custom exception anyway, I think it would be nice if it could have a generic `InvalidStateError` exception class for it to inherit from. Of course, I would be open to other ideas for what the name of this exception should be. Other possibilities off the top of my head are `BadStateError` or `StateError`. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/NMHNKS... Code of Conduct: http://python.org/psf/codeofconduct/

OK, but by that logic, why do we have standard exceptions like `ValueError` when we could define custom exceptions for the cases where that should be raised?

On Thu, Sep 1, 2022 at 2:57 PM Jean Abou Samra wrote:

How would a "state error" differ from this more precisely? What value would this new exception type add? Both ValueError and this proposed StateError are very generic.

Some examples: * a stream-like object that has been closed and you attempt to read from or write data to it. * a random number generator that has not been initialized with a seed (in the case where you have a constructor which doesn't also initialize it). * a hash function which you try to compute the digest without having added any data to it. In all these cases, the current call fails because a *previous* call was not done. The parameters to this invocation are not by themselves incorrect. --- Bruce

Jean Abou Samra wrote:

...

I frequently find that I want to raise an exception when the target of a call is not in an appropriate state to perform the requested operation. Rather than choosing between `Exception` or defining a custom exception, it would be nice if there were a built-in `InvalidStateError` exception that my code could raise. In cases where I want to define a custom exception anyway, I think it would be nice if it could have a generic `InvalidStateError` exception class for it to inherit from. Of course, I would be open to other ideas for what the name of this exception should be. Other possibilities off the top of my head are `BadStateError` or `StateError`. https://docs.python.org/3/library/exceptions.html#ValueError states that ValueError is “Raised when an operation or function receives an argument

Le 01/09/2022 à 23:40, Steve Jorgensen a écrit : that has the right type but an inappropriate value, and the situation is not described by a more precise exception such as |IndexError| https://docs.python.org/3/library/exceptions.html#IndexError.” How would a "state error" differ from this more precisely? What value would this new exception type add? Both ValueError and this proposed StateError are very generic.

`ValueError` is about for when the value of an argument passed to the function is unacceptable. The exception that I propose would be for when there is nothing wrong with any argument value, but the object is not in the correct state for that method to be called. I should have provided an example. One example is when trying to call methods to interact with a remote system either before a connection has been made or after the connection has been terminated.

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.

On Fri, 2 Sept 2022 at 10:51, Steve Jorgensen wrote:

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.

It depends on context whether it makes sense to define a custom exception, and I agree that I frequently should define a custom exception. In that case though, it would still be nice to have an appropriate generic exception for that to inherit from, just as I would inherit from `ValueError` for a special case of a value error.

Can you describe a situation where you'd want to catch InvalidStateError from two unrelated libraries at the same time? That's the main value of an exception hierarchy - you don't have to worry about exactly which part of a block of code raised LookupError, you just catch it and cope (eg if you delve deep into a complex structure that has both lists and dicts, you can "except LookupError: not_found()" without caring which one failed). TBH I'm actually a bit confused as to how you'd cope with InvalidStateError anyway. In what situations would you be able to recover from such an error (other than generic "log the error and continue", which works fine with "except Exception")? ChrisA

It depends on context whether it makes sense to define a custom exception, and I agree that I frequently should define a custom exception. In that case though, it would still be nice to have an appropriate generic exception for that to inherit from, just as I would inherit from `ValueError` for a special case of a value error.

I agree. But I don't see why that more specific root needs to live in the standard library?

On Fri, Sep 02, 2022 at 12:53:47AM -0000, Steve Jorgensen wrote:

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.

Your API shouldn't allow the object to be created and returned until it has been started. Long ago I read a great blog post describing this idiom as an anti-pattern: obj = SomeObject(args) obj.make_it_work() obj.do_something() where constructing the object isn't sufficient to start using it, you have to call a second, magical method (sometimes called "init()"!) to make it actually usable. Unfortunately I lost the URL and have never been able to find it again, but it made a big impression on me. You will notice that we don't do that with Python builtins: # we don't do this! f = open('filename', 'w') f.open() # Actually open it for writing. f.write('stuff') # Or this: d = dict(key=value) d.init() # Can't use the dict until we make it work. d.update(something) Returning a dict in an initialiated but invalid state, which needs a second method call to make it valid, would be an obvious antipattern. Why would we do such a thing? Its a bad design! Just have the dict constuctor return the dict in the fully valid state. Which of course we do: for most (all?) objects in the stdlib, creating the object *fully* initialises it, so it is ready to use, immediately, without needing a special "make it work" method call. Of course there may be some exceptions to that rule, but they are uncommon.

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.

Perhaps you should take your lead from file objects and inherit from ValueError. Trying to interact with a terminated process is analogous to writing to a closed file. What sort of features or APIs do you expect to inherit from this InvalidStateError class? -- Steve

Steven D'Aprano writes:

A closed file is not *invalid*, it is just closed.

I think it's not very useful to focus on the individual words used here. I believe that Steve J's idea here is related to the fact that an object is a namespace and an environment. So the operation is not "read from specified file", it's "read as appropriate in the specified environment" (duck-typing), so the state of the environment of the call (which is the implicit argument "self") is invalid. I myself would argue it's not that the environment is in an invalid state for reading, but that reading is an invalid operation on a closed file. I note that XEmacs Lisp's docstring for the error function says: `invalid-operation' refers to all cases where code is trying to do something that's disallowed, or when an error occurred during an operation. (These two concepts are merged because there's no clear distinction between them.) I want to emphasize the remark in parentheses. It's frequently *very* difficult to make distinctions that will be clear to all users of the API, or even to all API users named "Steve". :-) In my personal opinion, the XEmacs Lisp hierarchy does a good job of specifying a hierarchy that lends itself to clear distinctions. YMMV on whether that hierarchy is a good one, but I think the point is important: there are no absolutes here, rather the quality of a distinction is relative to the rest of the hierarchy, it depends on how well it fits in. Bottom line: let's focus the argument on (1) where in the Python exception hierarchy the new builtin exception would go, and (2) per Paul Moore, if it could be used in the interpreter (I will add, or in a variety of stdlib modules), and where.