On Tue, May 21, 2013 at 11:25 PM, Bod Soutar <bod...@googlemail.com> wrote:
> On 22 May 2013 07:20, Jim Mooney <cybervigila...@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@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.
_______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
