Steven D'Aprano:
The OP is doing it because catching all exceptions masks bugs. There are
certain exceptions which should be allowed through, as they indicate a bug
in the OP's code. Normally the tactic is to catch only the exceptions you
are interested in, and let everything else through, but the
Rene Pijlman wrote:
Steven D'Aprano:
The OP is doing it because catching all exceptions masks bugs. There are
certain exceptions which should be allowed through, as they indicate a bug
in the OP's code. Normally the tactic is to catch only the exceptions you
are interested in, and let
Yes, and that's the Right Thing(tm) to do. Source code don't lie. Source
code don't get out of sync. So source code *is* the best documentation
(or at least the most accurate).
I could not disagree more strongly with this. Not just no, but hell
no!
Yes, and that's the Right Thing(tm) to do.
Roy Smith:
I like to create a top-level exception class to encompass all the
possible errors in a given module, then subclass that. This way, if you
want to catch anything to goes wrong in a call, you can catch the top-level
exception class without having to enumerate them all.
What do you
James Stroud:
Which suggests that try: except HTTPException: will be specific enough
as a catchall for this module.
The following, then, should catch everything you mentioned except the
socket timeout:
Your conclusion may be (almost) right in this case. I just don't like this
approach.
Peter Hansen:
Good code should probably have a very small set of real exception
handling cases, and one or two catchalls at a higher level to avoid
barfing a traceback at the user.
Good point.
A catchall seems like a bad idea, since it also catches AttributeErrors
and other bugs in the
Paul Rubin http://[EMAIL PROTECTED]:
We have to get Knuth using Python.
Perhaps a MIX emulator and running TeXDoctest on his books will convince
him..
--
René Pijlman
--
http://mail.python.org/mailman/listinfo/python-list
Steven D'Aprano:
ExpectedErrors = (URLError, IOError)
ErrorsThatCantHappen =
try:
process_things()
except ExpectedErrors:
recover_from_error_gracefully()
except ErrorsThatCantHappen:
print Congratulations! You have found a program bug!
print For a $327.68 reward, please send the
Rene Pijlman [EMAIL PROTECTED] writes:
With low coverage, yes. But unit testing isn't the answer for this
particular problem. For example, yesterday my app was surprised by an
httplib.InvalidURL since I hadn't noticed this could be raised by
robotparser (this is undocumented). If that fact
Rene Pijlman [EMAIL PROTECTED] wrote:
A catchall seems like a bad idea, since it also catches AttributeErrors
and other bugs in the program.
All of the things like AttributeError are subclasses of StandardError. You
can catch those first, and then catch everything else. In theory, all
Jorge Godoy:
Rene Pijlman:
my app was surprised by an
httplib.InvalidURL since I hadn't noticed this could be raised by
robotparser (this is undocumented).
It isn't undocumented in my module. From 'pydoc httplib':
That's cheating: pydoc is reading the source :-)
What I meant was, I'm
Roy Smith:
In theory, all exceptions which represent problems with the external
environment (rather than programming mistakes) should derive from
Exception, but not from StandardError.
Are you sure?
The class hierarchy for built-in exceptions is:
Exception
+-- StandardError
|
In article [EMAIL PROTECTED],
Rene Pijlman [EMAIL PROTECTED] wrote:
Roy Smith:
In theory, all exceptions which represent problems with the external
environment (rather than programming mistakes) should derive from
Exception, but not from StandardError.
Are you sure?
The class
Rene Pijlman wrote:
Paul Rubin http://[EMAIL PROTECTED]:
We have to get Knuth using Python.
Perhaps a MIX emulator and running TeXDoctest on his books will convince
him..
Or maybe Python written for MIX...
-Roman
--
http://mail.python.org/mailman/listinfo/python-list
Rene Pijlman a écrit :
Jorge Godoy:
Rene Pijlman:
my app was surprised by an
httplib.InvalidURL since I hadn't noticed this could be raised by
robotparser (this is undocumented).
It isn't undocumented in my module. From 'pydoc httplib':
That's cheating: pydoc is reading the source :-)
Rene Pijlman wrote:
Steven D'Aprano:
ExpectedErrors = (URLError, IOError)
ErrorsThatCantHappen =
try:
process_things()
except ExpectedErrors:
recover_from_error_gracefully()
except ErrorsThatCantHappen:
print Congratulations! You have found a program bug!
print For a $327.68
James Stroud [EMAIL PROTECTED] wrote:
Reraise = (LookupError, ArithmeticError, AssertionError) # And then some
try:
process_things()
except Reraise:
raise
except:
log_error()
Why catch an error only to re-raise it?
To avoid the following handler[s] -- a pretty
James Stroud [EMAIL PROTECTED] writes:
try:
process_things()
except Reraise:
raise
except:
log_error()
Why catch an error only to re-raise it?
This falls under http://c2.com/cgi/wiki?YouReallyArentGonnaNeedThis
No, without the reraise, the bare except: clause would
Rene Pijlman wrote:
James Stroud:
Which suggests that try: except HTTPException: will be specific enough
as a catchall for this module.
The following, then, should catch everything you mentioned except the
socket timeout:
Your conclusion may be (almost) right in this case. I just don't
James Stroud [EMAIL PROTECTED] writes:
approach. Basically this is reverse engineering the interface from the
source at the time of writing the app.
This is using the source as documentation, there is no law against
that.
That's completely bogus. Undocumented interfaces in the library
Paul Rubin wrote:
James Stroud [EMAIL PROTECTED] writes:
approach. Basically this is reverse engineering the interface from the
source at the time of writing the app.
This is using the source as documentation, there is no law against
that.
That's completely bogus. Undocumented interfaces
James Stroud [EMAIL PROTECTED] writes:
My suggestion was to use some common sense about the source code and
apply it.
The common sense to apply is that if the source code says one thing
and the documentation says another, then one of them is wrong and
should be updated. Usually it's the source
On Sat, 04 Mar 2006 13:19:29 -0800, James Stroud wrote:
Why catch an error only to re-raise it?
As a general tactic, you may want to catch an exception, print extra
debugging information, then raise the exception again, like this:
try:
x = somedata()
y = someotherdata()
z =
One of the things I dislike about Java is the need to declare exceptions
as part of an interface or class definition. But perhaps Java got this
right...
I've writen an application that uses urllib2, urlparse, robotparser and
some other modules in the battery pack. One day my app failed with an
Rene Pijlman wrote:
One of the things I dislike about Java is the need to declare exceptions
as part of an interface or class definition. But perhaps Java got this
right...
I've writen an application that uses urllib2, urlparse, robotparser and
some other modules in the battery pack. One
James Stroud wrote:
except URLError, HTTPException:
Aieee! This catches only URLError and binds the name HTTPException to
the detail of that error. You must write
except (URLError, HTTPException):
to catch both.
--
Ben Caradoc-Davies [EMAIL PROTECTED]
http://wintersun.org/
Those who deny
Ben Caradoc-Davies wrote:
James Stroud wrote:
except URLError, HTTPException:
Aieee! This catches only URLError and binds the name HTTPException to
the detail of that error. You must write
except (URLError, HTTPException):
to catch both.
Oops.
--
In article [EMAIL PROTECTED],
Ben Caradoc-Davies [EMAIL PROTECTED] wrote:
James Stroud wrote:
except URLError, HTTPException:
Aieee! This catches only URLError and binds the name HTTPException to
the detail of that error. You must write
except (URLError, HTTPException):
to catch
Rene Pijlman wrote:
One of the things I dislike about Java is the need to declare exceptions
as part of an interface or class definition. But perhaps Java got this
right...
I've writen an application that uses urllib2, urlparse, robotparser and
some other modules in the battery pack. One
On Sat, 04 Mar 2006 00:10:17 +0100, Rene Pijlman wrote:
I've writen an application that uses urllib2, urlparse, robotparser and
some other modules in the battery pack. One day my app failed with an
urllib2.HTTPError. So I catch that. But then I get a urllib2.URLError, so
I catch that too. The
Steven D'Aprano [EMAIL PROTECTED] writes:
try:
process_things()
except ExpectedErrors:
recover_from_error_gracefully()
except ErrorsThatCantHappen:
print Congratulations! You have found a program bug!
print For a $327.68 reward, please send the following \
traceback to
On Fri, 03 Mar 2006 21:10:22 -0800, Paul Rubin wrote:
Steven D'Aprano [EMAIL PROTECTED] writes:
try:
process_things()
except ExpectedErrors:
recover_from_error_gracefully()
except ErrorsThatCantHappen:
print Congratulations! You have found a program bug!
print For a
Steven D'Aprano [EMAIL PROTECTED] writes:
The way to deal with it is to add another except clause to deal with the
KeyboardInterrupt, or to have recover_from_error_gracefully() deal with
it.
I think adding another except clause for KeyboardInterrupt isn't good
because maybe in Python 2.6 or
33 matches
Mail list logo
