Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!newsfeed.xs4all.nl!newsfeed5.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Return-Path: <rosuav@gmail.com>
X-Original-To: python-list@python.org
Delivered-To: python-list@mail.python.org
X-Spam-Status: OK 0.007
X-Spam-Evidence: '*H*': 0.99; '*S*': 0.00; 'exception': 0.03; 'exception.': 0.07; 'exception,': 0.09; 'globals': 0.09; 'instruction.': 0.09; 'option:': 0.09; 'propagate': 0.09; 'received:mail-vc0-f174.google.com': 0.09; 'retry': 0.09; 'from:addr:rosuav': 0.16; 'from:name:chris angelico': 0.16; 'oct': 0.16; 'optionally': 0.16; 'reason.': 0.16; 'used:': 0.16; 'wrote:': 0.17; 'thu,': 0.17; 'handles': 0.18; 'memory': 0.18; 'sort': 0.21; 'raise': 0.24; 'idea': 0.24; 'external': 0.24; 'tried': 0.25; 'header:In-Reply-To:1': 0.25; 'handling': 0.27; 'implemented': 0.27; 'possibly': 0.27; 'dos': 0.27; 'message- id:@mail.gmail.com': 0.27; 'changed.': 0.29; "d'aprano": 0.29; 'received:209.85.220.174': 0.29; 'steven': 0.29; 'usually': 0.30; 'function': 0.30; 'primary': 0.30; 'code': 0.31; '(and': 0.32; 'gets': 0.32; 'file': 0.32; 'structure': 0.32; 'getting': 0.33; 'function.': 0.33; 'his/her': 0.33; 'handle': 0.33; 'problem': 0.33; 'to:addr:python-list': 0.33; 'received:google.com': 0.34; 'third': 0.34; 'whatever': 0.35; 'fail': 0.35; 'pm,': 0.35; 'received:209.85.220': 0.35; 'subject:?': 0.35; 'received:209.85': 0.35; 'something': 0.35; 'there': 0.35; 'but': 0.36; 'subject:with': 0.36; 'should': 0.36; 'option': 0.37; 'why': 0.37; 'usual': 0.37; 'virtual': 0.37; 'received:209': 0.37; 'subject:: ': 0.38; 'some': 0.38; 'several': 0.39; 'to:addr:python.org': 0.39; 'where': 0.40; 'header:Received:5': 0.40; 'address': 0.60; 'save': 0.61; 'back': 0.62; 'more': 0.63; 'here': 0.65; 'believe': 0.69; 'power': 0.74; 'prompt': 0.78; 'interrupt': 0.84; 'received,': 0.84; 'thrown,': 0.84; 'disks,': 0.91
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=lxQ3uOCGAjCt/KJI6JlTaNJHhJvUjPahmlK15EyebT8=; b=QNSx88Ch00HXCVhRFh2jy3RQLd999rzdLCR2huGstpTeD7u/nH4beToNgNNeCA3t2z PsvT3VvgatX4kNrB3S66GIR1eQX4OsnxYSWw5gXQ3qVHMO2TRtLnQG2GrwsK991ulniq 5GtZJDZ51bXNGoom1gbQiRq3yAqx8kfrSUDpq5TKBwIT8uz/stWPyUOVPC4I8D7JZpnx a1uUhSXCmCEgEJvifUQria0EC7rrQCPU1/g3IMa0tmd4EElNXa+mF7/0T1Xz+pW+zlJr dR+SNmt/cbska0jWxkMU7fbIPwNkZiXlfb2ZiFc2luvEXy8M2onH5IbDYLSGgilJ0lJx 15Lg==
MIME-Version: 1.0
In-Reply-To: <5088929e$0$29978$c3e8da3$5496439d@news.astraweb.com>
References: <mailman.2758.1351083094.27098.python-list@python.org> <5088929e$0$29978$c3e8da3$5496439d@news.astraweb.com>
Date: Fri, 26 Oct 2012 01:51:43 +1100
Subject: Re: resume execution after catching with an excepthook?
From: Chris Angelico <rosuav@gmail.com>
To: python-list@python.org
Content-Type: text/plain; charset=ISO-8859-1
X-BeenThere: python-list@python.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion list for the Python programming language <python-list.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/options/python-list>, <mailto:python-list-request@python.org?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/python-list/>
List-Post: <mailto:python-list@python.org>
List-Help: <mailto:python-list-request@python.org?subject=help>
List-Subscribe: <http://mail.python.org/mailman/listinfo/python-list>, <mailto:python-list-request@python.org?subject=subscribe>
Newsgroups: comp.lang.python
Message-ID: <mailman.2845.1351176706.27098.python-list@python.org>
Lines: 33
NNTP-Posting-Host: 2001:888:2000:d::a6
X-Trace: 1351176706 news.xs4all.nl 6929 [2001:888:2000:d::a6]:49288
X-Complaints-To: abuse@xs4all.nl
Xref: csiph.com comp.lang.python:32130

On Thu, Oct 25, 2012 at 12:15 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> I don't believe that there is any
> way to jump back to the line of code that just failed (and why would you,
> it will just fail again)

There are several reasons to retry something after an exception,
mainly if some external state gets changed. Virtual memory is usually
implemented using traps, so the OS handles an interrupt by paging
something in from the disk, then retrying the "failing" instruction.
The old-favorite "Abort, retry, ignore[, fail]?" prompt from DOS has
the same notion; you tried to save a file onto a write-protected
floppy disk, an exception is thrown, you handle the exception by
getting the user to unprotect or change disks, and you resume where
you left off. CPU-level interrupts always have a return address for
that exact reason.

Handling Ctrl-C in this way makes a lot of sense. Give the user the
option to try to abort, but then to optionally change his/her mind and
keep going. Or possibly have a third option: break out of the current
operation and go back to some primary loop (throw the exception and
let it be caught at the main loop).

Arguably the problem here is that KeyboardInterrupt is an exception.
Perhaps a more classic signal handling structure should be used: when
signal received, call function. That function then has the power to
raise an exception, which will propagate through whatever code is
currently executing. This sort of thing would have all the usual
dangers of signal handlers, though; you have NO IDEA what state the
program's in, so you have to be ubercareful of what globals you use or
change.

ChrisA