On 10/23/2010 10:42 PM, Steve Holden wrote:
On 10/24/2010 1:26 AM, Chris Rebert wrote:
I was somewhat surprised to discover that Python 3 no longer
allows an
exception to be raised in an except clause (or rather that it
reports it as a separate exception that occurred during the
handling of the first).
<snip>
[snip]
What is the correct paradigm for this situation?
There doesn't seem to be one at the moment, although the issue
isn't very serious. Your Traceback is merely being made slightly
longer/more complicated than you'd prefer; however, conversely,
what if a bug was to be introduced into your exception handler?
Then you'd likely very much appreciate the "superfluous" Traceback
info.
Your quandary is due to the unresolved status of the "Open Issue:
Suppressing Context" in PEP 3141
(http://www.python.org/dev/peps/pep-3134/ ). I guess you could
start a discussion about closing that issue somehow.
This is a traceback issue only, right? The semantics of
the code below shouldn't change in Py3.x, I hope:
try :
...
try :
x = 1/0 # in a real program, input data might cause a problem
except ZeroDivisionError as msg:
raise RuntimeError("Math error on problem: " + str(msg))
except RuntimeError as msg :
print("Trouble: " + str(msg))
I have code where I'm reading and parsing a web page,
a process which can produce a wide range of errors. A try-block
around the read and parse catches the various errors and creates a
single user-defined "bad web page" exception object, which is then
raised. That gets caught further out, and is used to record the
troubled web page, schedule it for a retest, and such. This is
normal program operation, indicative of external problems, not a
code error or cause for program termination with a traceback.
Are exception semantics changing in a way which would affect that?
John Nagle
--
http://mail.python.org/mailman/listinfo/python-list
