Rene Pijlman wrote: > One of the things I dislike about Java is the need to declare exceptions > as part of an interface or class definition. But perhaps Java got this > right... > > I've writen an application that uses urllib2, urlparse, robotparser and > some other modules in the battery pack. One day my app failed with an > urllib2.HTTPError. So I catch that. But then I get a urllib2.URLError, so > I catch that too. The next day, it encounters a urllib2.HTTPError, then a > IOError, a socket.timeout, httplib.InvalidURL,... > > How do you program robustly with these modules throwing all those > different (and sometimes undocumented) exceptions at you?
I do it by not micromanaging things. Presumably if you plan to catch an exception, you have a specific procedure in mind for handling the problem. Maybe a retry, maybe an alternate way of attempting the same thing? Look to the code that you are putting in those except: statements (or that you think you want to put in them) to decide what to do about this situation. If each type of exception will be handled in a different manner, then you definitely want to identify each type by looking at the source or the docs, or doing it empirically. Most of the time there isn't a whole lot of real "handling" going on in an exception handler, but merely something like logging and/or reporting it onscreen in a cleaner fashion than a traceback, then failing anyway. This is one reason Java does get it wrong: 95% of exceptions don't need and shouldn't have special handling anyway. Good code should probably have a very small set of real exception handling cases, and one or two catchalls at a higher level to avoid barfing a traceback at the user. > A catchall seems like a bad idea, since it also catches AttributeErrors > and other bugs in the program. Generally speaking this won't be a problem if you have your catchalls at a fairly high level and have proper unit tests for the lower level code which is getting called. You are doing unit testing, aren't you? ;-) -Peter -- http://mail.python.org/mailman/listinfo/python-list
