前言

Python的異常處理能力非常強大，但是用不好也會帶來負面的影響。我平時寫程序的過程中也喜歡使用異常，雖然采取防御性的方式編碼會更好，但是交給異常處理會起到偷懶作用。偶爾會想想異常處理會對性能造成多大的影響，于是今天就試著測試了一下。

Python異常(谷歌開源風格指南)

tip:

允許使用異常, 但必須小心。

定義:

異常是一種跳出代碼塊的正?？刂屏鱽硖幚礤e誤或者其它異常條件的方式。

優(yōu)點:

正常操作代碼的控制流不會和錯誤處理代碼混在一起. 當某種條件發(fā)生時, 它也允許控制流跳過多個框架. 例如, 一步跳出N個嵌套的函數(shù), 而不必繼續(xù)執(zhí)行錯誤的代碼。

缺點:

可能會導致讓人困惑的控制流. 調(diào)用庫時容易錯過錯誤情況。

結論:

異常必須遵守特定條件:

像這樣觸發(fā)異常: raise MyException("Error message") 或者 raise MyException . 不要使用兩個參數(shù)的形式( raise MyException, "Error message" )或者過時的字符串異常( raise "Error message" )。
模塊或包應該定義自己的特定域的異?；? 這個基類應該從內(nèi)建的Exception類繼承. 模塊的異?；悜摻凶觥盓rror”。

class Error(Exception):
  pass 

永遠不要使用 except: 語句來捕獲所有異常, 也不要捕獲 Exception 或者 StandardError , 除非你打算重新觸發(fā)該異常, 或者你已經(jīng)在當前線程的最外層(記得還是要打印一條錯誤消息). 在異常這方面, Python非常寬容, except: 真的會捕獲包括Python語法錯誤在內(nèi)的任何錯誤. 使用 except: 很容易隱藏真正的bug。

盡量減少try/except塊中的代碼量. try塊的體積越大, 期望之外的異常就越容易被觸發(fā). 這種情況下, try/except塊將隱藏真正的錯誤。

使用finally子句來執(zhí)行那些無論try塊中有沒有異常都應該被執(zhí)行的代碼. 這對于清理資源常常很有用, 例如關閉文件。
當捕獲異常時, 使用 as 而不要用逗號. 例如

try:
  raise Error
except Error as error:
  pass

設計實驗方式

采取比較簡單直觀的對照實驗。

先定義一個裝飾器，用來計算每個函數(shù)執(zhí)行所需時間：

def timer(func):
  import time
  def wrapper(*args, **kwargs):
    startTime = time.time()
    f = func(*args, **kwargs)
    endTime = time.time()
    passTime = endTime - startTime
    print "執(zhí)行函數(shù)%s使用了%f秒" % (getattr(func, "__name__"), passTime)
    return f
  return wrapper

然后用該裝飾器裝飾測試的函數(shù)即可。

再定義一個叫do_something的函數(shù)，這個函數(shù)中就做一件事，把1賦值給變量a。在每個測試函數(shù)中，都會調(diào)用這個函數(shù)1000000次。

do_something:

def do_something():
  a = 1

我根據(jù)情況設計了不同的測試組：

測試組1（直接執(zhí)行耗時操作）:

@timer
def test1():
  for _ in xrange(1000000):
    do_something()

測試組2（耗時操作放在try中執(zhí)行，不拋出錯誤）:

@timer
def test2():
  try:
    for _ in xrange(1000000):
      do_something()
  except Exception:
    do_something()
  else:
    pass
  finally:
    pass

測試組3（try放耗時操作中，try每一次操作，不拋出錯誤）:

@timer
def test3():
  for _ in xrange(1000000):
    try:
      do_something()
    except Exception:
      do_something()
    else:
      pass
    finally:
      pass

測試組4（try放耗時操作中，try每一次操作并進行異常處理(捕捉拋出的特定異常)）:

@timer
def test4():
  zero = 0
  for _ in xrange(1000000):
    try:
      if zero == 0:
        raise ZeroDivisionError
    except ZeroDivisionError:
      do_something()
    else:
      pass
    finally:
      pass

測試組5（try放耗時操作中，try每一次操作并進行異常處理(捕捉所有異常 try…except BaseException)）:

@timer
def test5():
  zero = 0
  for _ in xrange(1000000):
    try:
      if zero == 0:
        raise ZeroDivisionError
    except BaseException:
      do_something()
    else:
      pass
    finally:
      pass

測試組6（try放耗時操作中，try每一次操作并進行異常處理(捕捉所有異常 不帶任何異常類型)）:

@timer
def test6():
  zero = 0
  for _ in xrange(1000000):
    try:
      if zero == 0:
        raise ZeroDivisionError
    except:
      do_something()
    else:
      pass
    finally:
      pass

測試組7（耗時操作放在except中）:

@timer
def test7():
  zero = 0
  try:
    if zero == 0:
      raise ZeroDivisionError
  except ZeroDivisionError:
    for _ in xrange(1000000):
      do_something()
  else:
    pass
  finally:
    pass

測試組8（防御式編碼）:

@timer
def test8():
  zero = 0
  for _ in xrange(1000000):
    if zero == 0:
      do_something()

執(zhí)行結果

對比結論

• 通過對比1和2，可以得知直接執(zhí)行耗時操作和耗時操作放在try中執(zhí)行并無異常觸發(fā)時性能消耗幾乎是一樣的。
• 通過對比2和7，可以得知使用異常的使用無論是把代碼放在 try 中執(zhí)行還是在 except 中執(zhí)行性能消耗幾乎是一樣的。
• 通過對比2和3，可以得知當不拋出錯誤時，把try放耗時操作中比耗時操作放在try中性能消耗要略大。
• 通過對比3和4，可以得知當使用try時無異常拋出跟使用try時拋出異常性能消耗幾乎相差好幾倍。
• 通過對比4和5，可以得知try放耗時操作中時，try每一次操作并進行異常處理(捕捉拋出的特定異常)跟try每一次操作并進行異常處理(捕捉所有異常 try…except BaseException)性能消耗幾乎是一樣的。
• 通過對比4和8，可以得知使用防御性方式編碼比捕捉異常方式性能消耗幾乎相差好幾倍。
• 通過對比5和6，可以得知捕捉所有異常（try…except）方式比捕捉所有異常(try…except BaseException)方式要略快。

總結

1. 由以上對比結論，可以總結為：
2. 無論是把代碼放在 try 中執(zhí)行還是在 except 中執(zhí)行性能消耗幾乎是一樣的。
3. 直接執(zhí)行代碼與放在try中執(zhí)行且不拋出異常時性能消耗幾乎是一樣的，當然理論上try會消耗一點性能，可以忽略不計。
4. 雖然try…except的方式比try…except BaseException和捕捉拋出的特定異常的方式要略快，但扔不建議采取這種方式，因為前者很容易隱藏真正的bug，從而帶來嚴重后果。
5. 通常要采取捕捉拋出的特定異常而不是捕捉所有異常，雖然二者性能消耗幾乎一樣。
6. 防御性方式編碼比捕捉異常方式性能消耗幾乎相差好幾倍，應盡量采取這種編程方式，提升性能并且更靠譜。

以上就是本文關于Python異常對代碼運行性能的影響實例解析的全部內(nèi)容，希望對大家有所幫助。感興趣的朋友可以繼續(xù)參閱本站其他相關專題，如有不足之處，歡迎留言指出。感謝朋友們對本站的支持！

最新評論