On Mon, 11 Jul 2005 21:18:40 +0530, Dark Cowherd wrote:
> I tend to use exceptions, but I think Joel has a point.
Joel being "Joel On Software" Joel.
> Taking the example code that you have given above.
>
> Let us assume that somebody else is using my_function and DOES NOT
> write a try except block.
Then, like any other piece of Python code, if it raises an
exception the exception will be propagated and the interpreter will halt.
That is the correct behaviour. On crash, halt.
> This code will run fine except, when the exception is thrown and it will
> suddenly pop up in some other error handler which may not be handling
> the situation correctly. You have to plan and create a series of
> errorhandling classes to handle such situations.
Why? You should be aiming to write correct code that doesn't produce
random exceptions at random times, rather than wrapping everything in
exception handlers, which are wrapped in exception handlers, which are
wrapped in exception handlers...
Exceptions are useful, but you shouldn't just cover them up when they
occur. The idea of exceptions is to recover from them safely, if you can,
and if not, bring the program to a halt safely.
Dealing with exceptions is no different from dealing with data. If there
is data you don't deal with correctly ("what if the user passes -1 as an
argument, when we expect an integer larger than zero?") you have a bug. If
there is a exception you don't deal with correctly ("what if this function
raises ZeroDivisionError when we expect a ValueError?"), you have an
uncaught exception which will halt your program, exactly as exceptions are
designed to do.
> However Joels_function forces the caller to write some kind of error
> handler. If he doesnt write the program will not run.
And Python gives you that error handler already built in. It is called
try...except, and if you don't write it, and your program raises an
exception, your program will stop.
> After reading that I have been giving this option some thought. The nice
> thing about Python is I can easily return tuples.
Yes. But returning a tuple (success, data) where the meaning of data
varies depending on whether success is True or False is an abuse of the
language. I can think of a few places where I might do that, but not very
many.
The problem with this tuple (success, data) idiom is that it leads to
duplicated code. All your functions end up looking like this:
def func(data):
if data[0]:
result = do_real_work(data[1])
if error_condition:
return (False, msg)
return (True, result)
else:
return data
But then you want to make do_real_work bulletproof, don't you? So
do_real_work ends up filled with error checking, just in case the calling
function passes the wrong data. So you end up losing all the advantages of
wrapping your data in a tuple with a flag, but keeping the disadvantages.
In any case, writing masses of boilerplate code is a drain on programmer
productivity, and a frequent cause of bugs. Boilerplate code should be
avoided whenever you can.
--
Steven.
--
http://mail.python.org/mailman/listinfo/python-list
