Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #53247

Re: Interface and duck typing woes

Show key headers only | View raw

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.

Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Interface and duck typing woes Joe Junior <joe.fbs.junior@gmail.com> - 2013-08-28 18:09 -0300
  Re: Interface and duck typing woes Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-08-28 23:24 +0000
  Re: Interface and duck typing woes Nobody <nobody@nowhere.com> - 2013-08-29 10:41 +0100
    Re: Interface and duck typing woes Joe Junior <joe.fbs.junior@gmail.com> - 2013-08-29 09:40 -0300
      Re: Interface and duck typing woes alex23 <wuwei23@gmail.com> - 2013-08-30 10:14 +1000
      Re: Interface and duck typing woes Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-08-30 02:42 +0000
        Re: Interface and duck typing woes Roy Smith <roy@panix.com> - 2013-08-30 06:35 -0400
          Re: Interface and duck typing woes Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-08-31 00:13 +0000
            Re: Interface and duck typing woes Ned Batchelder <ned@nedbatchelder.com> - 2013-08-30 20:45 -0400
            Re: Interface and duck typing woes Joshua Landau <joshua@landau.ws> - 2013-09-01 00:18 +0100
            Re: Interface and duck typing woes Roy Smith <roy@panix.com> - 2013-08-31 20:52 -0400
    Re: Interface and duck typing woes Chris Angelico <rosuav@gmail.com> - 2013-08-29 23:07 +1000
    Re: Interface and duck typing woes Joe Junior <joe.fbs.junior@gmail.com> - 2013-08-29 11:11 -0300
  Re: Interface and duck typing woes jussi.santti@ard.fi - 2013-08-29 22:37 -0700

csiph-web