Interface and duck typing woes

[Chris Angelico]

On Thu, Aug 29, 2013 at 10:40 PM, Joe Junior <joe.fbs.junior at gmail.com> wrote:
> @ChrisA
>>Do you believe that you can write code to catch every bug you might
>>make? If so, you are naive and probably haven't spent much time
>>programming yet :) And if not, then you must acknowledge that bugs
>>WILL happen; therefore you will need to cope with them after the
>>event. So rather than trying to prevent them all, just improve your
>>means of coping, and you'll accomplish the same end with much less
>>trouble.
>
> Oh, no! I'm not that presumptuous (or naive)! But what do you mean by
> "improve means of coping"? Do you know any article on the subject you
> could point me?

Hmm. l don't know of any good articles off-hand. But what I'm talking
about is simply developing the skill of reading exceptions, plus a few
simple things like knowing where it's appropriate to catch-and-log;
sometimes, what that means is actually writing some code to (for
example) email you whenever there's an exception, but more likely it
means writing no code at all, and just looking at STDERR of your live
usage. Works really well for >95% of Python scripts.

The most important thing to consider is: What happens if my code
doesn't run all the way through? Is it safe for this to run part way,
then bomb with an exception? For many scripts, it's pretty easy: fix
the problem and rerun the script, and it'll completely rewrite its
output file. For others, this is a good reason for putting all your
"real data" into a transactional database - you begin a transaction at
the top, don't commit till the end, and if an exception kills your
script, your transaction will be rolled back. I have a system for
patching our database based on a script (written in Pike, not Python,
but the same applies); if I have any sort of critical failure in the
patch script, it'll bomb out as soon as I test it - but since I use
PostgreSQL, all that DDL (eg "ALTER TABLE") is covered by
transactional integrity (which it isn't with MySQL - another reason to
be wary of MySQL), so my patch will be backed out, and I can fix it
and start over. I don't need to have a Look Before You Leap approach
to database changes - I can simply do stuff, and if it crashes, all's
well. (That same script also has a system for catching errors at a
mid-level point that means that the process doesn't terminate when
there's an error; it supports full code reload, so once I fix the
patch, I send the process a SIGHUP and it fetches from disk again.)
*That* is error handling the safe way.

ChrisA