python异常处理Exception
http://blog.csdn.net/pipisorry/article/details/21841883
关于异常处理有必要么的讨论
最重要的问题是你在开发过程中隐藏了bug,如果当时你没加这个Try…Catch,恐怕你早就发现这个bug了，因为程序压根就跑不下去。
[try catch 对代码运行的性能影响]
[你写的Try...Catch真的有必要么？]
异常处理
（含py2和py3的区别）
格式：
Python 3
try:
except Exception as e:
print(e)
不过lz推荐下面的格式：
import traceback try: ... except: print(traceback.format_exc()) input("hold on...")异常
1）所以异常都从 BaseException继承，并删除了StardardError 。StandardError异常：在Python 2里，StandardError是除了StopIteration，GeneratorExit，KeyboardInterrupt，SystemExit之外所有其他内置异常的基类。在Python 3里，StandardError已经被取消了；使用Exception替代。
| Notes | Python 2 | Python 3 |
|---|---|---|
x =StandardError() |
x =Exception() |
|
x =StandardError(a, b, c) |
x =Exception(a, b, c) |
2）去除了异常类的序列行为和.message属性
3）异常链，因为__context__在3.0a1版本中没有实现
- 相对于Python 2里在异常类型后添加逗号，Python 3使用了一个新的关键字，
as。 - 关键字
as也可以用在一次捕获多种类型异常的情况下。 - 如果你捕获到一个异常，但是并不在意访问异常对象本身，Python 2和Python 3的语法是一样的。
- 类似地，如果你使用一个保险方法(fallback)来捕获所有异常，Python 2和Python 3的语法是一样的。
在导入模块(或者其他大多数情况)的时候，你绝对不应该使用这种方法(指以上的fallback)。不然的话，程序可能会捕获到像KeyboardInterrupt(如果用户按Ctrl-C来中断程序)这样的异常，从而使调试变得更加困难。
触发异常-raise语句
Python 3里，抛出自定义异常的语法有细微的变化。
| Notes | Python 2 | Python 3 |
|---|---|---|
| ① | raise MyException |
unchanged |
| ② | raise MyException,'error message' |
raise MyException('error message') |
| ③ | raise MyException,'error message', a_traceback |
raise MyException('error message').with_traceback(a_traceback) |
| ④ | raise 'error message' |
unsupported |
Note:
- 抛出不带用户自定义错误信息的异常，这种最简单的形式下，语法没有改变。
- 当你想要抛出一个带用户自定义错误信息的异常时，改变就显而易见了。Python 2用一个逗号来分隔异常类和错误信息；Python 3把错误信息作为参数传递给异常类。Python 2支持新旧两种异常触发语法，而Python 3只接受带括号的的语法（不然会触发SyntaxError）
- Python 2支持一种更加复杂的语法来抛出一个带用户自定义回溯(stack trace，堆栈追踪)的异常。在Python 3里你也可以这样做，但是语法完全不同。
- 在Python 2里，你可以抛出一个不带异常类的异常，仅仅只有一个异常信息。在Python 3里，这种形式不再被支持。
2to3将会警告你它不能自动修复这种语法。
生成器的throw方法
在Python 2里，生成器有一个throw()方法。调用a_generator.throw()会在生成器被暂停的时候抛出一个异常，然后返回由生成器函数获取的下一个值。在Python 3里，这种功能仍然可用，但是语法上有一点不同。
| Notes | Python 2 | Python 3 |
|---|---|---|
| ① | a_generator.throw(MyException) |
no change |
| ② | a_generator.throw(MyException,'error message') |
a_generator.throw(MyException('error message')) |
| ③ | a_generator.throw('error message') |
unsupported |
- 最简单的形式下，生成器抛出不带用户自定义错误信息的异常。这种情况下，从Python 2到Python 3语法上没有变化 。
- 如果生成器抛出一个带用户自定义错误信息的异常，你需要将这个错误信息字符串(error string)传递给异常类来以实例化它。
- Python 2还支持抛出只有异常信息的异常。Python 3不支持这种语法，并且
2to3会显示一个警告信息，告诉你需要手动地来修复这处代码。
异常处理
Python 3中的异常处理也发生了一点变化。在Python 3中必须使用“as”关键字。
Python 2
try:
let_us_cause_a_NameError
except NameError, err:
print err, '--> our error message'
name 'let_us_cause_a_NameError' is not defined --> our error message
Python 3
try:
let_us_cause_a_NameError
except NameError as err:
print(err, '--> our error message')
name 'let_us_cause_a_NameError' is not defined --> our error message
except的一个例子：
考虑下面这个文件
import sys def bar(i):
if i == 1:
raise KeyError(1) def bad():
e = None
try:
bar(int(sys.argv[1]))
except KeyError as e:
print('key error')
print(e)
bad()
在python2中一切运作正常
$ python foo.py 1
key error
1
但是在python3中事情变得一团糟
$ python3 foo.py 1
key error
Traceback (most recent call last):
File "foo.py", line 19, in <module>
bad()
File "foo.py", line 17, in bad
print(e)
UnboundLocalError: local variable 'e' referenced before assignment
Note:问题出在，在Python3中，异常对象无法在异常块作用域外访问。（原因是在垃圾收集器运行且从内存中清理引用之前会在内存栈帧中保存一个引用周期）
解决此问题的方法之一是在异常块作用域外围护一个异常对象的引用，以使其可访问。这里是前例使用这一技术的一个版本，使得代码对Python2和Python3都友好：
import sys
def bar(i):
if i == 1:
raise KeyError(1) def good():
exception = None
try:
bar(int(sys.argv[1]))
except KeyError as e:
exception = e
print('key error')
print(exception)
除0异常ZeroDivisionError
现在除以变量A=0都不会被try-except捕捉到了，会直接在运行时警告：
RuntimeWarning: divide by zero encountered in double_scalars
只有直接除以0才会被try-except捕捉到
其它异常
x,y为字典，如果x < y的不能比较，抛出TypeError异常。2.x版本是返回伪随机布尔值的。
sys.exc_type, sys.exc_value, sys.exc_traceback
处理异常的时候，在sys模块里有三个你可以访问的变量：sys.exc_type，sys.exc_value，sys.exc_traceback。(实际上这些在Python 1的时代就有。)从Python 1.5开始，由于新出的sys.exc_info，不再推荐使用这三个变量了，这是一个包含所有以上三个元素的元组。在Python 3里，这三个变量终于不再存在了；这意味着，你必须使用sys.exc_info。
| Notes | Python 2 | Python 3 |
|---|---|---|
| sys.exc_type | sys.exc_info()[0] | |
| sys.exc_value | sys.exc_info()[1] | |
| sys.exc_traceback | sys.exc_info()[2] |
与异常处理相关的python上下文管理器ContextLib及with语句
else配合 try except错误控制使用
在异常处理语句中，当try代码块没有抛出任何的异常时，else语句块会被执行到。def my_to_int(str_param):
try:
print int(str_param)
except ValueError:
print 'cannot convert {} to a integer'.format(str_param)
else:
print 'convert {} to integer successfully'.format(str_param)
my_to_int("123")
my_to_int("me123")
convert 123 to integer successfully
cannot convert me123 to a integer
如打印日志所示，在转换成功未发生错的的时候，else语句里的逻辑会被执行，当然这个例子可能并没有什么太多的实际的用处，但大致能说明else在错误处理中的用处：简化逻辑，避免使用一些标志值就能够准确把握是否发生错误的情况来做一些实际的操作（比如在保存数据的时候如果发生错误，在else语句块中进行rollback的操作，然后紧接着还能加上finally语句完成一些清理操作。
Great Exceptations
Exceptions作为一种控制结构，在处理数据库、sockets、文件或者任何可能失败的资源时非常常用。使用标准的 try 、except 结构写数据库操作时通常是类型这样的方式。try:
# get API data
data = db.find(id='foo') # may raise exception
# manipulate the data
db.add(data)
# save it again
db.commit() # may raise exception
except Exception:
# log the failure
db.rollback()
db.close()
你能发现这里的问题吗？这里有两种可能的异常会触发相同的except模块。这意味着查找数据失败（或者为查询数据建立连接失败）会引发回退操作。这绝对不是我们想要的，因为在这个时间点上事务并没有开始。同样回退也不应该是数据库连接失败的正确响应，因此让我们将不同的情况分开处理。
首先，我们将处理查询数据。
try:
# get API data
data = db.find(id='foo') # may raise exception
except Exception:
# log the failure and bail out
log.warn("Could not retrieve FOO")
return
# manipulate the data
db.add(data)
现在数据检索拥有自己的try-except，这样当我们没有取得数据时，我们可以采取任何处理方式。没有数据我们的代码不大可能再做有用的事，因此我们将仅仅退出函数。除了退出你也可以构造一个默认对象，重新进行检索或者结束整个程序。
现在让我们将commit的代码也单独包起来，这样它也能更优雅的进行错误处理。
try:
db.commit() # may raise exception
except Exception:
log.warn("Failure committing transaction, rolling back")
db.rollback()
else:
log.info("Saved the new FOO")
finally:
db.close()
实际上，我们已经增加了两端代码。首先，让我们看看else，当没有异常发生时会执行这里的代码。在我们的例子中，这里只是将事务成功的信息写入日志，但是你可以按照需要进行更多有趣的操作。一种可能的应用是启动后台任务或者通知。
很明显finally 子句在这里的作用是保证db.close() 总是能够运行。回顾一下，我们可以看到所有和数据存储相关的代码最终都在相同的缩进级别中形成了漂亮的逻辑分组。以后需要进行代码维护时，将很直观的看出这几行代码都是用于完成 commit操作的。
皮皮blog
附录
常见的python异常类型
from:http://blog.csdn.net/pipisorry/article/details/21841883