[Tutor] try..except - what about that ton of **Error statements?

[Marc Tompkins]

On Tue, May 21, 2013 at 11:25 PM, Bod Soutar <bodsda at googlemail.com> wrote:

> On 22 May 2013 07:20, Jim Mooney <cybervigilante at gmail.com> wrote:
> >> Keep the try block small. For example if it's for a call to
> >> open(filename, "r") the only possible errors (assuming correct syntax)
> >> are NameError for using an undefined variable and IOError for
> >> specifying a file which doesnt exist.
> >
> > Thanks. Since I'm new at this the error lists I saw just had the bald
> > names, which didn't tell me much. But I found a concise and basic
> > explanation of each error at
> > http://python.about.com/od/pythonstandardlibrary/a/lib_exceptions.htm
> >
> > Although it's still a bit circular at my level. I won't be sure what
> > errors to raise until I see enough errors, but that will come with
> > experience, I guess. Now I just have to figure how to print the list
> > out without the ads ;')
> >
> > Jim
> > _______________________________________________
> > Tutor maillist  -  Tutor at python.org
> > To unsubscribe or change subscription options:
> > http://mail.python.org/mailman/listinfo/tutor
>
> One thing I tend to do is fire up the interpreter and deliberately
> write something that should fail, then I can see what error is raised.
> For example, when I suggested the open() test, I fired up the
> interpreter and tried
>
> >>> open(dave, "r")
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> NameError: name 'dave' is not defined
>
> >>> open("dave2", "r")
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> IOError: [Errno 2] No such file or directory: 'dave2'
>

I would just like to contribute my $.02 worth here and say: be VERY
conservative about assuming that you know what the error was/what caused
it.  As a user, and as support for users, nothing irritates me more than a
program that lies to me (unintentionally, of course) about what's wrong.
Case in point: back in the 80s and early 90s, "out of memory" errors were
extremely common - not necessarily because memory was actually scarce (it
WAS, but we knew how to deal with that) but because that was the default
error code if nothing else matched.  The actual error was sometimes "file
not found", or "printer not plugged in", or something else equally
unrelated to an actual shortage of memory - but because the programmer had
1) not foreseen the particular problem and 2) put in a catch-all that
assumed that "all errors not otherwise specified" were "out of memory",
troubleshooting was much harder than it should have been.

In short: if you're going to take the "catch all errors" approach (instead
of simply predicting what the most common errors might be), always let the
default be either to display the error and a traceback (in a dialog box,
for example) or to actually let the program crash and display the error on
stdout.  If you try to be too clever, your users will end up hating you for
it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tutor/attachments/20130522/7be76fa9/attachment.html>