On 2010-12-05, Harishankar <v.harishan...@gmail.com> wrote: >> Or consider this code: >> >> if y != 0: >> result = x/y >> else: >> handle_division_by_zero() >> >> >> This is also unsafe unless you know the type of y. Suppose y is an >> interval quantity that straddles zero, then division by y may fail even >> though y != 0. > > Of course in each of these cases the in-built exceptions are used to > verify the result of certain system level or lower level operations. My > object was not to deprecate the system-level or other low level > exceptions thrown by Python, but to consider whether such a mechanism > would be a preferable method of handling your own programs error- > conditions.
Whether you happen to like the exception mechanism and syntax or not, it is the idiomatic way of handling errors in Python. Using two different conventions in your code will lead to confusion. I come from a long C background as well. I have come to appreciate the power the Python's exception handling provides. It does everything that you need to do with passing values in C and more. > The issue to be considered by every programmer is to define what can be > defined as the exceptional condition and what is a condition that merits > merely different treatment without causing disruption of the normal flow > of the program. That is an issue much harder to define. Anything it is an obvious error *should* throw an exception. Invalid input is an error. Unusable hardware states are errors. Any invalid request to an object, is an error. Essentially anything that deviates from a normal flow of a program, to handle an exceptional condition, is an error Where it becomes less obvious is when you start using exceptions as part normal control flow. An example is a try it and see methodology. You might for instance have a group of file objects which might or might not support a particular method attribute. You might have a preference for using the attribute; but, have a fallback plan if it does not. One way to handle this is to try to use the attribute and catch the exception raised if it is not present to execute your backup method. I have found this *essential* in some marsaling enviroments where you might not have access to the meta-data of the object that you are working with. Another, questionable but useful use, is to ignore the complex accounting of your position inside of a complex data structure. You can continue moving through the structure until an exception is raised indicating that you have reached a boundary of the structure. Whether you accept uses of exceptions like these is more of a personal quesion. Like many good tools, they can be useful in ways that they were never really designed to be and I would hate to proclude some of these really useful features. This can, of course, be easily abused. I was once writing code, involving complex object marshaling like I described above, with a partner who wasn't totally familiar with Python. We came to a situation where it was impossible to know ahead of time what kind of object (one of two possiblities) we would receive from another marshalled object and had no meta-data to be able to figure out before attempting to access the object. I used a try/except clause to resolve the problem. The next day, I found several poorly conceived try/except blocks in the codebase that my partner had used for control structures using dictionaries because he didn't know of dict.has_key(). I was not so pleased. -- http://mail.python.org/mailman/listinfo/python-list