Recommendations (or best practices) to define functions (or methods)

Diez B. Roggisch deets at
Tue Jan 9 07:18:59 CET 2007

vizcayno schrieb:
> Diez B. Roggisch ha escrito:
>> vizcayno schrieb:
>>> Hello:
>>> Need your help in the "correct" definition of the next function. If
>>> necessary, I would like to know about a web site or documentation that
>>> tells me about best practices in defining functions, especially for
>>> those that consider the error exceptions management.
>>> I have the next alternatives but I think there are better:
>> <snip/>
>> IMHO none of them is good. Python has exceptions. Use them. There is no
>> need to awkwardly communicate error conditions using return-values. Use
>> return values to return values. Use exceptions in case of errors.
>> Diez
> Diez, in that case I woul prefer not to use exceptions and wait for
> Python to abort itself and wait to see the message it issues.

You are not making sense here - to me at last.

If you don't handle the exceptions, exactly what you seem to want will 
happen - you will see the interpreter stop, and why.

Handling errors in a graceful way can't be done by a standardized way, 
as you seem to want. It depends to much on what the actual code is 
doing. Sometimes an abort is necessary, sometimes you can continue 
working - but it all depends on what your actual usecase is, on a very 
detailed level.

All you did was to take the unpythonic (and un-javaic and un-C#ic) road 
to transform an exception to a returncode. But that has nothing to do 
with actually _dealing_ with the error. Instead, it just makes it more 
likely that you _don't_ deal with it, as a return-code evaluation might 
be more easily forgotten, and turn out with a program that will be 
error-prone, as it continues to run even when the preconditions for 
pieces of code aren't met anymore.


More information about the Python-list mailing list