Try, except...retry?

[Robert Brewer]

Peter Otten wrote:
> the first variant appears much clearer in that it
> has only code in the try clause that is actually
> supposed to fail.

I can understand that. It's my current, usual way of dealing with it.

> Also, in
> 
> try:
>     setWeapon("Doug", u"satire")        
> except KeyError:
>     allPiranhas["Doug"] = Goldfish()
>     retry
> 
> where would you want to jump?
> Should setWeapon() be executed in a way similar to generators,
> saving its state in case of an exception instead of a yield?

I assume you mean "where would you want to jump" upon the "retry"
statement? My intuition tells me: start the try block over again. Don't
muck about with saving (or clearing) state, either in far scopes or the
local one. If it's going to "work", it's got to follow the language, not
fight it. That was the problem with VB's Resume, IMO--humans having to
do a lot of work sometimes to determine what was "next". But of course
the VB error model demands goto's for any serious error recovery
process.

> Sometimes you can *not* execute a statement 
> twice in a reliable manner.

This is, I think, a moot issue, since the programmer must answer this
question regardless of the existence of retry. One must understand the
reentry problems in "the while loop solution" to an *identical* extent.
The only things retry buys the programmer are development time,
readability, and LOC. The important point is that no program logic
changes. The assembly might even be the same. Just think of it as a
readability-optimizing decompiler. :) Or, alternately, it's the
while-loop way of doing it with an anonymous flag.


Robert Brewer
MIS
Amor Ministries
fumanchu at amor.org

P.S. I apologize profusely for misspelling "Piranha" more than once in
my original. "Goldfish" is better. :P