Exception Handling in Python 3

[John Nagle]

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