3 ms·

I think Python's exceptions work pretty well, but how do you make use of the hierarchy? It's not clear to me from this example. I find myself using Python exc

by chubot 10y ago

I think Python's exceptions work pretty well, but how do you make use of the hierarchy? It's not clear to me from this example. I find myself using Python exceptions in two pretty disjoint cases: 1) try/catch around a single line, where the exception is as specific as possible (e.g. KeyError, etc.). To do something specific in the error case, perhaps decrement a retry count. (Although this is one of those places where "exceptions should be exceptional" comes to mind; I don't like "except" for normal control flow...) 2) try/catch around main(), where the exception is as general as possible. To log the exceptions, or perhaps print a usage message. There doesn't seem to be much usage between those two extremes. I recently read "The Design and Evolution of C++" by Stroustrop, and it was not obvious to them to use the class hierarchy for exceptions. I'm not sure exactly where the idea originated from. (He also talks about resume after exceptions, which sounds insane today, but was pretty heavily debated at the time.) Go has no class hierarchy, and I believe the error handling is with an Error interface. Although I guess is does have some kind of subtyping by creating a more specific interface than Error by adding methods.

Animats 10y ago
The class hierarchy for exceptions is a library standardization concept in Python. Exceptions were rather haphazard in early Python, but got organized around Python 2.6-2.7. All exceptions descend from "Exception". Usually, though, you don't want to catch that. If you do, it's usually to log the error or report it someplace before aborting the program. "EnvironmentError" includes most of the things that can go wrong external to the program; it subsumes OSError and IOerror and all the networking/HTTP errors. Modules which do I/O or network operations should catch EnvironmentError and do something about it. Your GUI program or web service shouldn't abort for an EnvironmentError. Code can and should catch more specific errors at lower levels, but a backup exception handler for EnvironmentError is useful for when something that "never" fails does fail. I have a moderately large Python system which reads and processes arbitrary web pages, trying to rate web sites. Such a program sees all the things that can go wrong with networking, HTTP, and HTML. Functions in standard packages functions sometimes raise unexpected exceptions. None of those events are abort conditions; they have to be dealt with as ordinary problems. Some errors require "try again", some require "try again later", and some require "never try again". Errors log to the database, not a log file, and some are reported on the rating page for a site. The point of all this is to have a system which requires very little human attention. It's been several years since I had to deal with a system failure manually.

by chubot 10y ago

Animats 10y ago

The class hierarchy for exceptions is a library standardization concept in Python. Exceptions were rather haphazard in early Python, but got organized around Python 2.6-2.7. All exceptions descend from "Exception". Usually, though, you don't want to catch that. If you do, it's usually to log the error or report it someplace before aborting the program. "EnvironmentError" includes most of the things that can go wrong external to the program; it subsumes OSError and IOerror and all the networking/HTTP errors. Modules which do I/O or network operations should catch EnvironmentError and do something about it. Your GUI program or web service shouldn't abort for an EnvironmentError. Code can and should catch more specific errors at lower levels, but a backup exception handler for EnvironmentError is useful for when something that "never" fails does fail. I have a moderately large Python system which reads and processes arbitrary web pages, trying to rate web sites. Such a program sees all the things that can go wrong with networking, HTTP, and HTML. Functions in standard packages functions sometimes raise unexpected exceptions. None of those events are abort conditions; they have to be dealt with as ordinary problems. Some errors require "try again", some require "try again later", and some require "never try again". Errors log to the database, not a log file, and some are reported on the rating page for a site. The point of all this is to have a system which requires very little human attention. It's been several years since I had to deal with a system failure manually.