On Thu, Aug 29, 2013 at 10:40 PM, Joe Junior <joe.fbs.jun...@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 -- http://mail.python.org/mailman/listinfo/python-list
