Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #11959
| From | Terry Reedy <tjreedy@udel.edu> |
|---|---|
| Subject | Re: try... except with unknown error types |
| Date | 2011-08-21 15:52 -0400 |
| References | (1 earlier) <j2mcne$rmo$1@reader1.panix.com> <4e4ec405$0$29994$c3e8da3$5496439d@news.astraweb.com> <7xipprsxha.fsf@ruckus.brouhaha.com> <4e5015ad$0$29986$c3e8da3$5496439d@news.astraweb.com> <7xty9ahb84.fsf@ruckus.brouhaha.com> |
| Newsgroups | comp.lang.python |
| Message-ID | <mailman.286.1313956388.27778.python-list@python.org> (permalink) |
On 8/21/2011 2:26 PM, Paul Rubin wrote: > Steven D'Aprano<steve+comp.lang.python@pearwood.info> writes: >>> But there's no way to know what that minimum is. Python libraries throw >>> all sorts of exceptions that their documentation doesn't mention. >> >> Yes, you're absolutely correct. But it's also irrelevant. Most of those >> exceptions should not be caught, even if you know what they are, because >> they represent either bugs that should be fixed, or bad data which should >> raise an exception. A bare except, or except Exception, is hardly ever the >> right approach. > > I'm not sure what to do instead. The exceptions I'm currently dealing > with happen when certain network operations go wrong (e.g. network or > remote host is down, connection fails, etc.) The remedy in each case is > to catch the exception, log the error, and try the operation again > later. But there's no guaranteed-to-be-complete list in the Python docs > of all the exceptions that can be thrown. A new and surprising mode of > network failure can lead to an unhandled exception, unless you catch > everything. I would expect that catching socket.error (or even IOError) should catch all of those. "exception socket.error A subclass of IOError, this exception is raised for socket-related errors. It is recommended that you inspect its errno attribute to discriminate between different kinds of errors." > It's a retail application that would cause some business disruption and > a pissed off customer if the program went down. Also it's in an > embedded box on a customer site. It's not in Antarctica or anything > like that, but it's a few towns over, and someone would have to drive > there (probably through heavy traffic) if something went wrong that > power cycling the box couldn't fix. -- Terry Jan Reedy
Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
try... except with unknown error types Yingjie Lin <Yingjie.Lin@mssm.edu> - 2011-08-19 15:09 -0400
Re: try... except with unknown error types John Gordon <gordon@panix.com> - 2011-08-19 19:14 +0000
Re: try... except with unknown error types Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-20 06:13 +1000
Re: try... except with unknown error types John Gordon <gordon@panix.com> - 2011-08-19 20:24 +0000
Re: try... except with unknown error types Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-20 06:45 +1000
Re: try... except with unknown error types Seebs <usenet-nospam@seebs.net> - 2011-08-20 05:46 +0000
Re: try... except with unknown error types John Nagle <nagle@animats.com> - 2011-08-20 13:15 -0700
Re: try... except with unknown error types Paul Rubin <no.email@nospam.invalid> - 2011-08-20 12:18 -0700
Re: try... except with unknown error types Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-21 06:14 +1000
Re: try... except with unknown error types Paul Rubin <no.email@nospam.invalid> - 2011-08-21 11:26 -0700
Re: try... except with unknown error types Chris Angelico <rosuav@gmail.com> - 2011-08-21 20:17 +0100
Re: try... except with unknown error types Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-22 10:30 +1000
Re: try... except with unknown error types Chris Angelico <rosuav@gmail.com> - 2011-08-22 01:41 +0100
Re: try... except with unknown error types Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-22 14:01 +1000
Re: try... except with unknown error types Paul Rubin <no.email@nospam.invalid> - 2011-08-23 00:21 -0700
Re: try... except with unknown error types Chris Angelico <rosuav@gmail.com> - 2011-08-23 09:26 +0100
Re: try... except with unknown error types gene heskett <gheskett@wdtv.com> - 2011-08-23 04:43 -0400
Re: try... except with unknown error types Paul Rubin <no.email@nospam.invalid> - 2011-08-23 10:43 -0700
Re: try... except with unknown error types Chris Angelico <rosuav@gmail.com> - 2011-08-23 10:07 +0100
Re: try... except with unknown error types John Nagle <nagle@animats.com> - 2011-08-31 21:22 -0700
Re: try... except with unknown error types Ethan Furman <ethan@stoneleaf.us> - 2011-08-21 12:22 -0700
Re: try... except with unknown error types Terry Reedy <tjreedy@udel.edu> - 2011-08-21 15:52 -0400
Re: try... except with unknown error types Chris Torek <nospam@torek.net> - 2011-08-31 21:01 +0000
Re: try... except with unknown error types Stefan Krah <stefan-usenet@bytereef.org> - 2011-09-09 23:41 +0200
Re: try... except with unknown error types Nobody <nobody@nowhere.com> - 2011-09-10 10:33 +0100
Re: try... except with unknown error types Peter Otten <__peter__@web.de> - 2011-09-10 12:17 +0200
Re: try... except with unknown error types Roy Smith <roy@panix.com> - 2011-08-21 17:14 -0400
Re: try... except with unknown error types Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-22 10:25 +1000
Re: try... except with unknown error types Roy Smith <roy@panix.com> - 2011-08-21 22:09 -0400
Re: try... except with unknown error types Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-23 18:33 +1000
csiph-web