异常处理

https://www.cnblogs.com/tjudzj/p/7053980.html

1.检查型异常（Checked Exception）

　　个人理解：所谓检查（Checked）是指编译器要检查这类异常，检查的目的一方面是因为该类异常的发生难以避免，另一方面就是让开发者去解决掉这类异常，所以称为必须处理（try ...catch）的异常。如果不处理这类异常，集成开发环境中的编译器一般会给出错误提示。

　　例如：一个读取文件的方法代码逻辑没有错误，但程序运行时可能会因为文件找不到而抛出FileNotFoundException，如果不处理这些异常，程序将来肯定会出错。所以编译器会提示你要去捕获并处理这种可能发生的异常，不处理就不能通过编译。

2.非检查型异常（Unchecked Exception）

　　个人理解：所谓非检查（Unchecked）是指编译器不会检查这类异常，不检查的则开发者在代码的编辑编译阶段就不是必须处理，这类异常一般可以避免，因此无需处理（try ...catch）。如果不处理这类异常，集成开发环境中的编译器也不会给出错误提示。

　　例如：你的程序逻辑本身有问题，比如数组越界、访问null对象，这种错误你自己是可以避免的。编译器不会强制你检查这种异常。

https://blog.csdn.net/zmx729618/article/details/80917347

看hadoop源码时，想想自己最近在做的那个系统，发现很多异常处理的方式不对，还是按照传统的异常处理方式（即：采用返回值来标识程序出现的异常情况）。而hadoop中很多方法的声明是有异常抛出的，而我的系统中的很多方法的声明都没有抛出异常。只是判断了异常情况，并输出了错误提示，但是并没有抛出异常。

org.apache.hadoop.hdfs.protocol包下的Block类的readFields()方法：

