On 01/05/2014 12:52 AM, Steven D'Aprano wrote:
If you don't understand an exception, you
have no business covering it up and hiding that it took place. Never use
a bare try...except, always catch the *smallest* number of specific
exception types that make sense. Better is to avoid catching exceptions
at all: an exception (usually) means something has gone wrong. You
should aim to fix the problem *before* it blows up, not after.
I'm reminded of a quote:
"I find it amusing when novice programmers believe their main job is
preventing programs from crashing. ... More experienced programmers
realize that correct code is great, code that crashes could use
improvement, but incorrect code that doesn't crash is a horrible
nightmare." -- Chris Smith
Your code is incorrect, it does the wrong thing, but it doesn't crash,
it just covers up the fact that an exception occured.
An exception, or any other kind of anomaly detected by a func one calls, is in
most cases a *symptom* of an error, somewhere else in one's code (possibly far
in source, possibly long earlier, possibly apparently unrelated). Catching an
exception (except in rare cases), is just suppressing a _signal_ about a
probable error. Catching an exception does not make the code correct, it just
pretends to (except in rare cases). It's like hiding the dirt under a carpet, or
beating up the poor guy that ran for 3 kilometers to tell you a fire in
threatening your home.
Again: the anomaly (eg wrong input) detected by a func is not the error; it is a
consequence of the true original error, what one should aim at correcting. (But
our culture apparently loves repressing symptoms rather than curing actual
problems: we programmers just often thoughtlessly apply the scheme ;-)
We should instead gratefully thank func authors for having correctly done their
jobs of controlling input. They offer us the information needed to find bugs
which otherwise may happily go on their lives undetected; and thus the
opportunity to write more correct software. (This is why func authors should
control input, refuse any anomalous or dubious values, and never ever try to
guess what the app expects in such cases; instead just say "cannot do my job
safely, or at all".)
If one is passing an empty set to an 'average' func, don't blame the func or
shut up the signal/exception, instead be grateful to the func's author, and find
why and how it happens the set is empty. If one is is trying to write into a
file, don't blame the file for not existing, the user for being stupid, or shut
up the signal/exception, instead be grateful to the func's author, and find why
and how it happens the file does not exist, now (about the user: is your doc
clear enough?).
The sub-category of cases where exception handling makes sense at all is the
following:
* a called function may fail (eg average, find a given item in a list, write
into a file)
* and, the failure case makes sense for the app, it _does_ belong to the app
logic
* and, the case should nevertheless be handled like others up to this point in
code (meaning, there should not be a separate branch for it, we should really
land there in code even for this failure case)
* and, one cannot know whether it is a failure case without trying, or it would
be as costly as just trying (wrong for average, right for 2 other examples)
* and, one can repair the failure right here, in any case, and go on correctly
according to the app logic (depends on apps) (there is also the category of
alternate running modes)
In such a situation, the right thing to do is to catch the exception signal (or
use whatever error management exists, eg a check for a None return value) and
proceed correctly (and think at testing this case ;-).
But this is not that common. In particular, if the failure case does not belong
to the app logic (the item should be there, the file should exist) then do *not*
catch a potential signal: if it happens, it would tell you about a bug
*elsewhere* in code; and _this_ is what is to correct.
There a mythology in programming, that software should not crash; wrongly
understood (or rightly, authors of such texts usually are pretty unclear and
ambiguous), this leads to catching exceptions that are just signal of symptoms
of errors... Instead, software should crash whenever it is incorrect; often
(when the error does not cause obvious misbehaviour) it is the only way for the
programmer to know about errors. Crashes are the programmer's best friend (I
mean, those programmers which aim is to write quality software).
Denis
_______________________________________________
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
