On Sat, 11 Sep 2010 04:47:13 am Michael Powe wrote:
> No problem, I am working on getting this sorted out. The
> documentation seems to be written as reminder for people who already
> know how this stuff works, rather than as a clear explanation for
> anybody working with it.
That's because the job of documentation is to be documentation, not a
tutorial.
Admittedly, sometimes it's hard to draw a line between the two, but you
have to assume *some* knowledge of the reader -- imagine if every time
you tried to document some piece of code, you had to start explaining
what variables are.
In this case, the Fine Manual is plenty clear. The example in the
tutorial shows:
try:
...
except ValueError:
...
http://docs.python.org/tutorial/errors.html#handling-exceptions
There's no need to add an error message to the ValueError:
# this does NOT work
except ValueError("I never know what message to expect"):
There's nothing in any of the documentation I've ever seen that suggests
that catching an exception requires you to specify the exact error
message. Since error messages are subject to change without warning, or
translation into other languages, this wouldn't be practical even if it
could work (which it doesn't).
It does require a bit more knowledge to decipher the main documentation:
http://docs.python.org/reference/compound_stmts.html#try
http://docs.python.org/reference/executionmodel.html#exceptions
but as I said, this is not a tutorial. They are written for
non-beginners. If you need a tutorial, do the tutorial, and don't
expect the documentation to be all things to all users.
Or read example code in the standard library. If you pick a random
module and read it, you can expect to find exception handling. See what
other coders do.
> Eventually, I arrived at a workable conclusion by wrapping only the
> call in main and using your suggested 'as' clause.
If you're focused on the 'as' clause part, you're still missing the
point.
> This successfully
> suppresses the traceback and gives a useable error message.
> Although, in the case of URLError, 'getaddrinfo failed' may not
> actually mean much to the end user, it'll have to do.
>
> I don't like the fact that I cannot locate my thrown exception at the
> point of throwing
Of course you can.
> -- i.e., I don't necessarily mind catching the
> exception in main but I would like to be able to print out exactly
> where the exception occurred. This is more useful when
> troubleshooting.
Err, that's exactly what the stacktrace is for -- it shows the execution
chain that failed.
> However, an entire stacktrace is unacceptably verbose.
For who? You, the developer, or for an end user?
If you mean for an end user, I agree. Stack traces aren't written for
them.
If you mean for you, the developer, then I'm sorry, but I find that a
bogus attitude. It's true that *most of the time* the only part of the
stack trace that you (generic you) will look at is the final call, but
there are many, many times when you need to see the entire call chain
to determine what's going on.
Anyway, be glad this is Python. In a former life, I worked for a company
that had just installed a SAP accounting application. One day the
application crashed, and printed out a stack trace direct to the
printer. It was over fifty pages of tightly-written 9pt font.
Seriously.
We called the developers and asked what they wanted us to do with it,
and they said to throw it out.
--
Steven D'Aprano
_______________________________________________
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
