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.
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),
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
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
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
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
>
> 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
>
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
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
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
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
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
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
>
> 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
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
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
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
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
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
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,
20 matches
Mail list logo
