[Tutor] Exception Handling

Alan Gauld alan.gauld at btinternet.com
Tue Dec 30 00:02:21 CET 2008


"spir" <denis.spir at free.fr> wrote

> I often use the else clause of try...except. This allows putting 
> only the
> minimum problematic code lines inside the try block, which is good 
> both for
> legibility andto avoid catching unexpected errors. The else will be 
> executed
> only in case of no exception:
>
> try:
> problematic_instructions
> except ExceptionType, exception:
> expected_exception_handler
> else:
> further_standard_process


Thats exactly what I try to avoid. The big win for me in try/except is
that I can put the whole logic of a function together with no error
code confusing the picture. The above is no better than the old
BASIC style error handling

problemInstruction
if errorcode == XXX:
    handle error
further instruction

I find that much harder to follow the normal case code than:

try:
    problematic instructions
    more instructions
    more problems
except Error1
    handleError1
except Error2:
    handleError2

Now I can see the real algorithm and the errors are all tiucked out of
the way at the bottom where I don't need to read them until its
necessary.

Assuming you don't wrte functions that are hundreds of lines long
that doesn't cause me any problerms when debugging but greatly
increases the readability

The only somewhat valid case for doing line by line exceptions is
IMHO the one that started this - where users are entering input
and would need to start right at the beginning in the event of an
error. But as Bob pointed out you can avoid that by writing
a convertion function to do the error handling and validation and
call it repeatedly.

But it is largely a matter of personal taste.

Alan G. 




More information about the Tutor mailing list