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 -- http://mail.python.org/mailman/listinfo/python-list