开发者

Python using exceptions for control flow considered bad?

开发者 https://www.devze.com 2023-04-01 03:18 出处:网络
All right, I\'ve seen this multiple times in the past, but most recently with my que开发者_运维知识库stion here. So, I\'m curious why this is the case, in python because generators use exceptions to

All right,

I've seen this multiple times in the past, but most recently with my que开发者_运维知识库stion here. So, I'm curious why this is the case, in python because generators use exceptions to indicate the end of the data.

If this is so bad for everyone using python, why does the language include it in what are considered fundamental control structures? For those who want to read the relevant PEP go here.


Because ending the generator is not a common event (I know it will always happen, but it only happens once). Throwing the exception is considered expensive. If an event is going to succeed 99% of the time and fail 1%, using try/except can be much faster than checking if it's okay to access that data (it's easier to ask forgiveness than permission).

There's also a bias against it since try/except blocks used like that can be very difficult to understand. The flow control can be difficult to follow, while an if/else are more straightforward. The try/except means you have to track the flow control of the statements inside the try and inside of the functions it calls (as they may throw the exception and it may propagate upwards. An if/else can only branch at the point when the statement is evaluated.

There are times when using try/except is correct and times when if/else make more sense. There are also performance costs associated with each of them. Consider:

a = <some dictionary>
if key in a:
    print a[key]

vs.

a = <some dictionary>
try:
    print a[key]
except KeyError:
    pass

The first will be faster if key does not exist inside of a and will only be slightly (almost unnoticeable) slower if it does exist. The second will be faster if the key does exist, but will be much slower if it doesn't exist. If key almost always exists, you go with the second. Otherwise, the first works better.

EDIT: Just a little thing to add about Python try/except that helps greatly with one of the readability problems.

Consider reading from a file.

f = None
try:
    f = open(filename, 'r')
    ... do stuff to the file ...
except (IOError, OSError):
    # I can never remember which one of these Python throws...
    ... handle exception ...
finally:
    if f:
        f.close()

Now anything in the do stuff to the file can throw an exception and we'll catch it. Commonly, you try to keep as little code as possible in the try for this reason. Python has an optional else clause for the try that will only be run if the try ran to completion without hitting an exception.

f = None
try:
    f = open(filename, 'r')
except (IOError, OSError):
    pass
else:
    ... do stuff to the file ...
finally:
    if f:
        f.close()

In this case, you would not have any of the readability problems since only one statement is in the try; it is a python standard library function call and you're catching only specific exceptions.


Because exceptions are raised up the stack, they are appropriate for some cases where you want code that uses other code to be able to catch the exception. For example, consider the case where you want to create an iterator that uses part of another iterator more "manually", it's valuable to have an exception you can catch from higher up the stack and insert your own logic.


Using try blocks for flow control all the time could produce code like this:

try:
  # stuff
  try:
    if userCondition:
      raise NeedToDoSomethingElseException
    try:
      # stuff
    except NeedToDoSomethingElseException:
      # other stuff
  except NeedToDoSomethingElseException:
    # other stuff
except NeedToDoSomethingElseException:
  # other stuff

Performance concerns aside, this is not very elegant. So, sometimes it's perfectly appropriate to use try, but not for everything.

0

精彩评论

暂无评论...
验证码 换一张
取 消