Mailing List Archive

Gerrit Holl wrote:
>
> can someone please give me an example when a RuntimeError is raised?

At a guess I'd say it's a base class from which
other runtime error classes are derived, and
isn't actually raised itself.

Greg

[Gerrit Holl]
> can someone please give me an example when a RuntimeError is raised?
>
> I don't understand: if none of the others are raised.

Python 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] on win32
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import sys
>>> del sys.stdout
>>> print "hi"
Traceback (innermost last):
File "<stdin>", line 1, in ?
RuntimeError: lost sys.stdout
>>>

Honestly, I had never seen a RuntimeError before! I found this one by
digging thru the source code to see when it gets raised. There's really no
pattern to it, and the RuntimeError docstring in Lib/exceptions.py
("Unspecified run-time error.") is as accurate as anything that says nothing
can be <wink>. It generally seems to mean something bad and unexpected
happened, but not bad enough to shut down the interpreter (things *that* bad
raise SystemError).

more-art-than-science-here-ly y'rs - tim

On Sun, Jun 27, 1999 at 10:27:04PM -0400, Tim Peters wrote:
> From: "Tim Peters" <tim_one@email.msn.com>
> To: "Gerrit Holl" <gerrit.holl@pobox.com>, <python-list@python.org>
> Subject: RE: RuntimeError?
> Date: Sun, 27 Jun 1999 22:27:04 -0400
>
> [Gerrit Holl]
> > can someone please give me an example when a RuntimeError is raised?
> >
> > I don't understand: if none of the others are raised.
>
> Python 1.5.2 (#0, Apr 13 1999, 10:51:12) [MSC 32 bit (Intel)] on win32
> Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
> >>> import sys
> >>> del sys.stdout
> >>> print "hi"
> Traceback (innermost last):
> File "<stdin>", line 1, in ?
> RuntimeError: lost sys.stdout
> >>>
>
> Honestly, I had never seen a RuntimeError before! I found this one by
> digging thru the source code to see when it gets raised. There's really no
> pattern to it, and the RuntimeError docstring in Lib/exceptions.py
> ("Unspecified run-time error.") is as accurate as anything that says nothing
> can be <wink>. It generally seems to mean something bad and unexpected
> happened, but not bad enough to shut down the interpreter (things *that* bad
> raise SystemError).
>

Ah, I understand. But what kind of things are bad enough to raise SystemError?
core dump?

groeten,
Gerrit.

--
The Dutch Linuxgames homepage: http://linuxgames.nl.linux.org
Personal homepage: http://www.nl.linux.org/~gerrit/

Discoverb is a python program (in several languages) which tests the words you
learned by asking it. Homepage: http://www.nl.linux.org/~gerrit/discoverb/

Gerrit Holl wrote in message <19990628105921.A26266@optiplex.palga.uucp>...

>> can be <wink>. It generally seems to mean something bad and unexpected
>> happened, but not bad enough to shut down the interpreter (things *that*
bad
>> raise SystemError).

Actually, I dare to correct Tim on this point. SystemErrors typically will
_not_ shutdown the interpreter (they used to, but not any more!)

>Ah, I understand. But what kind of things are bad enough to raise
SystemError?
>core dump?

My take is this: RuntimeError is raised in a situation that could not
reasonably have been predicted by the programmer (eg, someone deleting
sys.stdout). A SystemError OTOH usually means an internal Python error
(Python or an extension). The most common example of a SystemError that I
see is when an extension module returns NULL but doesnt set a Python
exception - ie, a bug that needs to be fixed by the original programmer, and
nothing the end user could do would prevent this. (roughly speaking, of
course :-)

A core dump is unfortunately (or fortunately depending on your POV) not
mapped to a Python exception.

Mark.

[.RuntimeError ... generally seems to mean something bad and unexpected
happened, but not bad enough to shut down the interpreter (things *that*
bad raise SystemError).
]

[Gerrit Holl]
> Ah, I understand. But what kind of things are bad enough to raise
> SystemError? core dump?

>>> print SystemError.__doc__
Internal error in the Python interpreter.

Please report this to the Python maintainer, along with the traceback,
the Python version, and the hardware/OS platform and version.
>>>

That means something has happened Python can't figure out -- it's a problem
in Python itself (or in some C code you wrote to extend Python), not a
problem in your Python code. This is the kind of thing that *could* cause a
core dump (or other random damage) if Python didn't check for it first.
It's hard to give you an example, since if I could I'd have to report it to
the Python maintainer and he'd fix it before you could reproduce it <wink>.

Core dumps are even worse -- that's something so bad Python didn't even
check for it first, or didn't check for it correctly. For example, if you
have unbounded recursion:

def f():
f()
f()

Python does check how many levels deep f calls itself, and raises an
exception if it gets "too deep". Under Windows, though, the check in 1.5.2
doesn't quite work, and Python dies with a stack overflow in the operating
system. Python never wants that to happen! There's no chance for your
Python program to recover from it.

read-Lib/exceptions.py-for-more-entertainment-ly y'rs - tim

Tim Peters writes:
> Honestly, I had never seen a RuntimeError before! I found this one by

Ooh, lucky you! ;-) Actually, I've seen very few.

> digging thru the source code to see when it gets raised. There's really no
> pattern to it, and the RuntimeError docstring in Lib/exceptions.py

When RuntimeError is raised by the interpreter itself, that seems to
be the case. When documenting modules, I've seen that a lot of them
do things like "raise RuntimeError" (note: no parameters) whenever
they need to raise an exception and the programmer hadn't already
defined an exception specific to the module. I consider this a real
problem, since it becomes hard to catch just the right exception. The
ones I've seen in modules didn't seem to be so serious, just lazy
about defining new exceptions the might only get used in one place.
I've not maintained a list of where I've see this, unfortunately:
fixing them would be a worthwhile activity.


-Fred

--
Fred L. Drake, Jr. <fdrake@acm.org>
Corporation for National Research Initiatives

From: "Fred L. Drake" <fdrake@cnri.reston.va.us>


Tim Peters writes:
> Honestly, I had never seen a RuntimeError before! I found this one by

Ooh, lucky you! ;-) Actually, I've seen very few.

> digging thru the source code to see when it gets raised. There's really no
> pattern to it, and the RuntimeError docstring in Lib/exceptions.py

When RuntimeError is raised by the interpreter itself, that seems to
be the case. When documenting modules, I've seen that a lot of them
do things like "raise RuntimeError" (note: no parameters) whenever
they need to raise an exception and the programmer hadn't already
defined an exception specific to the module. I consider this a real
problem, since it becomes hard to catch just the right exception. The
ones I've seen in modules didn't seem to be so serious, just lazy
about defining new exceptions the might only get used in one place.
I've not maintained a list of where I've see this, unfortunately:
fixing them would be a worthwhile activity.


-Fred

--
Fred L. Drake, Jr. <fdrake@acm.org>
Corporation for National Research Initiatives