How do I get info on an exception ?

Discussion in 'Python' started by Erik Max Francis, Jul 18, 2003.

  1. Frank wrote:

    > Using Python 2.2.2,
    > I want to catch all exceptions from "socket.gethostbyaddr(ip)"
    >
    > From IDLE, I can generate:
    > >>> socket.gethostbyaddr('1.2')

    > Traceback (most recent call last):
    > File "<pyshell#28>", line 1, in ?
    > socket.gethostbyaddr('1.2')
    > herror: (11004, 'host not found') <=== what I want when I catch
    >
    > When I run this code:
    > try:
    > hostname, aliases, hostip = socket.gethostbyaddr(ip)
    > return (hostip, hostname)
    > except:
    > print sys.exc_info()
    > print sys.exc_type
    > return


    Use the format:

    try:
    ...
    except ErrorType, e:
    ... do something with exception object e ...

    >>> import socket
    >>> socket.error

    <class socket.error at 0x8154304>
    >>> try:

    .... socket.gethostbyaddr('1.2')
    .... except socket.error, e:
    .... print e, dir(e), e.args
    ....
    (1, 'Unknown host') ['__doc__', '__getitem__', '__init__', '__module__',
    '__str__', 'args'] (1, 'Unknown host')

    > How do I get the "(11004, 'host not found')" part?
    > More importantly, where is the answer documented that I should
    > have looked?


    Check the part on exception handling.

    --
    Erik Max Francis && && http://www.alcyone.com/max/
    __ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
    / \ It is human nature to think wisely and act foolishly.
    \__/ Anatole France
     
    Erik Max Francis, Jul 18, 2003
    #1
    1. Advertising

  2. Erik Max Francis

    Frank Guest

    Using Python 2.2.2,
    I want to catch all exceptions from "socket.gethostbyaddr(ip)"

    From IDLE, I can generate:
    >>> socket.gethostbyaddr('1.2')

    Traceback (most recent call last):
    File "<pyshell#28>", line 1, in ?
    socket.gethostbyaddr('1.2')
    herror: (11004, 'host not found') <=== what I want when I catch

    When I run this code:
    try:
    hostname, aliases, hostip = socket.gethostbyaddr(ip)
    return (hostip, hostname)
    except:
    print sys.exc_info()
    print sys.exc_type
    return

    The "print sys.exc_info()" gives-
    (<class socket.herror at 0x00AE7AC0>,
    <socket.herror instance at 0x00C725C0>,
    <traceback object at 0x00C73920>)

    And the "print sys.exc_type" gives-
    socket.herror

    How do I get the "(11004, 'host not found')" part?
    More importantly, where is the answer documented that I should
    have looked?

    Frank
     
    Frank, Jul 18, 2003
    #2
    1. Advertising

  3. Erik Max Francis

    Ian Bicking Guest

    On Fri, 2003-07-18 at 01:33, Frank wrote:
    > Using Python 2.2.2,
    > I want to catch all exceptions from "socket.gethostbyaddr(ip)"
    >
    > >From IDLE, I can generate:
    > >>> socket.gethostbyaddr('1.2')

    > Traceback (most recent call last):
    > File "<pyshell#28>", line 1, in ?
    > socket.gethostbyaddr('1.2')
    > herror: (11004, 'host not found') <=== what I want when I catch


    > When I run this code:
    > try:
    > hostname, aliases, hostip = socket.gethostbyaddr(ip)
    > return (hostip, hostname)
    > except:
    > print sys.exc_info()
    > print sys.exc_type
    > return


    try:
    do exceptional stuff...
    except Exception, e:
    print e.args, dir(e)

    Probably that information is just in e.args, but you can add other
    attributes to exceptions, any of which should be revealed by dir(e).

    Exceptions are poorly documented, so I don't know where that might be
    noted.

    Ian
     
    Ian Bicking, Jul 18, 2003
    #3
  4. > How do I get the "(11004, 'host not found')" part?
    > More importantly, where is the answer documented that I should
    > have looked?


    Look at the traceback module from the Python standard library. If you
    just wish to print the exception, do the following:

    import traceback

    try:
    nosuchobject
    except:
    traceback.print_exc()

    HTH!

    Heiko.
     
    Heiko Wundram, Jul 18, 2003
    #4
  5. On Thu, 17 Jul 2003 23:29:40 -0700, Erik Max Francis <> wrote:

    >Frank wrote:
    >
    >> Using Python 2.2.2,
    >> I want to catch all exceptions from "socket.gethostbyaddr(ip)"
    >>
    >> From IDLE, I can generate:
    >> >>> socket.gethostbyaddr('1.2')

    >> Traceback (most recent call last):
    >> File "<pyshell#28>", line 1, in ?
    >> socket.gethostbyaddr('1.2')
    >> herror: (11004, 'host not found') <=== what I want when I catch
    >>
    >> When I run this code:
    >> try:
    >> hostname, aliases, hostip = socket.gethostbyaddr(ip)
    >> return (hostip, hostname)
    >> except:
    >> print sys.exc_info()
    >> print sys.exc_type
    >> return

    >
    >Use the format:
    >
    > try:
    > ...
    > except ErrorType, e:
    > ... do something with exception object e ...
    >

    Indeed. Or if you want to catch all standard exceptions until you know what is
    happening, you could pick from the following. I guess you could also catch all
    exceptions defined in a module without knowing what they're named, and re-raise
    if other, e.g., with (untested!)

    if not repr(e.__class__).startswith('socket'): raise

    is there another way to do that?

    >>> import socket
    >>> try:

    ... socket.gethostbyaddr('1.2')
    ... except Exception, e:
    .... print 'plain e:', e
    .... print 'e class:', e.__class__
    .... print 'e class name:', e.__class__.__name__
    .... print 'vars keys:', vars(e).keys()
    .... print 'vars dict:', vars(e)
    .... print 'additional inherited clutter seen by dir:\n',dir(e)
    ....
    plain e: (11004, 'host not found')
    e class: socket.herror
    e class name: herror
    vars keys: ['args']
    vars dict: {'args': (11004, 'host not found')}
    additional inherited clutter seen by dir:
    ['__doc__', '__getitem__', '__init__', '__module__', '__str__', 'args']

    You could also print a formatted vars(e) to see unanticipated attributes more nicely
    with e.g., (untested!) print ''.join(['%16s = %r\n' %(k,v) for k,v in vars(e).items()])

    >>>> import socket
    >>>> socket.error

    ><class socket.error at 0x8154304>
    >>>> try:

    >... socket.gethostbyaddr('1.2')
    >... except socket.error, e:
    >... print e, dir(e), e.args
    >...
    >(1, 'Unknown host') ['__doc__', '__getitem__', '__init__', '__module__',
    >'__str__', 'args'] (1, 'Unknown host')
    >
    >> How do I get the "(11004, 'host not found')" part?
    >> More importantly, where is the answer documented that I should
    >> have looked?

    >
    >Check the part on exception handling.
    >

    Interactively, help('exceptions') is also helpful (note quotes)

    Regards,
    Bengt Richter
     
    Bengt Richter, Jul 18, 2003
    #5
  6. In article <U2NRa.7475$>,
    Raymond Hettinger <> wrote:
    .
    .
    .
    >You could catch it with:
    >
    > except socket.herror, inst:
    > print inst.args
    >
    >or more broadly with:
    >
    > except socket.error, (errno, string_message):
    > print code, message
    >
    >
    >> More importantly, where is the answer documented that I should
    >> have looked?

    >
    >The list of possible socket exceptions is in the docs for sockets.
    >It also describes the (errno, string) return tuple value of inst.args.

    .
    .
    .
    True.

    But unsatisfying--at least to me. I'm curious whether anyone
    else sees it the same way.

    We're talking here about <URL:
    http://www.python.org/doc/lib/module-socket.html >, I assume,
    which tells us the socket module has three exception constants
    (and what they are), and also such details as that it might be
    except socket.error, (errno, string_message)
    but that it also might be simply
    except socket.error, string_message

    It's a temptation to go rhetorical at this point, and protest
    that we would not believe any other API documented if so little
    were written about it, but that we expect this poverty for
    exceptions. Rather than promote a general manifesto, though,
    I'll just summarize that neither the manual entry, nor the
    references it provides, give definite knowledge about even the
    signature of socket exceptions. A programmer who wants preci-
    sion in regard to exceptions must either experiment, or read
    implementation sources--and sometimes both.

    So, the answer to the question is the subject line is this:
    read the manual, then play with a live system to see what
    really happens.
    --

    Cameron Laird <>
    Business: http://www.Phaseit.net
    Personal: http://phaseit.net/claird/home.html
     
    Cameron Laird, Jul 19, 2003
    #6
  7. >>> >The list of possible socket exceptions is in the docs for sockets.
    >>> >It also describes the (errno, string) return tuple value of inst.args.
    >>> .
    >>> True.
    >>>
    >>> But unsatisfying--at least to me.

    >>
    >>Submit a patch.

    > .
    > .
    > I deserved that.
    >
    > There was more to my post, of course. Part of what I was trying to
    > express is that exception interfaces are almost always relegated to
    > a footnote, with only a generalized description, even in the frequent
    > case that a method's exceptions are more complicated than its invoca-
    > tions.
    >
    > Rather than tilt at the collection of all such windmills, I want to
    > first understand better why this is, and what response is appropriate.
    > To summarize: I don't know what patch is the right one. I also
    > thought it only fair to warn Mr. July that things are indeed more dif-
    > ficult than we were explaining, even though I didn't feel up to
    > detailing the difficulties.
    >
    > So, Raymond, do you have general guidelines for how you think excep-
    > tions should be documented?


    I don't know what Raymond will suggest, but for myself I always (well,
    nearly always) when I find the docs insufficient, I'll submit a patch
    which contains what I would like to read there.
    Works pretty well so far...

    Thomas
     
    Thomas Heller, Jul 22, 2003
    #7
  8. [Cameron Laird]
    > >> But unsatisfying--at least to me.

    > >
    > >Submit a patch.

    > .
    > .
    > .
    > I deserved that.


    It wasn't a jab.
    Truly, if you see a way to clarify the docs, submit a patch.
    If everyone finds it helpful, it will be accepted. That's how
    the docs improve over time. I've personally written or
    accepted over a hundred of these in the past year.


    > There was more to my post, of course. Part of what I was trying to
    > express is that exception interfaces are almost always relegated to
    > a footnote, with only a generalized description, even in the frequent
    > case that a method's exceptions are more complicated than its invoca-
    > tions.


    No doubt, exceptions often get less explanation than everything else.
    However, in this case, the docs seemed reasonably clear to me.

    The part that could be improved is where it talks about returning a
    message or a tuple, as if either one but not both could occur at any
    time. It would be more accurate to say, that in all cases an exception
    instance is returned; the instance has a __str__ method so it can be
    printed as if it were a string; the instance has an attribute "args" which
    is the tuple (errno, errmsg); and the instance has a __getitem__ method
    so the args tuple can be directly unpacked as if the instance had been
    the tuple itself.

    OTOH, that is long-winded and distracts from the flow of knowledge
    about sockets. It is also how all exception instances work.


    > So, Raymond, do you have general guidelines for how you think excep-
    > tions should be documented?


    Unless there are interesting values being returned, it is probably
    sufficient to name the exception, state what it represents, and
    describe where it fits in the class structure (i.e. socket.herror is a
    subclass of socket.error). When you think about it, why have
    three paragraphs on an exception whose code is as simple as:

    class xyzException(Exception): pass # raised when xyz occurs

    When interesting values are returned, describe the meaning of
    each element in the instance's arg tuple (i.e. (errno, errmsg)).
    Afterall, the code behind it may be as simple as:

    raise socket.herror(errno, errmsg) # reveal the packet's error information

    Elsewhere in the docs, functions descriptions should list the names
    of the exceptions they can raise unless it is obvious or pertains
    to a whole collection of functions (i.e. all high-volume socket
    operations can potentially raise a timeout).

    In general, I like the documents to be as specific as possible without
    replicating the code or locking in a particular implementation. However,
    there is a competing force to keep module documents centered on how
    to use the module. For example, I found the unittest documentation to
    be highly specific and thorough, yet unsatisfactory because you practically
    had to read a book on the subject to be able to make basic use of the
    module. To fix it, I added a new introductory section that covers
    (in one page) the 5% of the module that will meet 95% of your needs
    (enough to get you up and running).


    Raymond Hettinger
     
    Raymond Hettinger, Jul 22, 2003
    #8
  9. Erik Max Francis

    Frank Guest

    On Tue, 22 Jul 2003 17:59:48 GMT, "Raymond Hettinger"
    <> wrote:

    >[Cameron Laird]
    >> >> But unsatisfying--at least to me.
    >> >
    >> >Submit a patch.

    >> .
    >> .
    >> .
    >> I deserved that.

    >
    >It wasn't a jab.
    >Truly, if you see a way to clarify the docs, submit a patch.
    >If everyone finds it helpful, it will be accepted. That's how
    >the docs improve over time. I've personally written or
    >accepted over a hundred of these in the past year.
    >
    >
    >> There was more to my post, of course. Part of what I was trying to
    >> express is that exception interfaces are almost always relegated to
    >> a footnote, with only a generalized description, even in the frequent
    >> case that a method's exceptions are more complicated than its invoca-
    >> tions.

    >
    >No doubt, exceptions often get less explanation than everything else.
    >However, in this case, the docs seemed reasonably clear to me.
    >
    >The part that could be improved is where it talks about returning a
    >message or a tuple, as if either one but not both could occur at any
    >time. It would be more accurate to say, that in all cases an exception
    >instance is returned; the instance has a __str__ method so it can be
    >printed as if it were a string; the instance has an attribute "args" which
    >is the tuple (errno, errmsg); and the instance has a __getitem__ method
    >so the args tuple can be directly unpacked as if the instance had been
    >the tuple itself.
    >
    >OTOH, that is long-winded and distracts from the flow of knowledge
    >about sockets. It is also how all exception instances work.
    >
    >
    >> So, Raymond, do you have general guidelines for how you think excep-
    >> tions should be documented?

    >
    >Unless there are interesting values being returned, it is probably
    >sufficient to name the exception, state what it represents, and
    >describe where it fits in the class structure (i.e. socket.herror is a
    >subclass of socket.error). When you think about it, why have
    >three paragraphs on an exception whose code is as simple as:
    >
    > class xyzException(Exception): pass # raised when xyz occurs
    >
    >When interesting values are returned, describe the meaning of
    >each element in the instance's arg tuple (i.e. (errno, errmsg)).
    >Afterall, the code behind it may be as simple as:
    >
    > raise socket.herror(errno, errmsg) # reveal the packet's error information
    >
    >Elsewhere in the docs, functions descriptions should list the names
    >of the exceptions they can raise unless it is obvious or pertains
    >to a whole collection of functions (i.e. all high-volume socket
    >operations can potentially raise a timeout).
    >
    >In general, I like the documents to be as specific as possible without
    >replicating the code or locking in a particular implementation. However,
    >there is a competing force to keep module documents centered on how
    >to use the module. For example, I found the unittest documentation to
    >be highly specific and thorough, yet unsatisfactory because you practically
    >had to read a book on the subject to be able to make basic use of the
    >module. To fix it, I added a new introductory section that covers
    >(in one page) the 5% of the module that will meet 95% of your needs
    >(enough to get you up and running).
    >
    >
    >Raymond Hettinger
    >

    Thanks to all for your help.

    After checking that the input is a string, I try calling
    gethostbyname/addr depending on whether the first char is numeric and
    catch:
    "except socket.error, err:"
    Will this catch all possible errors? I've tried feeding various
    errors into my def and caught them all so far. Input might come from
    users at the keyboard, and crashing the program is not an option, no
    matter what is typed in.
    ------------------------------------
    I did look for the solution before posting; I checked:
    Python Lib Ref 2.2.2
    Python Language Ref 2.2.2
    Lutz - Learning Python
    Lutz - Programming Python, 2nd
    Holden - Python Web Programming
    Brueck - Python 2.1 Bible
    Martelli - Python in a Nutshell
    and even Guido's Tutorial. If the complete answer is there, I could
    not find it or assemble all the parts from the various references.
    Perhaps with more experience in Python it would have been clearer, but
    I have to agree with those that say exceptions are not well
    documented. Complete and precise documentation is probably more
    important for a language/compiler/interpreter system than any anything
    else.

    Frank
     
    Frank, Jul 24, 2003
    #9
  10. On Tue, 22 Jul 2003 16:44:04 -0000, (Cameron Laird) wrote:

    >Raymond Hettinger <> wrote:
    >>> >You could catch it with:
    >>> >
    >>> > except socket.herror, inst:
    >>> > print inst.args
    >>> >
    >>> >or more broadly with:
    >>> >
    >>> > except socket.error, (errno, string_message):
    >>> > print code, message
    >>> >
    >>> >
    >>> >> More importantly, where is the answer documented that I should
    >>> >> have looked?
    >>> >
    >>> >The list of possible socket exceptions is in the docs for sockets.
    >>> >It also describes the (errno, string) return tuple value of inst.args.
    >>> .
    >>> .
    >>> .
    >>> True.
    >>>
    >>> But unsatisfying--at least to me.

    >>
    >>Submit a patch.

    > .
    > .
    > .
    >I deserved that.
    >
    >There was more to my post, of course. Part of what I was trying to
    >express is that exception interfaces are almost always relegated to
    >a footnote, with only a generalized description, even in the frequent
    >case that a method's exceptions are more complicated than its invoca-
    >tions.
    >
    >Rather than tilt at the collection of all such windmills, I want to
    >first understand better why this is, and what response is appropriate.
    >To summarize: I don't know what patch is the right one. I also
    >thought it only fair to warn Mr. July that things are indeed more dif-
    >ficult than we were explaining, even though I didn't feel up to
    >detailing the difficulties.
    >
    >So, Raymond, do you have general guidelines for how you think excep-
    >tions should be documented?


    ISTM there are (at least) two important places for doc info: Code-associated and
    language/tool-usage-associated. There are docs we approach as docs like books to read,
    and there are embedded docs as in doc strings and comments. And pydoc sort of
    bridges the gap and makes a book from code and whatall.

    I wonder where the best place is to enhance the documentation accessible to users.
    I suspect it would be in the area of pydoc and the structure of "code and whatall."
    The most likely place to find up-to-date info is in the latest code. (See below
    for an idea of how to enhance the latest code doc info without changing known-good
    code source).

    Exceptions (subject topic ;-) are a special case. In principle any code documentation
    could be enhanced by adopting source conventions to help pydoc present better info.
    The question then becomes how best to format the doc-enhancing info, where to put it,
    and how best to support its presentation.

    One thing that is a deterrent to improved documentation *within* code is that people
    like to minimize the number of official code versions, whether by CVS or just noting
    MD5 digests etc., and/or by burning an "official" CDROM. This makes me wonder if it would
    make sense to have a way to store doc info separately, yet still integratable into a pydoc
    presentation.

    One way would be to have a file name convention, so that the optional doc-enhancement
    info for e.g., xxx.py would be found in, e.g., xxx.dpy. This could make a clutter of small
    files though, so maybe one or more .dpx files could contain the mapping from multiple
    small related sources to a single .dpy. And by convention .dpy info for packaged files
    would be looked for in a .dpy for the overall package if not found separately.

    Ok, we could hone this search mechanism. What about the structure of .dpy files themselves,
    which now potentially could have info enhancing docs for both xxx.py and yyy.py?

    Some kind of easy internal labeled sections to separate xxx.py from yyy.py info
    would seem obvious. Then, the real question: what goes in the .dpy section for xxx.py
    so as to tie into certain parts of xxx.py code, without requiring changes to that code
    (which, remember, may be on a CDROM etc)?

    The context-finding mechanism of diff/patch would be one option, but to use that literally
    would make the .dpy files into diff files, and probably not something easy to generate
    manually and readably. And you don't want to carry a whole source fork just to maintain
    doc enhancement .dpy files. So we need some conventions functionally to enable human-doable
    doc diff patches. Maybe with special easy syntax to refer to exception raising loci
    in the code vs catching, vs functions, classes, methods, existing doc strings, etc, etc.

    An advantage of pure doc-enhancement info is that a mistake can't break the actual code,
    so more people could be given commit privileges for that kind of files, if maintained
    separately on CVS. Even wide-open wiki methods could be considered. You could even configure
    pydoc to query python.org efficiently to check if a local cache is out of date, and prompt
    for optional download.

    But this is a matter of arriving at some PEP consensus after discussing 1) whether it's
    worth discussing, and 2) what the usability goals are for both users and creators of
    doc enhancement info, and 3) who has the time to follow up on stuff like this.
    Just writing this post cost something, as will your replies (if any ;-)

    Regards,
    Bengt Richter
     
    Bengt Richter, Jul 24, 2003
    #10
  11. [Raymond]
    > >The part that could be improved is where it talks about returning a
    > >message or a tuple, as if either one but not both could occur at any
    > >time. It would be more accurate to say, that in all cases an exception
    > >instance is returned; the instance has a __str__ method so it can be
    > >printed as if it were a string; the instance has an attribute "args" which
    > >is the tuple (errno, errmsg); and the instance has a __getitem__ method
    > >so the args tuple can be directly unpacked as if the instance had been
    > >the tuple itself.


    [Frank]
    > After checking that the input is a string, I try calling
    > gethostbyname/addr depending on whether the first char is numeric and
    > catch:
    > "except socket.error, err:"
    > Will this catch all possible errors? I've tried feeding various
    > errors into my def and caught them all so far. Input might come from
    > users at the keyboard, and crashing the program is not an option, no
    > matter what is typed in.


    Yes, that will catch all errors. You have bound the instance to "err".

    As I said earlier, the part of the docs that some folks may
    find confusing is that part about returning a string or a tuple.
    In fact, it always returns an instance that can be printed like
    a string *and* unpacked like a tuple.

    I'll modify the docs to make this more clear.

    If you're in an experimental frame of mind, it is straight-forward to
    learn exactly what is going on by adding a few print statements:

    except socket.error, inst:
    print 'Caught a', type(inst) # show that an exception instance was
    recd
    print 'The inst can be printed like a string:', inst
    errno, errmsg = inst # show the exception can be unpacked
    print 'It contains a tuple with', errno, 'and', errmsg
    print 'Its methods are', dir(inst)
    print 'The data is kept in inst.args', inst.args
    print 'It prints because of the __str__ method:', inst.__str__()
    print 'That is my story and I am sticking with it!'


    Raymond Hettinger




    Raymond Hettinger
     
    Raymond Hettinger, Jul 27, 2003
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Vasanth
    Replies:
    0
    Views:
    599
    Vasanth
    Jun 28, 2004
  2. Jonah Olsson

    How to get most info from exception

    Jonah Olsson, Feb 16, 2004, in forum: ASP .Net
    Replies:
    8
    Views:
    477
    John Saunders
    Feb 17, 2004
  3. Andrea Williams

    Clear the Render info & change to different info

    Andrea Williams, Oct 27, 2004, in forum: ASP .Net
    Replies:
    2
    Views:
    1,456
    Ken Dopierala Jr.
    Oct 27, 2004
  4. alejandrina
    Replies:
    8
    Views:
    849
    alejandrina
    Aug 30, 2007
  5. ilya

    get CPU info, RAM info

    ilya, Apr 8, 2010, in forum: Java
    Replies:
    43
    Views:
    6,251
    Mike Schilling
    Apr 19, 2010
Loading...

Share This Page