On Wed, 31 Aug 2011 21:01:34 +, Chris Torek wrote:
Still, it sure would be nice to have a static analysis
tool that could answer questions about potential exceptions. :-) )
That's an impossibility in a dynamic language.
If you call f.read() where f was passed in as a parameter, the
Chris Torek wrote:
import socket
isinstance(socket.error, IOError)
False
Here you test if the socket.error *class* is an instance of IOError; this
would print True if IOError were socket.error's metaclass. However:
isinstance(socket.error(), IOError)
True
or more directly:
Chris Torek nos...@torek.net wrote:
(I have also never been sure whether something is going to raise
an IOError or an OSError for various OS-related read or write
operation failures -- such as exceeding a resource limit, for
instance -- so most places that do I/O operations on OS files, I
In article mailman.286.1313956388.27778.python-l...@python.org,
Terry Reedy tjre...@udel.edu wrote:
I would expect that catching socket.error (or even IOError) should catch
all of those.
exception socket.error
A subclass of IOError ...
Except that, as Steven D'Aprano almost noted elsethread,
On 8/21/2011 5:30 PM, Steven D'Aprano wrote:
Chris Angelico wrote:
A new and surprising mode of network failure would be indicated by a
new subclass of IOError or EnvironmentError.
/s/would/should/
I don't see why you expect this, when *existing* network-related failures
aren't:
import
Chris Angelico ros...@gmail.com writes:
Ehh, granted. Definitely a case of should. But certainly, there
won't be an infinite number of new exceptions invented;
Right, the number is finite, but the issue is that it's unknown. It's
like never knowing whether you've fixed the last bug in a
On Tue, Aug 23, 2011 at 8:21 AM, Paul Rubin no.email@nospam.invalid wrote:
Chris Angelico ros...@gmail.com writes:
Ehh, granted. Definitely a case of should. But certainly, there
won't be an infinite number of new exceptions invented;
Right, the number is finite, but the issue is that it's
On Mon, 22 Aug 2011 04:26 am Paul Rubin wrote:
The Erlang approach is tempting. Don't catch the exception at all--just
let the process crash, and restart it. But that's a more heavyweight
operation in Python.
You might be interested in this paper:
On Tuesday, August 23, 2011 04:42:04 AM Chris Angelico did opine:
On Tue, Aug 23, 2011 at 8:21 AM, Paul Rubin no.email@nospam.invalid
wrote:
Chris Angelico ros...@gmail.com writes:
Ehh, granted. Definitely a case of should. But certainly, there
won't be an infinite number of new
On Tue, Aug 23, 2011 at 9:43 AM, gene heskett ghesk...@wdtv.com wrote:
OTOH, ChrisA, I have it on good authority that no program is ever finished,
until someone shoots the programmer. :)
Correct, although I've had projects that were killed by changes to
requirements - such as my fantastic
gene heskett ghesk...@wdtv.com writes:
OTOH, ChrisA, I have it on good authority that no program is ever finished,
until someone shoots the programmer. :)
The way I heard it was software is never finished until the last user
is dead.
--
http://mail.python.org/mailman/listinfo/python-list
Steven D'Aprano steve+comp.lang.pyt...@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
On Sun, Aug 21, 2011 at 7:26 PM, Paul Rubin no.email@nospam.invalid wrote:
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
Paul Rubin wrote:
Steven D'Aprano steve+comp.lang.pyt...@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
On 8/21/2011 2:26 PM, Paul Rubin wrote:
Steven D'Apranosteve+comp.lang.pyt...@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
In article 7xty9ahb84@ruckus.brouhaha.com,
Paul Rubin no.email@nospam.invalid wrote:
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
Paul Rubin wrote:
Steven D'Aprano steve+comp.lang.pyt...@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
Chris Angelico wrote:
A new and surprising mode of network failure would be indicated by a
new subclass of IOError or EnvironmentError.
/s/would/should/
I don't see why you expect this, when *existing* network-related failures
aren't:
import socket
issubclass(socket.error,
On Mon, Aug 22, 2011 at 1:30 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
/s/would/should/
I don't see why you expect this, when *existing* network-related failures
aren't
Ehh, granted. Definitely a case of should. But certainly, there
won't be an infinite number of new
In article 4e51a205$0$29974$c3e8da3$54964...@news.astraweb.com,
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:
http://www.codinghorror.com/blog/2011/04/working-with-the-chaos-monkey.html
I *love* being the Chaos Monkey!
A few jobs ago, I had already turned in my resignation and
On Mon, 22 Aug 2011 10:41 am Chris Angelico wrote:
On Mon, Aug 22, 2011 at 1:30 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
/s/would/should/
I don't see why you expect this, when *existing* network-related failures
aren't
Ehh, granted. Definitely a case of should. But
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info writes:
You can catch all exceptions by catching the base class Exception:
Except that is nearly always poor advice, because it catches too much: it
hides bugs in code, as well as things which should be caught.
You should always catch the
Paul Rubin wrote:
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info writes:
You can catch all exceptions by catching the base class Exception:
Except that is nearly always poor advice, because it catches too much: it
hides bugs in code, as well as things which should be caught.
You
On 8/19/2011 1:24 PM, John Gordon wrote:
In4e4ec405$0$29994$c3e8da3$54964...@news.astraweb.com Steven
D'Apranosteve+comp.lang.pyt...@pearwood.info writes:
You can catch all exceptions by catching the base class Exception:
Except that is nearly always poor advice, because it catches too
Hi Python users,
I have been using try...except statements in the situations where I can expect
a certain type of errors might occur.
But sometimes I don't exactly know the possible error types, or sometimes I
just can't spell the error types correctly.
For example,
try:
response =
In mailman.230.1313780957.27778.python-l...@python.org Yingjie Lin
yingjie@mssm.edu writes:
try:
response = urlopen(urljoin(uri1, uri2))
except urllib2.HTTPError:
print URL does not exist!
Though urllib2.HTTPError is the error type reported by Python, Python
doesn't
On Friday 2011 August 19 12:09, Yingjie Lin wrote:
Hi Python users,
I have been using try...except statements in the situations where I can
expect a certain type of errors might occur. But sometimes I don't exactly
know the possible error types, or sometimes I just can't spell the error
:
On 19 August 2011 15:09, Yingjie Lin yingjie@mssm.edu wrote:
I have been using try...except statements in the situations where I can
expect a certain type of errors might occur.
But sometimes I don't exactly know the possible error types, or sometimes I
just can't spell the error
Hi Zero,
I see! This is very helpful. Thank you.
- Yingjie
On Aug 19, 2011, at 3:30 PM, Zero Piraeus wrote:
:
On 19 August 2011 15:09, Yingjie Lin yingjie@mssm.edu wrote:
I have been using try...except statements in the situations where I can
expect a certain type of errors
John Gordon wrote:
In mailman.230.1313780957.27778.python-l...@python.org Yingjie Lin
yingjie@mssm.edu writes:
try:
response = urlopen(urljoin(uri1, uri2))
except urllib2.HTTPError:
print URL does not exist!
Though urllib2.HTTPError is the error type reported by Python, Python
In 4e4ec405$0$29994$c3e8da3$54964...@news.astraweb.com Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info writes:
You can catch all exceptions by catching the base class Exception:
Except that is nearly always poor advice, because it catches too much: it
hides bugs in code, as well as
John Gordon wrote:
In 4e4ec405$0$29994$c3e8da3$54964...@news.astraweb.com Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info writes:
You can catch all exceptions by catching the base class Exception:
Except that is nearly always poor advice, because it catches too much: it
hides bugs
xDog Walker wrote:
On Friday 2011 August 19 12:09, Yingjie Lin wrote:
[ ... ]
Does anyone know what error type I should put after the except statement?
or even better: is there a way not to specify the error types? Thank you.
You probably need to import urllib2 before you can use
On 8/19/11 12:09 PM, Yingjie Lin wrote:
try:
response = urlopen(urljoin(uri1, uri2))
except urllib2.HTTPError:
print URL does not exist!
Though urllib2.HTTPError is the error type reported by Python, Python
doesn't recognize it as an error type name.
I tried using HTTPError
On 2011-08-19, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:
Even if you don't think it's the ethical thing to do, consider that someday
you might be maintaining code written by the OP :)
A common further conclusion people reach is but then I will be able to get
a job fixing it!
35 matches
Mail list logo
