Yield inside try...finally

[Michael Sparks]

Thanks to all who responded. I'll group my replies here...

Peter Hansen <peter at engcorp.com> wrote:
> Twisted does "deliberate wheel reinvention" already, in many
> different areas.  Why reinvent reinventing the wheel when others
> already do it so well?  ;-)

Twisted is, AFAICT, essentially a state machine/reactor based approach
which has been done multiple times in multiple languages, each time with
a different "twist". (sorry...)

In the past I've worked as part of a large team supporting and helping
maintain a million line piece high performance network code written in
C++ that was entire state machine based. The system was elegant, worked
very  efficiently, but was _fragile_ to change, and needed a high skill
level to debug due to this fragilty.

The complaints may not apply to Twisted, but in most statemachine /
reactor based systems I've come across, sooner or later things become
either ugly, fragile or inefficient. (pick any one :)

This wheel re-invention is designed to see if using a generator based
(or rather co-routine) approach produces clearer, more readable, more
maintainable code, with significantly less fragility. It might not pan
out, but then again, it might. (After all state machines and generators
are functionally equivalent.)

Steven Taschuk <staschuk at telusplanet.net> wrote:
> What if the caller of your code calls .next for a while, then
> discards the iterator and does something else? Then the finally
> block will not be executed.

The system I've written that this code will live in forms a component
system that uses generators as communicating lightweight threads or
microprocesses. If the scheduler doesn't re-call next() - and hence 
re-activate - this component, this would be deemed as catastrophic
failure of the system as a whole.

Much like with state machine based concurrency if a particular state
machine gets stuck in a location and doesn't return control to (say) a
reactor pattern would be deemed a catastrophic failure.

Alan Kennedy <alanmk at hotmail.com> wrote:
> [ solultion ]

So the general form would be:

class Finality(Exception): pass

try:
    thing = getThing()
        try: # .. try, again
            while thing.doMoreThingsThatMightBreak():
                yield thing
            raise Finality
        except Exception, x: # Where you want nested "finally"s
            thing.necessaryShutdownFollowingFirstBreakable()
            raise x
except Finality: # Where you would want the last "finally"
   pass
except NastyExceptionThrowableByAllThoseMethods, e:
   print "Whinge, Moan, Complain", e

I'm not convinced that I _like_ this version, but it's definitely an
interesting alternative. (The thing I don't like is the "raise" in this
casestrikes me as an abuse of what raise is for. I'll have a think.

Very many thanks to all who responded - esp Alan!

Regards,


Michael
-- 
Michael.Sparks at rd.bbc.co.uk    
British Broadcasting Corporation, Research and Development
Kingswood Warren, Surrey KT20 6NP

This message (and any attachments) may contain personal views
which are not the views of the BBC unless specifically stated.