How do I get info on an exception ?

[Frank]

On Tue, 22 Jul 2003 17:59:48 GMT, "Raymond Hettinger"
<vze4rx4y at verizon.net> 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