Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!newsfeed.xs4all.nl!newsfeed4.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <CAPTjJmqcFDHW4DgqZiy0i3q68Q4bJmkCMKzs_Kt3QM3Y63yehQ@mail.gmail.com>
References: <mailman.327.1377724351.19984.python-list@python.org> <pan.2013.08.29.09.41.38.945000@nowhere.com> <CADuC2CssnrZExb7v58X=wEw3MpF9mA9EHYb0QqChj6_+ifwdjA@mail.gmail.com> <CAPTjJmqcFDHW4DgqZiy0i3q68Q4bJmkCMKzs_Kt3QM3Y63yehQ@mail.gmail.com>
Date: Thu, 29 Aug 2013 11:11:38 -0300
Subject: Re: Interface and duck typing woes
From: Joe Junior <joe.fbs.junior@gmail.com>
To: Chris Angelico <rosuav@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: python-list@python.org
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.366.1377785505.19984.python-list@python.org>
Lines: 33
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:53247

On 29 August 2013 10:07, Chris Angelico <rosuav@gmail.com> wrote:
> 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.
>

Oh, I get it! Thanks.