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

Groups > comp.lang.python > #11865 > unrolled thread

try... except with unknown error types

Back to article view | Back to comp.lang.python

Contents

  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

Page 1 of 2  [1] 2  Next page →

#11865 — try... except with unknown error types

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 = 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" alone too, but that's not recognized either.

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.


- Yingjie

[toc] | [next] | [standalone]

#11866

In <mailman.230.1313780957.27778.python-list@python.org> Yingjie Lin <Yingjie.Lin@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 recognize it as an error type name. I tried using "HTTPError"
> alone too, but that's not recognized either.

Have you imported urllib2 in your code?

> 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 can catch all exceptions by catching the base class Exception:

  try:
    some_method()
  except Exception, e:
    print "some error happened, here is the explanation:"
    print str(e)

-- 
John Gordon                   A is for Amy, who fell down the stairs
gordon@panix.com              B is for Basil, assaulted by bears
                                -- Edward Gorey, "The Gashlycrumb Tinies"

[toc] | [prev] | [next] | [standalone]

#11872

John Gordon wrote:

> In <mailman.230.1313780957.27778.python-list@python.org> Yingjie Lin
> <Yingjie.Lin@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 recognize it as an error type name. I tried using "HTTPError"
>> alone too, but that's not recognized either.
> 
> Have you imported urllib2 in your code?

Good question.

If Python "doesn't recognize it as an error type name", there is a reason
for that. Exceptions are exactly the same as every other name:

>>> foo.spam
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'foo' is not defined
>>> urllib2.HTTPError
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'urllib2' is not defined



>> 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 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 absolute minimum you need to catch.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#11876

In <4e4ec405$0$29994$c3e8da3$5496439d@news.astraweb.com> Steven D'Aprano <steve+comp.lang.python@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 absolute minimum you need to catch.

I agree, but it did seem to be exactly what he was asking for.

-- 
John Gordon                   A is for Amy, who fell down the stairs
gordon@panix.com              B is for Basil, assaulted by bears
                                -- Edward Gorey, "The Gashlycrumb Tinies"

[toc] | [prev] | [next] | [standalone]

#11881

John Gordon wrote:

> In <4e4ec405$0$29994$c3e8da3$5496439d@news.astraweb.com> Steven D'Aprano
> <steve+comp.lang.python@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 absolute minimum you need to catch.
> 
> I agree, but it did seem to be exactly what he was asking for.

Sure, but if we're giving advice to somebody who is clearly a beginner
(doesn't even know how to deal with a simple NameError from failing to
import a module), it is our responsibility to teach *good* habits, not to
teach him to be a crap programmer.

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 :)




-- 
Steven

[toc] | [prev] | [next] | [standalone]

#11899

On 2011-08-19, Steven D'Aprano <steve+comp.lang.python@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!"

Trust me, this is NOT where you want to go.  :)

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

[toc] | [prev] | [next] | [standalone]

#11930

On 8/19/2011 1:24 PM, John Gordon wrote:
> In<4e4ec405$0$29994$c3e8da3$5496439d@news.astraweb.com>  Steven D'Aprano<steve+comp.lang.python@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 absolute minimum you need to catch.

    Right.  When in doubt, catch EnvironmentError.  That means something
external to the program, at the OS or network level, has a problem.
"Exception" covers errors which are program bugs, like references to
undefined class members.

					John Nagle

[toc] | [prev] | [next] | [standalone]

#11926

Steven D'Aprano <steve+comp.lang.python@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 absolute minimum you need to catch.

But there's no way to know what that minimum is.  Python libraries throw
all sorts of exceptions that their documentation doesn't mention.
Java's checked exceptions are obnoxious but they do have their
attractions.

[toc] | [prev] | [next] | [standalone]

#11929

Paul Rubin wrote:

> Steven D'Aprano <steve+comp.lang.python@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 absolute minimum you need to catch.
> 
> 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.

As for exceptions which should be caught, they should be dealt with on a
case-by-case basis. There's no need to identify all those obscure
exception-raising cases ahead of time. After all, unless you're writing
software for a nuclear reactor, or an aeroplane's autopilot, chances are
that *bugs don't really matter*. That is to say, if you release software
with a hidden bug, the consequences generally aren't very important.
(Depends on the nature of the software, and the bug, of course. Sometimes
bugs are important. How's your test suite?) At some point, you will get a
bug report, and then you will fix the bug. The fix may involve catching an
extra exception, or avoiding generating the exception in the first place.

Trying to predict ahead of time every possible exception that could be
raised, and deal with them correctly (as opposed to just sweeping them
under the carpet), is not only impossible but also usually unnecessary.

It took me a long time to realise that the world won't end if I write a
piece of software with a bug. Now I realise that software is never
finished, there's always going to be a next version, so trying to make it
perfect is a fool's errand. It's very liberating :)


