Thanks, Alan and Ben! I really appreciate your explanations. Degreat
----- Reply message ----- From: "Ben Finney" <ben+pyt...@benfinney.id.au> To: <tutor@python.org> Subject: [Tutor] Unhandled exception Date: Mon, Jul 21, 2014 11:16 "yarteydegre...@gmail.com" <yarteydegre...@gmail.com> writes: > I just want to know if an unhandled exception is a bug in my programs! That's a good question, thanks for asking. In some programming languages, exceptions are something to avoid and reduce where possible. But that's not the case for Python. In Python, exceptions are a fundamental part of the program flow. When a function call (or some other part of a program) encounters a circumstance where “this is the result” doesn't make sense, the correct idiom is to raise an exception with rich information about what the exceptional situation was. For example, a procedure for “divide number foo by number bar” should usually return a numeric result. If one of the values is not a number, though, no result makes sense; a ValueError exception is raised. If they *are* both numbers, but the second (the denominator) is zero, there's still no sensible result to return; instead, it makes more sense to raise a ZeroDivisionError. Another example: a procedure for “get me the next item from this sequence” should usually return the item as a value. If the sequence *has* no more items, though, no value makes sense to return; a StopIteration exception is raised. An example you are likely familiar with: Your Python program can run at a text console, or maybe you're writing some Python code at the interactive Python shell. This usually reads a line of text from your console, and goes on to process the result as a line of text. If you want to stop the session, though, you can press the console's “interrupt” key (Ctrl+C, or Ctrl+Z on some systems). No particular line of text makes sense as a result, so a KeyboardInterrupt exception is raised. In all these cases, the exception is raised because no return value makes sense, and *something* needs to deal with the fact that the typical path through the code can't continue. Exceptions are normal :-) So, in light of all that: If your code is written to expect specific exceptions, you can catch them (by the type of exception) and handle them at an appropriate point. If not, they end your program at the top level reporting that the exception was unhandled. Whether they are an *error* is a matter of what your intention was. If you weren't intending the program to encounter that exception, then yes! But exceptions are a normal part of Python control flow, and often they are exactly what is needed. -- \ “The Things to do are: the things that need doing, that you see | `\ need to be done, and that no one else seems to see need to be | _o__) done.” —Richard Buckminster Fuller, 1970-02-16 | Ben Finney _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
_______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
