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

[George Sakkis]

vizcayno wrote:

> 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:
>
> Alternative 1:
> =============
> def ExecuteSQL(cmdSQL, cursor):
>     try:
>         cursor.execute(cmdSQL)
>     except Exception, e:
>         return e
>     return 1
>
> Seems a good solution but the function is not returning an uniform
> type, should the code that receives the function result decides the
> error display according of datatype? If I do this in C# I think I will
> have problems.
>
>
> Alternative 2:
> =============
> def ExecuteSQL(cmdSQL, cursor):
>     try:
>         cursor.execute(cmdSQL)
>     except Exception, e:
>         return 0, e   # or return (0,e.message)
>     return 1, "ok"    # or return (1, "ok")
> Sounds good, but seems forced. When doing return 1, "ok" I am doing
> redundancy and I have problems with the type (e is exception type and
> "ok" is string).
>
>
> Alternative 3:
> =============
> def ExecuteSQL(cmdSQL, cursor):
>     try:
>         cursor.execute(cmdSQL)
>     except Exception, e:
>         print "ERROR:", e
>         return 0
>     return 1
>
> It solves the problem of alternative 1 and 2, but the print keyword
> would have problems if the function is called from an WEB or GUI
> application and, because there are plans to convert print into a
> function in py3k.
>
>
> Alternative 4:
> =============
> def ExecuteSQL(cmdSQL, cursor):
>     try:
>         cursor.execute(cmdSQL)
>     except Exception, e:
>         print >> logerr, e.message
>         return 0
>     return 1
>
> Seems a good solution but I should always be persuaded to have an open
> global file (logerr) when invoking this function; otherwise code will
> generate another error. The function is not totally independent.I think
> I would be in the same situation when using the "logging" battery.
>
> Thanks for your attention.
>
> Regards,

My vote goes to None Of The Above. In neither alternative you actually
do anything useful with the exception other than reporting it in some
ad-hoc way. If that's all you can and/or want to do with it (i.e. no
error recovery of some sort), the typical thing to do is nothing; just
let it propagate up the call stack until the appropriate level. This
might be the console, a GUI, a logfile, an automatically sent email or
any combination of these or more. If it's a programmer's error (aka
bug), it should propagate all the way up and end in printing the stack
trace.

The bottom line is, it's simply not this function's (ExecuteSQL) job to
deal with the error, so it shouldn't. Most important, returning an
error or status code is rarely (if ever) desirable or necessary in
Python; that's what exceptions are for.

George