Recommendations (or best practices) to define functions (or methods)
Diez B. Roggisch
deets at nospam.web.de
Tue Jan 9 01:18:59 EST 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.
Diez
More information about the Python-list
mailing list