public void readFields(DataInput in) throws IOException {
    this.blockId = in.readLong();
    this.numBytes = in.readLong();
    this.generationStamp = in.readLong();
    if (numBytes < 0) {
      throw new IOException("Unexpected block size: " + numBytes);//抛出异常，要是的话就不会抛出，而只是System.out.println错误提示，
    }

 1.如果方法声明名里面有throws异常，那么方法体里面可以不抛出异常。因为可以在方法声明中包含异常说明，但实际上却不抛出！这样做的好处是，为异常先占个位置，以后就可以抛出这种异常而不用修改修改已有的代码。在定义抽象基类和接口时这种能力很重要，这样派生类或接口实现类就能够抛出这些预先声明的异常。

2.为什么有的方法声明里面没有throws，但方法体里面却抛出了异常？从RuntimeException继承的异常，可以在没有异常说明throws的情况下被抛出！对于Runtime异常（也称为非检查的异常unchecked exception），编译器不需要异常说明。只能在代码中忽略RuntimeException（及其子类）类型的异常，其他类型的异常的处理都是由编译器强制实施的。究其原因，RuntimeException代表的是编程错误。

3.运行时异常会被Java虚拟机自动抛出！

《有效处理Java异常三原则》http://www.importnew.com/1701.html

1. 异常处理基础

     1.1 System.out.println是高代价的。调用System.out.println会降低系统吞吐量。

 

     1.2 在生产环境中别用异常的printStackTrace()方法。printStackTrace默认会把调用的堆栈打印到控制台上，在生产环境中访问控制台是不现实的。

 

2. 异常处理基本原则

     2.1 如果你不能处理异常，不要捕获该异常。

 

     2.2 如果要捕获，应在离异常源近的地方捕获它。

 

     2.3 不要吞没你捕获的异常。

     *（就是捕获的异常，但是什么也不做）

 

     2.4 除非你要重新抛出异常，否则把它log起来。

 

     2.5 当一个异常被重新包装，然后重新抛出的时候，不要打印statck trace。

 

     2.6 用自定义的异常类，不要每次需要抛出异常的时候都抛出java.lang.Exception。方法的调用者可以通过throws知道有哪些异常需要处理--所以它是自我描述的。

 

     2.7 如果你编写业务逻辑，对于终端用户无法修复的错误，系统应该抛出非检查的异常（unchecked exception）；如果你编写一个第三方的包给其他的开发人员用，对于不可修复的错误要用需要检查的异常（checked exception）。

 

    2.8 绝对不要因为写throws语句会让你用起来不舒服，而不声明需要检查的异常。

 

    2.9 应用级别的错误或不可修复的系统异常用非检查的异常（unchecked exception）抛出。

    *（注意是错误，意味着不可修复，比如配置文件错误）

 

    2.10 根据异常的粒度组织你的方法

 

 

 

 

 http://f.dataguru.cn/thread-616021-1-1.html

上周公司组织Python方面的代码review，其中提到一个问题就是没有一个统一的异常日志分析机制，都乱七八糟的，然后回头看了一下自己项目的异常处理方面，感觉对Python异常体系以及相关的工具模块了解不是很深。有必要整理一下关于Python异常处理方面的一些基础知识。1. Python中的异常栈跟踪

之前在做Java的时候，异常对象默认就包含stacktrace相关的信息，通过异常对象的相关方法printStackTrace()和getStackTrace()等方法就可以取到异常栈信息，能打印到log辅助调试或者做一些别的事情。但是到了Python，在2.x中，异常对象可以是任何对象，经常看到很多代码是直接raise一个字符串出来，因此就不能像Java那样方便的获取异常栈了，因为异常对象和异常栈是分开的。而多数Python语言的书籍上重点在于描述Python中如何构造异常对象和raise try except finally这些的使用，对调试程序起关键作用的stacktrace往往基本上不怎么涉及。

python中用于处理异常栈的模块是traceback模块，它提供了print_exception、format_exception等输出异常栈等常用的工具函数。

def func(a, b):        return a / bif __name__ == '__main__':        import sys        import traceback        try:                func(1, 0)        except Exception as e:                print "print exc"                traceback.print_exc(file=sys.stdout)

输出结果：

print excTraceback (most recent call last):  File "./teststacktrace.py", line 7, in <module>    func(1, 0)  File "./teststacktrace.py", line 2, in func    return a / b

其实traceback.print_exc()函数只是traceback.print_exception()函数的一个简写形式，而它们获取异常相关的数据都是通过sys.exc_info()函数得到的。

def func(a, b):        return a / bif __name__ == '__main__':        import sys        import traceback        try:                func(1, 0)        except Exception as e:                print "print_exception()"                exc_type, exc_value, exc_tb = sys.exc_info()                print 'the exc type is:', exc_type                print 'the exc value is:', exc_value                print 'the exc tb is:', exc_tb                traceback.print_exception(exc_type, exc_value, exc_tb)

输出结果：

print_exception()the exc type is: <type 'exceptions.ZeroDivisionError'>the exc value is: integer division or modulo by zerothe exc tb is: <traceback object at 0x104e7d4d0>Traceback (most recent call last):  File "./teststacktrace.py", line 7, in <module>    func(1, 0)  File "./teststacktrace.py", line 2, in func    return a / bZeroDivisionError: integer division or modulo by zero

sys.exc_info()返回的值是一个元组，其中第一个元素，exc_type是异常的对象类型，exc_value是异常的值，exc_tb是一个traceback对象，对象中包含出错的行数、位置等数据。然后通过print_exception函数对这些异常数据进行整理输出。

traceback模块提供了extract_tb函数来更加详细的解释traceback对象所包含的数据：

def func(a, b):        return a / bif __name__ == '__main__':        import sys        import traceback        try:                func(1, 0)        except:                _, _, exc_tb = sys.exc_info()                for filename, linenum, funcname, source in traceback.extract_tb(exc_tb):                        print "%-23s:%s '%s' in %s()" % (filename, linenum, source, funcname)

输出结果：

samchimac:tracebacktest samchi$ python ./teststacktrace.py ./teststacktrace.py    :7 'func(1, 0)' in <module>()./teststacktrace.py    :2 'return a / b' in func()

2. 使用cgitb来简化异常调试

如果平时开发喜欢基于log的方式来调试，那么可能经常去做这样的事情，在log里面发现异常之后，因为信息不足，那么会再去额外加一些debug log来把相关变量的值输出。调试完毕之后再把这些debug log去掉。其实没必要这么麻烦，Python库中提供了cgitb模块来帮助做这些事情，它能够输出异常上下文所有相关变量的信息，不必每次自己再去手动加debug log。

cgitb的使用简单的不能想象：

def func(a, b):        return a / bif __name__ == '__main__':        import cgitb        cgitb.enable(format='text')        import sys        import traceback        func(1, 0)

运行之后就会得到详细的数据:

A problem occurred in a Python script.  Here is the sequence offunction calls leading up to the error, in the order they occurred. /Users/samchi/Documents/workspace/tracebacktest/teststacktrace.py in <module>()    4   import cgitb    5   cgitb.enable(format='text')    6   import sys    7   import traceback    8   func(1, 0)func = <function func> /Users/samchi/Documents/workspace/tracebacktest/teststacktrace.py in func(a=1, b=0)    2   return a / b    3 if __name__ == '__main__':    4   import cgitb    5   cgitb.enable(format='text')    6   import sysa = 1b = 0

完全不必再去log.debug("a=%d" % a)了，个人感觉cgitb在线上环境不适合使用，适合在开发的过程中进行调试，非常的方便。

也许你会问，cgitb为什么会这么屌？能获取这么详细的出错信息？其实它的工作原理同它的使用方式一样的简单，它只是覆盖了默认的sys.excepthook函数，sys.excepthook是一个默认的全局异常拦截器，可以尝试去自行对它修改：

def func(a, b):        return a / bdef my_exception_handler(exc_type, exc_value, exc_tb):        print "i caught the exception:", exc_type        while exc_tb:                print "the line no:", exc_tb.tb_lineno                print "the frame locals:", exc_tb.tb_frame.f_locals                exc_tb = exc_tb.tb_nextif __name__ == '__main__':        import sys        sys.excepthook = my_exception_handler        import traceback        func(1, 0)

输出结果：

i caught the exception: <type 'exceptions.ZeroDivisionError'>the line no: 14the frame locals: {'my_exception_handler': <function my_exception_handler at 0x100e04aa0>, '__builtins__': <module '__builtin__' (built-in)>, '__file__': './teststacktrace.py', 'traceback': <module 'traceback' from '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/traceback.pyc'>, '__package__': None, 'sys': <module 'sys' (built-in)>, 'func': <function func at 0x100e04320>, '__name__': '__main__', '__doc__': None}the line no: 2the frame locals: {'a': 1, 'b': 0}

看到没有？没有什么神奇的东西，只是从stack frame对象中获取的相关变量的值。frame对象中还有很多神奇的属性，就不一一探索了。
3. 使用logging模块来记录异常

在使用Java的时候，用log4j记录异常很简单，只要把Exception对象传递给log.error方法就可以了，但是在Python中就不行了，如果直接传递异常对象给log.error，那么只会在log里面出现一行异常对象的值。

在Python中正确的记录Log方式应该是这样的：

logging.exception(ex)
logging.error(ex, exc_info=1) # 指名输出栈踪迹, logging.exception的内部也是包了一层此做法
logging.critical(ex, exc_info=1) # 更加严重的错误级别

 

描述了几种比较全面的异常处理方式

http://www.cnblogs.com/fat39/p/9186715.html