[Python-ideas] Re: Add InvalidStateError to the standard exception hierarchy

[Bluenix]

I am not sure this is necessary: RuntimeError already encapsulates this 
somewhat well. You'll find RuntimeError already widely used, especially in 
concurrency where it is easy to get into a situation where the state is invalid 
for a specific action.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/I5YZI5KV4NNQBZWLEIXCKVCI3SECJEVI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add InvalidStateError to the standard exception hierarchy

[Chris Angelico]

On Fri, 2 Sept 2022 at 23:08, Stephen J. Turnbull
 wrote:
> 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.

And if not (2), then (3) whether there's actually value in being able
to catch invalid state exceptions from different sources, because a
core exception that isn't used by the stdlib could potentially have
value for that, but otherwise it's better for each module to make its
own.

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/WXGVBR673SWNLQOVSDQN5OCQ22DVWHWG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add InvalidStateError to the standard exception hierarchy

[Stephen J. Turnbull]

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.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/4L6WJ2HC6EN4YNIFORIVIRDUARUQG4XT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add InvalidStateError to the standard exception hierarchy

[Steven D'Aprano]

On Fri, Sep 02, 2022 at 12:53:47AM -, 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
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/SCTMGDJZ3THNN4EJDBTYJUV5XW77YTQD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add InvalidStateError to the standard exception hierarchy

[Steven D'Aprano]

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
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/4FDFLQ5S2XHP2L3UACW2S2UMWRBQNKKZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add InvalidStateError to the standard exception hierarchy

[Steven D'Aprano]

On Thu, Sep 01, 2022 at 03:11:29PM -0700, Bruce Leban wrote:

> * a stream-like object that has been closed and you attempt to read from or
> write data to it.

That would be a ValueError:

>>> f.write('a')
Traceback (most recent call last):
  File "", line 1, in 
ValueError: I/O operation on closed file.

Its arguable that this could (should?) have been some sort of IOError 
instead, but that ship has sailed.


> * 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).

That would be a bug in the constructor.


> * a hash function which you try to compute the digest without having added
> any data to it.

That shouldn't be an error at all:

>>> a = hashlib.sha256()
>>> a.hexdigest()
'e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855'


-- 
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/4XGZ7XDM5TOJPTEHQ44PBVCPQB6BJOOJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add InvalidStateError to the standard exception hierarchy

[Matthias Görgens]

>
> 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?
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/OWERIZIM6NEAEFOAJFXWLU4DOBNPXJBS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add InvalidStateError to the standard exception hierarchy

[Stephen J. Turnbull]

Steve Jorgensen writes:
 > Paul Moore wrote:

 > > The built in exceptions are ones that are raised by the core interpreter.

 > 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?

I get 154 hits for PyExc_ValueError in cpython/Python.  That's exactly
the logic that Paul mentions. :-)

I suspect that the reason that there is no PyExc_InvalidStateError is
that the interpreter rarely can detect it.  For example, in the
following very contrived example

def getcontents(file):# argument should be "filename"
# Oops, forgot to open the file named by `file`.
return file.read()

you'll get an AttributeError.  If you typecheck `file` at the top of
the function, ValueError is appropriate.  It's not hard to contrive a
case where you can detect it:

>>> with open(RandomExistingFile) as f:
...  f.close()
...  f.read()
... 
Traceback (most recent call last):
  File "", line 3, in 
ValueError: I/O operation on closed file.

and Python chooses to shoehorn the round InvalidStateError peg into
the square ValueError hole.  This isn't entirely implausible in
Python's implementation of object-oriented programming: the object `f`
is an invalid value for the `self` argument of the read function.

So, assuming you use this "it's in the interpreter" logic in
advocating this new Error, I would say collect examples of other
errors raised where you would prefer InvalidStateError.  If they're
consistently ValueError, I would say you have a case.  Probably you
need to derive InvalidStateError from ValueError for backward
compatibility.

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/MZQQVUWFB5P35EBYPL2TJRUE5OCQ7XB3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add InvalidStateError to the standard exception hierarchy

[David Mertz, Ph.D.]

On Thu, Sep 1, 2022, 9:12 PM Chris Angelico

> > 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?
>
> 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")?
>

I'm +0 on this. Maybe +0.5.

Making a custom error isn't hard, but inheriting from something more in the
ballpark is nicer.  Doing `except Exception ` feels very likely to be too
broad.

If my code hits ZeroDivisionError, I probably want to do something
different than I do for an ended subprocess or a closed file. Maybe they
all are just "log and continue," sure.

But for many resources, it's possible to require them, or at least
something functionally equivalent/usable. Maybe *that* subprocess ended,
but I might be able to launch another with suitable behavior. Maybe *that*
file handle is closed, but I can reopen the same file.

>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/OX4L4SBH3GIHEL5XJ3GXGLCLMMMOCGR5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add InvalidStateError to the standard exception hierarchy

[Chris Angelico]

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
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/TP7BQXFXYEOULI3F4GY734YCK77XFXNO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add InvalidStateError to the standard exception hierarchy

[Steve Jorgensen]

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 stevec...@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-le...@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?
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/5JGBBE7JEKWYPEQO6NC4B7UFKJN2UK6K/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add InvalidStateError to the standard exception hierarchy

[Steve Jorgensen]

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.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/YC62WQIXUTM3ULVA64SBXBS5YZ3M2XGT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add InvalidStateError to the standard exception hierarchy

[Steve Jorgensen]

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.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/GNBFLWNXWBV54C73MOZJDEXJPDIOVBGM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add InvalidStateError to the standard exception hierarchy

[Matthias Görgens]

>
> 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.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/F7YKSRESIZV6R7BGUDUFOH6VUBPEIEWV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add InvalidStateError to the standard exception hierarchy

[Steven D'Aprano]

On Thu, Sep 01, 2022 at 09:40:05PM -, Steve Jorgensen 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.

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.

I believe that the interpreter may sometimes raise RuntimeError for 
cases where objects are in a broken internal state, but I've never seen 
one in real life. Oh, no, I was thinking of SystemError. Nevertheless, 
for my own classes, I've sometimes used RuntimeError for broken internal 
state. I have always considered that a bug in my code.

> 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.

What functionality do you expect this InvalidStateError superclass to 
provide that isn't already provided by Exception?


-- 
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/IZ7MFY36GYPMW5XPCUHZRRUB6GMK26EH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add InvalidStateError to the standard exception hierarchy

[Steve Jorgensen]

Jean Abou Samra wrote:
> Le 01/09/2022 à 23:40, Steve Jorgensen a écrit :
> > 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
> 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.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/W2G5XNWKS6KHXSCH45QPLFRUMZIVNS4L/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add InvalidStateError to the standard exception hierarchy

[Bruce Leban]

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
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/XREF2WPN7HW5TBTORERQJFUEJXKOUPJB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add InvalidStateError to the standard exception hierarchy

[Jean Abou Samra]

Le 01/09/2022 à 23:40, Steve Jorgensen a écrit :

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
that has the right type but an inappropriate value, and the situation is
not described by a more precise exception such as |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.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/RDFDFU4O2AIPWWOXX5G772T33DAHQEOU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add InvalidStateError to the standard exception hierarchy

[Bruce Leban]

Java calls this IllegalStateException so I would suggest IllegalStateError.

Looking at other exceptions that Java has, it would also be nice to
have UnsupportedOperationError (I have used NotImplementedError for this
but that suggests it might someday be implemented).

On the other hand, as you noted, it's fairly trivial to implement new
exceptions where needed.

--- Bruce




On Thu, Sep 1, 2022 at 2:41 PM Steve Jorgensen  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-le...@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/NMHNKSEZG7UZ6AIFTVGQXVECCNYYVODT/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/R56RBM25NENOV6DPCZ6SUD325BGJS26S/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Add InvalidStateError to the standard exception hierarchy

[Paul Moore]

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  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-le...@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/NMHNKSEZG7UZ6AIFTVGQXVECCNYYVODT/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/KIVLJIBG73RLV7AREYVSKSOBC3V43YUR/
Code of Conduct: http://python.org/psf/codeofconduct/