Carl M. Johnson wrote:
On Jan 23, 2012, at 9:00 PM, Nick Coghlan wrote:
On Tue, Jan 24, 2012 at 3:47 PM, Mike Meyer
wrote: The argument isn't that we need a new syntax for a small set of loops, it's that the only ways to implement retrying after an exception leave a code smell. Uh, saying "retrying is fundamentally a looping operation" is not a code smell.
I do think there's something code smelly about a retry--if it didn't work the first time, why should it work the second time after you give it a whack? Either whacking is good and you should do it in advance or it's bad and you should do something more sophisticated
"Whacking" is not necessarily bad or difficult, and is not necessarily a code smell. There are many common situations where "try again" is natural and expected. E.g. in response to a busy signal, you should wait a little while before retrying: delay = 5 # Initial delay between attempts in seconds. for _ in range(MAX_ATTEMPTS): try: response = urllib2.urlopen(url) except urllib2.HTTPError as e: if e.code == 503: # Service Unavailable. time.sleep(delay) delay *= 2 # Exponential back-off. else: raise else: break This could be written without the for-loop using a hypothetical retry statement, but it doesn't really gain us much: delay = 2 # Initial delay between attempts in seconds. count = 0 try: response = urllib2.urlopen(url) except urllib2.HTTPError as e: if e.code == 503 and count < MAX_ATTEMPTS: # Service Unavailable time.sleep(delay) delay *= 2 # Exponential back-off count += 1 retry else: raise Although you save one indent level, you don't save any lines of code, and it costs you the effort of handling the book-keeping that a for-loop would give you for free. I don't count this as a win. -- Steven