Problem with Unittest:

Terry Reedy tjreedy at udel.edu
Tue May 13 20:05:49 EDT 2003


"Francis Avila" <francisgavila at yahoo.com> wrote in message
news:vc2snuamt8cn1f at corp.supernews.com...
>
> "Terry Reedy" <tjreedy at udel.edu> wrote in message
> news:88ycnaV9r5MLqlyjXTWcog at comcast.com...
> > Bad advice, I believe.  When you raise an exception class, it is
> > converted to an exception instance which is tested against the
classes
> > listed in except statements with isinstance().
>
> But that seems completely backwards to me.  I thought raising
instances was
> depreciated (ok, "discouraged") when we switched over to exception
classes
> instead of strings.  And so now we raise classes instead of (for now
only
> conceptually) instances of string objects.  It would seem instead
that
> raising *instances* (including all the now-builtin types) would be
> depreciated, and only classes could be raised, which are implicitly
> instantiated before being tossed up.  Is the suggestion really that
every
> raise statement be
>
> raise Exception(arg)

This is how one creates a class instance everywhere else in Python,
and optionally here.

> instead of
>
> raise Exception, arg

This is the only place in Python where a class instance is created
with this syntax.
So yes, I would like to see this exceptional and unnecessary duplicate
syntax considered for deprecation (along with string exceptions).

> won't except statements *require* a class rather than a instance?

Except statements 'receive' a class instance which is checked against
the class-or-tuple with isinstance(instance, class-or-tuple).  Again,
the exception object bound to the name you give after the ',' is the
instance, not its class.  I find it easier to remember this if I
directly create the instance in the first place.  The time saving of
typing ', ' instead of '(' and ')' is not, to me, worth the confusion.

> In any case, I was completely wrong about what the OP's problem was:
the

Yeah, this is off-topic, but I think he got enough on-topic advice to
move forward, at least to his next problem.

Terry J. Reedy






More information about the Python-list mailing list