On Thu, Oct 23, 2014 at 11:04 PM, Ben Finney <ben+pyt...@benfinney.id.au> wrote: > boB Stepp <robertvst...@gmail.com> writes: > [...] > >> I have so far been unable to find a list of these class/subclass >> names. > > The standard library documentation's chapter on exceptions > <URL:https://docs.python.org/3/library/exceptions.html> shows > <URL:https://docs.python.org/3/library/exceptions.html#exception-hierarchy>. >
As with Danny, thanks Ben. This is what I was trying to find [...] > > More importantly, though, you should consider *why* you're attempting to > catch a lot of exception classes. Will you be meaningfully handling > every one of those situations? That's rather doubtful. > > Instead, you should consider which exceptional states your code can > meaningfully handle, discover what excpetion classes are raised for > those few situations, and catch *only* those classes. > In the programs I have been dabbling in at work, I am often "surprised" by the situations my users stumble into that I did not have sufficient imagination to consider up front. And in line with your statements I have often wondered if I had done enough error checking, or whether in some instances I was doing too much. Trying to imagine what the user might do is often a difficult exercise, especially as my programs have been becoming more lengthy and complex. I suppose this gets easier with more knowledge and experience? > Any other exception that gets raised isn't something you can do anything > useful with, so it should propagate back up to higher levels, either to > be handled or to exit with a useful error message. > As a user of software I have often wished that the error messages generated were understandable and help me to avoid the condition which triggered that message in the future. -- boB _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
