Re: Python style guidelines

From: Rocco Moretti (roccomoretti_at_hotpop.com)
Date: 03/17/04 

Date: Wed, 17 Mar 2004 13:22:30 -0600

Heather Coppersmith wrote:

> On 12 Mar 2004 23:08:19 -0800,
> jcb@iteris.com (MetalOne) wrote:

>>Some guidelines recommend functions with only a single return
>>point. I don't understand why this insanity got started. At
>>one point it was recognized that multiple entry points into a
>>function was confusing, but why did it have to get extrapolated
>>to multiple exit points. Upon entry to a function, I sometimes
>>like to verify that everything is ok before proceeding and if it
>>is not just get out. Parameters can validated, resources
>>acquired, or whatever.
>
>
> It's that "resources acquired" part that messes people up. I've
> seen it over and over and over again. Memory leaks. Dangling
> pointers. Unrecoverable file handles. Especially as functions
> that acquire lots of resources evolve over time and someone adds
> code to acquire another resource or detect another error condition
> and then doesn't find all the subsequent exit points. It's less
> of an issue with languages with proper garbage collection, but it
> can be a real nightmare in (e.g.) C or assembler. Unit tests that
> cover all possible resource leaks are difficult to construct
> correctly. C++ partially addresses the problem with RIAA (if
> coders use it properly) and a hodgepodge of "smart" objects that
> do pseudo self-garbage collection.

Unfortunately, the way I've seen "single exit points" handled in complex
functions is either to use a flag variable, which may or may not
correspond to the temporary variable for storing the return value, or to
enclose the whole function in an try: except block, raising a
specialized exception to quit. Neither of these is too elegant in my
opinion, and runs into the same problems seen with breaking out of
deeply nested loops. (A suggestion for which on a recent thread, BTW,
was to put them in a function and use return from multiple points).

Perhaps someone should write up a PEP:

def fun(params):
        #Function body
finally:
        #Cleanup code

Disavowing-all-responsibility-(Unless-Guido-likes-it)-ly'rs

-Rocco

Relevant Pages

  • Re: [PATCH] watchdog: cleanup s3c2410_wdt probe and release
    ... using labels instead of multiple returns. ... remove the checks for the resources having been ... allocate in the exit, as we will now either have ...
    (Linux-Kernel)
  • Re: Hamiltons Rule In The Mirror
    ... > action of the actor. ... The variable +b is strictly the movement of resources ... from the actor to recipients such as food, ... i.e. only the entire multiple rb can ever ...
    (sci.bio.evolution)
  • Re: moving data from one place to another in a text file
    ... for example, that multi-threading will save resources, but it does this ... software and multiple streams. ... The servers that I look after have multiple users and run several X ... desktops plus each user runs ...
    (comp.lang.cobol)
  • Re: using
    ... I claim it's cleaner to write code in the most obvious ... I could give you plenty of examples where it's simpler to have multiple ... Not just error handling - anything else you might want to do as you ... exit the method, such as logging, resource cleanup etc. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: When it will be freed?
    ... Some programmers do not like the idea of multiple return points from a function; they want all code paths to reach a single return point at the end of the function. ... While there are some advantages to having a single return point, more pragmatic programmers believe that complex code is often easier to understand with multiple return (or exit()) points. ... This is not unlike the debate about "goto"; avoiding it is a good idea in general, but there are times it's the best tool for the job. ...
    (comp.lang.c)
Loading