心情有点纠结，怎么说呢，倒不是由于其它学习上的事情，反而是由于生活上狗血的剧情逼着人偏离，渐行渐远，人跟人之间有误会也是正常的，可能是由于交流不够，彼此不够了解吧，希望能尽快度过这一段纠结的日子，简单的生活，慢慢的品味，细细的思考。
近期一段时间，由于须要，借阅了一本Python Cookbook，发现这本书在非常多方面介绍的都非常不错，比方一些系统管理，web，分布式编程，数据持久化等等这些方面。可是却没有发现具体的关于错误和异常的一些介绍，本着作死的态度打算好好研究一下。
首先，照例，我们先来看一段演示样例程序：
首先，我们这里出现的不是异常，而是另一个我们经常遇到的非致命警告warning,主要是向用户提供非致命警告，指出执行一个程序时遇到的问题，通常来说，我们最好是在程序中不要出现这些东西，否则我们就须要从新审视我们的代码了。
一．Warning---非致命警告
警告使用的是内置异常类Warning的子类进行分类，通常须要依据过滤器（filter）设置来处理。过滤器一般包括，Action，Message,Category,Module和Line number.也能够这么理解，这里面的消息Message部分一般是一个匹配警告文本的正則表達式，类别Catregory是一个异常类的名称，模块Module包括一个正則表達式，要与生成警告的模块名匹配，行号Line Number能够改变在一个警告出现时的处理
每当生成一个警告时，都须要将其与注冊过的过滤器比較，第一个匹配的过滤器将控制这个警告採取的动作，否则採取默认的动作，事实上本质流程上会发现与Exception异常处理如出一辙，看一下常见的过滤器动作：
动作 | 含义 |
error | 将警告提升为异常 |
ignore | 忽略警告 |
always | 总是抛出警告 |
default | 从各个位置第一次生成警告时输出警告 |
module | 从各个模块第一次生成警告时输出警告 |
once | 第一次生成警告时输出警告 |
1.模式过滤
简单的过滤如演示样例中的show_warning_by_filtering(),可是想要通过编程依照更复杂的规则进行过滤就须要使用filterwarning()，比方，须要依据消息文本的内容过滤，能够提供一个正則表達式作为參事。如演示样例中的show_pattern_filter(),模式包括‘do not’具体的消息中使用了‘Do not’，正則表達式被编译为不区分大写和小写的匹配，故这个模式会匹配。当然，相同的匹配也适用于源模块名，能够将模块名作为模式传至module參数，抑制来自copy模块的全部消息，例如以下所看到的：
当然，我们也能够限定仅仅抑制某一行上的警告，例如以下所看到的：
2.反复警告
默认情况，大多数警告仅仅会在给定位置第一次出现时才会输出，可是假如我们的程序里面出现了警告，我们改完之后发现后面另一个相同的警告，这个时候就会有不知道什么时候是个头的错觉，最直接的办法就是在每个出现警告的地方我们就给他来一个警告，最起码我们能做到心里有数，例如以下所看到的：
3.警告定向输出
普通情况下，警告都会输出到sys.stderr，我们能够通过替换warning模块中的showwarning()函数来改变这个行为，例如以下所看到的：
略微注意下：这里的UserWarning是一种警告类型，来自用户代码的警告的基类，另一些其它的类型，比方:
Warning-----全部警告的基类
DeprecationWarning----用于不再维护的特性
PendingDeprecationWarning----用于非常快会废弃的特性
SyntaxWarning---用于有问题的语法
RuntimeWarning----用于执行时可能导致问题的事件
FutureWarning----关于将来语言或者库中可能的改变的有关警告
ImportWarning 关于导入模块时出现的问题的警告
UnicodeWarning---关于Unicode文本中的问题的警告
二．Exception----内置异常类
1.异常基类
BaseException：
全部异常的基类，实现了基类的逻辑，能够使用str()由传入构造函数的參数创建异常的一个串表示
Exception:
有些异常不会导致退出正在执行的应用，Exception是这些全部异常的基类，用户定义的全部异常应当都是用其作为基类
StandardError:
标准库中使用的内置异常的基类
ArithmeticError：
与数学相关的错误的基类
LookupError：
无法找到某个对象时产生的错误的基类
EnvironmentError：
来自Python外部（操作系统，文件系统等）错误的基类
2.常见的异常
这里，我们仅仅以AssertionError为例，AssertionError是由一个失败的assert语句产生，断言在库中一般非经常见，通经常使用来对传入參数的限制，通过相似failif()等方法，AssertionError还能够用在unittest模块创建的自己主动測试中，执行的自己主动測试套件的程序会监视AssertionError异常，作为測试失败的一个特殊提示，例如以下所看到的：
当然除此之外还有非常多异常，例如以下：
AttributeError:当一个属性引用或赋值失败时，会产生
EOFError：对于相似input或者raw_input这种内置函数，假设在遇到输入流末尾之前没有读到不论什么数据，会产生
FloatingPointError：这个错误由导致错误的浮点操作产生，前提是已经打开了浮点异常控制(fpectl),启用fpectl时，要求编译解释器提供 with-fpectl标志，可是标准文档中不提倡使用fpectl
IOError:输入或输出失败时会产生，如磁盘满了，输入文件不存在等等
ImportError:无法导入一个模块或者模块中的一个成员时会产生该异常
IndexError:假设一个序列引用越界，就会产生IndexError
KeyError:假设没有找到一个值作为字典的键，会产生异常
KeyBoardInterrupt:用户按下Ctrl-C(或者Delete)终止一个正在执行的程序时，会产生
MemoryError：假设一个程序用尽了全部内存，并且能够恢复，会产生
NameError:假设代码引用了一个名字，而当前作用域中不存在这个名字，会产生
NotImplementedError:用户自己定义的基类可能产生NotImplementedError，来指示一个方法或者行为须要子类定义
OSError:一个操作系统级别函数返回错误时会产生OSError
OverflowError:当一个算术运算超出变量类型的界限时，会产生
RefernceError:
使用一个weakref代理訪问已经被垃圾回收的对象时，会产生
RuntimeError:假设没有其它更特定的异常可用，就要使用RuntimeError异常
SyntaxError:当解释器无法解释程序的时候，会产生
SystemError:假设发生错误在解释其本身，会产生
SystemExit:当调用sys.exit()会产生
TypeError:结合对象或者在对象上调用函数时，假设对象类型不对会产生
UnboundLocalError:一种NameError,特别针对局部变量名
UnicodeError:ValueError的一个子类，出现Unicode问题时产生
ValueError:假设一个函数接收到的值类型正确，可是值不合法
ZeroDivisionError:0做分母时抛出
特别提醒：关于为什么要了解异常呢，首先在程序中我们可能会经常碰到，可是最重要的是这对以后我们编敲代码，调试程序提供了有力的帮助，针对错误信息，能够马上推断出什么地方出了问题，这才是最重要的地方