python异常处理和断言

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...")[/code]直接调用print Exception, e得到的结果就只有一行信息，只是异常的名字和说明而已。而这样可以输出栈信息，ide中点击就可以到达错误位置，并且不会一闪而过。

异常

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

将会警告你它不能自动修复这种语法。

使用lambda匿名函数抛出异常

How can I write a lambda expression that's equivalent to:
def x():
raise Exception()
The following is not allowed:
y = lambda : raise Exception()

lambda errmsg: exec('raise(Exception(errmsg))')

[
Define a lambda expression that raises an Exception]

生成器的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中一切运作正常

1
key error 1

但是在python3中事情变得一团糟

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]

皮皮blog

与异常处理相关的

[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异常类型



[Python异常编程技巧]

皮皮blog

断言

断言是一句必须等价于布尔真的判定;此外,发生异常也意味着表达式为假.这些工作类似于 C 语言预处理器中 assert 宏,但在 Python 中它们在运行时构建(与之相对的是编译期判别).
如果你刚刚接触断言这个概念,无妨.断言可以简简单单的想象为 raise-if 语句(更准确的说是raise-if-not 语句).测试一个表达式,如果返回值是假,触发异常.

断言语句等价于这样的 Python 表达式,如果断言成功不采取任何措施(类似语句),否则触发AssertionError(断言错误)的异常.assert 的语法如下:
assert expression[, arguments]

[Python中何时使用断言]

from:http://blog.csdn.net/pipisorry/article/details/21841883