> Java's checked exceptions are obnoxious but they do have their
> attractions.

No doubt about it, the concept is attractive, but a few Java heavyweights
now consider checked exceptions to be a mistake.

http://www.mindview.net/Etc/Discussions/CheckedExceptions
http://radio-weblogs.com/0122027/stories/2003/04/01/JavasCheckedExceptionsWereAMistake.html

More here:
http://www.ibm.com/developerworks/java/library/j-jtp05254/index.html



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#11953

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.

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.  

> After all, unless you're writing
> software for a nuclear reactor, or an aeroplane's autopilot, chances are
> that *bugs don't really matter*. That is to say, if you release software
> with a hidden bug, the consequences generally aren't very important.

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.

> It took me a long time to realise that the world won't end if I write a
> piece of software with a bug. 

It's not the end of the world if I get run over a truck, but such an
event would be of enough consequence to me personally that I find it
worth going to some trouble to avoid it.

[toc] | [prev] | [next] | [standalone]

#11955

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 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.
>

A new and surprising mode of network failure would be indicated by a
new subclass of IOError or EnvironmentError. If you catch one of
those, you should catch it. That's the benefit of hierarchical
exceptions.

ChrisA

[toc] | [prev] | [next] | [standalone]

#11976

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, EnvironmentError)
False

(Fortunately that specific example is fixed in Python 3.)

Besides, there's a world of difference between "should be" and "are".


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#11977

On Mon, Aug 22, 2011 at 1:30 AM, Steven D'Aprano
<steve+comp.lang.python@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 exceptions invented; most of the
runtime issues you'll have will fall into a fairly small number of
exception types (either by subclassing or by parameters eg errno).

ChrisA

[toc] | [prev] | [next] | [standalone]

#11988

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.python@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 exceptions invented; most of the
> runtime issues you'll have will fall into a fairly small number of
> exception types (either by subclassing or by parameters eg errno).

Er, you can't know that either.

Except that all exceptions must be rooted at BaseException, there *can* be
an infinite number of new exception types invented. Or functions could
raise unexpected, but known, exceptions, whether built-in or not.

Of course, the set of hypothetical exceptions that could theoretically be
raised is much, much bigger than the set of exceptions which you can
realistically expect to see, especially if you limit yourself to those that
don't leave you wondering about the sanity of the developer ("WTF? Why is
x+1 raising HTTPBadGatewayError?"). But still, as a general rule you should
not be surprised to see any of:

AttributeError
TypeError
ValueError
(and likely others)

The more important question is, if you get an exception, any exception, is
that a bug in the function you are calling, a bug in your calling code (you
supplied a bad argument), or an expected result that you should catch and
work around?


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#12064

Chris Angelico <rosuav@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 program.

[toc] | [prev] | [next] | [standalone]

#12067

On Tue, Aug 23, 2011 at 8:21 AM, Paul Rubin <no.email@nospam.invalid> wrote:
> Chris Angelico <rosuav@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 program.
>

Yeah. Oh, I know when I've fixed the last bug in a program. It's the
day the program gets deleted. Until then? Nope.

ChrisA

[toc] | [prev] | [next] | [standalone]

#12070

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 <rosuav@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 program.
> 
> Yeah. Oh, I know when I've fixed the last bug in a program. It's the
> day the program gets deleted. Until then? Nope.
> 
> ChrisA

OTOH, ChrisA, I have it on good authority that no program is ever finished, 
until someone shoots the programmer.  :)

Cheers, gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
<http://204.111.25.156:85/gene/>

Practice is the best of all instructors.
		-- Publilius

[toc] | [prev] | [next] | [standalone]

#12109

gene heskett <gheskett@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".

[toc] | [prev] | [next] | [standalone]

#12071

On Tue, Aug 23, 2011 at 9:43 AM, gene heskett <gheskett@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 system for writing device drivers
that leveraged DEBUG.EXE to translate assembly code into machine code,
and a REXX script to handle jump labels and such. That project was
quite thoroughly finished on the day that I met nasm :)

But that's quite off-topic.

ChrisA

[toc] | [prev] | [next] | [standalone]

#12545

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 socket
>>>> issubclass(socket.error, EnvironmentError)
> False
>
> (Fortunately that specific example is fixed in Python 3.)

    I think I reported that some years ago.

    There were some other errors in the URL and SSL area that
weren't subclasses of EnvironmentError.  It's also possible
to get UnicodeError from URL operations.

					John Nagle

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.python

csiph-web