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 s
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
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 close
>
> 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
> `ValueEr
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
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 t
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 ca
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 ca
>
> 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 t
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 w
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 exce
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 a
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 w
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 no
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, loo
20 matches
Mail list logo
