Exceptions as New Style Classes

[Andrew]

Hi,
To satisfy my curiosity I was wondering if anyone knew if this
behaviour was intentional?
Is there a specific reason why exceptions are not allowed to be new
style classes?

Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32 bit (Intel)] on
win32

class OldException: pass
raise OldException() Traceback (most recent call last):
File "<stdin>", line 1, in ?
__main__.OldException: <__main__.OldException instance at 0x006AC490>
class NewException(object): pass
raise NewException()

Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: exceptions must be classes, instances, or strings
(deprecated), not NewException

[Steven Taschuk]

Quoth Andrew:

To satisfy my curiosity I was wondering if anyone knew if this
behaviour was intentional?
Is there a specific reason why exceptions are not allowed to be new
style classes?

It is intentional.

There are two difficulties with allowing new-style classes as
exception types. Ideas exist for dealing with them, but at the
moment none of them as been implemented.

Problem 1: Implicit instantiation. When the interpreter sees
raise x
it must determine whether x is a class or an instance, so it can
determine whether to instantiate it. (E.g., in
x = TypeError
raise x
instantiation will occur during the raise statement, whereas in
x = TypeError()
raise x
it will not.) The problem is that, with new-style classes, there
is no clear and strong distinction between classes and instances,
so it is not clear how the interpreter can make this decision.

Problem 2: It is probably not desirable to allow things like
raise 3
raise {'d': 17}
since raising such objects as ints and dicts (etc.) is very
unlikely to be anything but a bug in practice. (There are cases
in which you might want to do such things, but they are rare.)
However, there is (or will and should be) no clear and strong
distinction between, say, user-defined new-style classes and
built-in types, so it is not clear how the interpreter would
detect such cases and forbid them.

At the moment the dominant idea for solving these problems is to
make inheritance from Exception mandatory for exception types; see
Guido's 11 June post
<http://mail.python.org/pipermail/python-dev/2003-June/036162.html>
for details. (I have another idea involving a new special method
'__raise__', but haven't worked out the details yet.)

--
Steven Taschuk w_w
st******@telusplanet.net ,-= U
1 1

[Carl Banks]

Steven Taschuk wrote:

At the moment the dominant idea for solving these problems is to
make inheritance from Exception mandatory for exception types; see
Guido's 11 June post
<http://mail.python.org/pipermail/python-dev/2003-June/036162.html>
for details. (I have another idea involving a new special method
'__raise__', but haven't worked out the details yet.)

Why not give exceptions their own metaclass? So if type(x) is
ExceptionMetaclass, it's a class. If type(type(x)) is
ExceptionMetaclass, it's an instance. Otherwise, it's illegal to
raise it.
--
CARL BANKS

[Steven Taschuk]

Quoth Carl Banks:

Steven Taschuk wrote:

At the moment the dominant idea for solving these problems is to
make inheritance from Exception mandatory for exception types; see

[...] Why not give exceptions their own metaclass? So if type(x) is
ExceptionMetaclass, it's a class. If type(type(x)) is
ExceptionMetaclass, it's an instance. Otherwise, it's illegal to
raise it.

That seems workable. (I'd prefer, though, to test
isinstance(type(x), ExceptionMetaclass)
and likewise for the second case.)

I'm not sure what it gains us, though, over the idea of mandatory
inheritance from Exception. Am I missing something?

--
Steven Taschuk st******@telusplanet.net
"Telekinesis would be worth patenting." -- James Gleick

[Carl Banks]

Steven Taschuk wrote:

Quoth Carl Banks:

Steven Taschuk wrote:

> At the moment the dominant idea for solving these problems is to
> make inheritance from Exception mandatory for exception types; see

[...]

Why not give exceptions their own metaclass? So if type(x) is
ExceptionMetaclass, it's a class. If type(type(x)) is
ExceptionMetaclass, it's an instance. Otherwise, it's illegal to
raise it.

That seems workable. (I'd prefer, though, to test
isinstance(type(x), ExceptionMetaclass)
and likewise for the second case.)

I'm not sure what it gains us, though, over the idea of mandatory
inheritance from Exception. Am I missing something?

Probably not much, unless you think you want to raise exceptions that
aren't subclasses of Exception.
--
CARL BANKS

[Michael Hudson]

Steven Taschuk <st******@telusplanet.net> writes:

Quoth Andrew:

To satisfy my curiosity I was wondering if anyone knew if this
behaviour was intentional?
Is there a specific reason why exceptions are not allowed to be new
style classes?

It is intentional.

There are two difficulties with allowing new-style classes as
exception types. Ideas exist for dealing with them, but at the
moment none of them as been implemented.

They have, in PyPy! (which doesn't do old-style classes at all, at
present).

IIUC, Guido thought what PyPy does would be sensible enough for
CPython, but I don't know what the timeframe might be.

Cheers,
mwh

--
This is not to say C++ = bad, Lisp = good. It's to say
C++ = bad irrespective of everything else.
-- Alain Picard, comp.lang.lisp

[Steven Taschuk]

Quoth Carl Banks:

Steven Taschuk wrote:

Quoth Carl Banks: [...]

Why not give exceptions their own metaclass? So if type(x) is
ExceptionMetaclass, it's a class. If type(type(x)) is
ExceptionMetaclass, it's an instance. Otherwise, it's illegal to
raise it.

[...] I'm not sure what it gains us, though, over the idea of mandatory
inheritance from Exception. Am I missing something?

Probably not much, unless you think you want to raise exceptions that
aren't subclasses of Exception.

I would have thought that having to raise instances of classes
which are instances of ExceptionMetaclass would be just as onerous
as having to raise instances of Exception.

class MyRaisable(Exception):
# ...

class MyRaisable(object):
__metaclass__ = ExceptionMetaclass
# ...

I suppose Exception could have behaviour you don't want, in which
case the latter might be preferable.

--
Steven Taschuk st******@telusplanet.net
"Our analysis begins with two outrageous benchmarks."
-- "Implementation strategies for continuations", Clinger et al.