[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