2009/10/18 Steven D'Aprano <st...@remove-this-cybersource.com.au>: > That confuses me. If I call: > > y = mydict[x] > > how does my knowledge of what to do if x is not a key relate to whether > the language raises an exception, returns an error code, dumps core, or > prints "He's not the Messiah, he's a very naughty boy" to stderr? > > You seem to be making a distinction of *intent* which, as far as I can > tell, doesn't actually exist. What's the difference in intent between > these? > > y = mydict[x] > if y == KeyErrorCode: > handle_error_condition() > process(y) > > > and this? > > try: > y = mydict[x] > except KeyError: > handle_error_condition() > process(y)
Nothing -- because both of those are at the level of code where you know what to do with the error condition. But if you weren't -- if, for example, you were in a library routine and had no idea how the routime might be used in the future -- the latter would just become: y = mydict[x] and the problem is passed on until it gets to somebody who does know. In the former case, though, you still need all the error handling code even though you don't know how to handle the error, *and* you need to exit with an error code of your own, *and* your client needs error handling code even though /they/ might not know how to handle the error, and so on. > Neither assumes more or less knowledge of what to do in > handle_error_condition(). Neither case assumes that the failure of x to > be a key is an error: They both assume that calling handle_error_condition() is an appropriate response. >> That's why they have the overhead that they do. > > Exceptions don't have one common overhead across all languages that use > them. They have different overhead in different languages -- they're very > heavyweight in C++ and Java, but lightweight in Python. As others have pointed out, Python exceptions are cheap to set up, but decidedly less cheap to invoke. But I'm not making the efficiency argument, I'm making the clarity argument. I don't /quite/ believe that Premature Optimisation is the root of all evil, but I wouldn't avoid exceptions because of the overhead. In the rare cases where the response to an exceptional condition is time (or resource?)-critical I'd consider that case to need special handling anyway, and so wouldn't treat it as an exception. >>> Python uses exceptions for flow control: >> >> Yes, and in some cases I think that's a serious language wart. Not >> enough to put me off the language, but a serious wart nevertheless. > > I think exceptions are a beautiful and powerful way > of dealing with flow control, much better than returning a special code, > and much better than having to check some status function or global > variable, as so often happens in C. They're more restricted, and > therefore safer, than goto. They're not a panacea but they're very useful. I agree completely -- when they're used in appropriate circumstances. Not when they're not. > I think you're confused about what list.index(obj) does. You seem to me > to be assuming that [1,2,3].index(5) should return the item in position 5 > of the list, and since there isn't one (5 is out of bounds), raise an > exception. But that's not what it does. It searches the list and returns > the position at which 5 is found. Yes, sorry, brain fade. But my point remains that the authors of index can't know whether the item not being in the list is an error or not, can't know how to handle that case, and so passing it to the client as an exception is an appropriate response. > No, it's not being killed from outside the program -- it's being > *interrupted* from *inside* the program by the user. Who -- unless AI has advanced further than I thought -- is *outside* the program. -- Tim Rowe -- http://mail.python.org/mailman/listinfo/python-list
