<p>异常处理在任何一门编程语言里都是值得关注的一个话题，良好的异常处理可以让你的程序更加健壮，清晰的错误信息更能帮助你快速修复问题。在Python中，和不部分高级语言一样，使用了try/except/finally语句块来处理异常，如果你有其他编程语言的经验，实践起来并不难。</p>    <h2>异常处理语句 try…excpet…finally</h2>    <h3>实例代码</h3>    <pre>  <code class="language-python">defdiv(a, b):      try:          print(a / b)      exceptZeroDivisionError:          print("Error: b should not be 0 !!")      exceptExceptionas e:          print("Unexpected Error: {}".format(e))      else:          print('Run into else only when everything goes well')      finally:          print('Always run into finally block.')     # tests  div(2, 0)  div(2, 'bad type')  div(1, 2)     # Mutiple exception in one line  try:      print(a / b)  except (ZeroDivisionError, TypeError) as e:      print(e)     # Except block is optional when there is finally  try:      open(database)  finally:      close(database)     # catch all errors and log it  try:      do_work()  except:          # get detail from logging module      logging.exception('Exception caught!')            # get detail from sys.exc_info() method      error_type, error_value, trace_back = sys.exc_info()      print(error_value)      raise  </code></pre>    <h3>总结如下</h3>    <ol>     <li>except 语句不是必须的， finally 语句也不是必须的，但是二者必须要有一个，否则就没有 try 的意义了。</li>     <li>except 语句可以有多个，Python会按 except 语句的顺序依次匹配你指定的异常，如果异常已经处理就不会再进入后面的 except 语句。</li>     <li>except 语句可以以元组形式同时指定多个异常，参见实例代码。</li>     <li>except 语句后面如果不指定异常类型，则默认捕获所有异常，你可以通过logging或者sys模块获取当前异常。</li>     <li>如果要捕获异常后要重复抛出，请使用 raise ，后面不要带任何参数或信息。</li>     <li>不建议捕获并抛出同一个异常，请考虑重构你的代码。</li>     <li>不建议在不清楚逻辑的情况下捕获所有异常，有可能你隐藏了很严重的问题。</li>     <li>尽量使用内置的异常处理语句来 替换try/except语句，比如 with 语句， getattr() 方法。</li>    </ol>    <h2>抛出异常 raise</h2>    <p>如果你需要自主抛出异常一个异常，可以使用 raise 关键字，等同于C#和Java中的 throw 语句，其语法规则如下。</p>    <pre>  <code class="language-python">raiseNameError("bad name!")  </code></pre>    <p>raise 关键字后面需要指定你抛出的异常类型，一般来说抛出的异常越详细越好，Python在 exceptions 模块内建了很多的异常类型，通过使用 dir() 函数来查看 exceptions 中的异常类型，如下：</p>    <pre>  <code class="language-python">importexceptions     # ['ArithmeticError', 'AssertionError'.....]  printdir(exceptions)  </code></pre>    <p>当然你也可以查阅Python的文档库进行更详细的了解。</p>    <ul>     <li><a href="/misc/goto?guid=4959730312121716911" rel="nofollow,noindex">https://docs.python.org/2.7/l…</a></li>    </ul>    <h2>自定义异常类型</h2>    <p>Python中也可以自定义自己的特殊类型的异常，只需要要从 Exception 类继承(直接或间接)即可：</p>    <pre>  <code class="language-python">class SomeCustomException(Exception):      pass  </code></pre>    <p>一般你在自定义异常类型时，需要考虑的问题应该是这个异常所应用的场景。如果内置异常已经包括了你需要的异常，建议考虑使用内置 的异常类型。比如你希望在函数参数错误时抛出一个异常，你可能并不需要定义一个 InvalidArgumentError ，使用内置的 ValueError 即可。</p>    <h2>经验案例</h2>    <h3>传递异常 re-raise Exception</h3>    <p>捕捉到了异常，但是又想重新引发它（传递异常），使用不带参数的 raise 语句即可：</p>    <pre>  <code class="language-python">deff1():      print(1/0)     deff2():      try:          f1()      exceptExceptionas e:          raise  # don't raise e !!!     f2()  </code></pre>    <p>在Python2中，为了保持异常的完整信息，那么你捕获后再次抛出时千万不能在 raise 后面加上异常对象，否则你的 <strong> trace 信息就会从此处截断 </strong> 。以上是最简单的重新抛出异常的做法。</p>    <p>还有一些技巧可以考虑，比如抛出异常前对异常的信息进行更新。</p>    <pre>  <code class="language-python">deff2():      try:          f1()      exceptExceptionas e:          e.args += ('more info',)          raise  </code></pre>    <p>如果你有兴趣了解更多，建议阅读这篇博客。</p>    <ul>     <li><a href="/misc/goto?guid=4959730312221064442" rel="nofollow,noindex">http://www.ianbicking.org/blo…</a></li>    </ul>    <p>Python3对重复传递异常有所改进，你可以自己尝试一下，不过建议还是同上。</p>    <h3>Exception 和 BaseException</h3>    <p>当我们要捕获一个通用异常时，应该用 Exception 还是 BaseException ？</p>    <pre>  <code class="language-python">BaseException   +-- SystemExit   +-- KeyboardInterrupt   +-- GeneratorExit   +-- Exception        +-- StopIteration...        +-- StandardError...        +-- Warning...  </code></pre>    <p>从 Exception 的层级结构来看， BaseException 是最基础的异常类， Exception 继承了它。 BaseException 除了包含所有的 Exception 外还包含了 SystemExit ， KeyboardInterrupt 和 GeneratorExit 三个异常。</p>    <p>有此看来你的程序在捕获所有异常时更应该使用 Exception 而不是 BaseException ，因为另外三个异常属于更高级别的异常，合理的做法应该是交给Python的解释器处理。</p>    <h3>except Exception as e和 except Exception, e</h3>    <p>代码示例如下：</p>    <pre>  <code class="language-python">try:      do_something()  exceptNameErroras e:  # should      pass  exceptKeyError, e:  # should not      pass  </code></pre>    <p>在Python2的时代，你可以使用以上两种写法中的任意一种。在Python3中你只能使用第一种写法，第二种写法被废弃掉了。第一个种写法可读性更好，而且为了程序的兼容性和后期移植的成本，请你也抛弃第二种写法。</p>    <h3>raise “Exception string”</h3>    <p>把字符串当成异常抛出看上去是一个非常简洁的办法，但其实是一个非常不好的习惯。</p>    <pre>  <code class="language-python">if is_work_done():      pass  else:      raise "Work is not done!" # not cool  </code></pre>    <p>上面的语句如果抛出异常，那么会是这样的：</p>    <pre>  <code class="language-python">Traceback (mostrecentcalllast):    File "/demo/exception_hanlding.py", line 48, in       raise "Work is not done!"  TypeError: exceptionsmustbeold-styleclassesor derivedfromBaseException, not str  </code></pre>    <p>这在Python2.4以前是可以接受的做法，但是没有指定异常类型有可能会让下游没办法正确捕获并处理这个异常，从而导致你的程序挂掉。简单说，这种写法是是封建时代的陋习，应该扔了。</p>    <h3>使用内置的语法范式代替try/except</h3>    <p>Python 本身提供了很多的语法范式简化了异常的处理，比如 for 语句就处理的 StopIteration 异常，让你很流畅地写出一个循环。</p>    <p>with 语句在打开文件后会自动调用 finally 中的关闭文件操作。我们在写Python代码时应该尽量避免在遇到这种情况时还使用try/except/finally的思维来处理。</p>    <pre>  <code class="language-python"># should not  try:      f = open(a_file)      do_something(f)  finally:      f.close()     # should  withopen(a_file) as f:      do_something(f)  </code></pre>    <p>再比如，当我们需要访问一个不确定的属性时，有可能你会写出这样的代码：</p>    <pre>  <code class="language-python">try:      test = Test()      name = test.name  # not sure if we can get its name  exceptAttributeError:      name = 'default'  </code></pre>    <p>其实你可以使用更简单的 getattr() 来达到你的目的。</p>    <pre>  <code class="language-python">name = getattr(test, 'name', 'default')  </code></pre>    <h2>最佳实践</h2>    <p>最佳实践不限于编程语言，只是一些规则和填坑后的收获。</p>    <ol>     <li>只处理你知道的异常，避免捕获所有 异常然后吞掉它们。</li>     <li>抛出的异常应该说明原因，有时候你知道异常类型也猜不出所以然的。</li>     <li>避免在catch语句块中干一些没意义的事情。</li>     <li>不要使用异常来控制流程，那样你的程序会无比难懂和难维护。</li>     <li>如果有需要，切记使用finally来释放资源。</li>     <li>如果有需要，请不要忘记在处理异常后做清理工作或者回滚操作。</li>    </ol>    <p> </p>    <p>来自：http://python.jobbole.com/87087/</p>    <p> </p>