java--何时处理Exception（哪一个层级），包装的基础类处理任务尽可能简洁，写入日志，检查null等运行时异常

1. 运行时异常和受检异常

2. 提前预防运行时异常。最常发生的是NPE，而检查NPE是程序员的基本职责。其他的，如除0等运行时异常的检查，需要程序员仔细检查，每个函数都得检查（除非可以确定不会有空指针等情况），哪怕if()语句数量增加。无法通过预检查的异常除外，如在解析一个外部传来的字符串形式数字时，通过catch NumberFormatException来实现。

null：1）如果是外部获取，则有必要检查null，也有必要进行有效性检查（validationCheck）；2）如果是内部的或者逻辑上保证正确的，可以不查null。

3. 处理受检异常。如从数据库取数据，http链接等获取外部数据，必须进行受检异常处理，因为这是即时进行正常操作也可能出现异常的情况。

比较赞同的一段https://www.zhihu.com/question/35085136

所有的运行时异常都是可以在发生之前检测到并且避免的，这意味着一段代码如果写得好，将不会有抛出运行时异常的可能。因此，运行时异常被抛出时，程序员应该检查代码中的bug，而不是catch它。

从语言本身的角度讲，程序不该去catch这类异常，虽然能够从诸如RuntimeException这样的异常中catch并恢复，但是并不鼓励终端程序员这么做，因为完全没要必要。因为这类错误本身就是bug，应该被修复，出现此类错误时程序就应该立即停止执行。

我想，之所以区分出受检异常和非受检异常，是因为受检异常的发生不受自身代码控制，往往是在和外部连接的时候发生，也就是自身代码逻辑正确并不能阻止错误情况的发生；处理受检异常是在编译时检查，函数会抛出受检异常的原因是它认为自己无法处理这个异常，如果认为自己可以处理，则处理不再抛出。非受检异常大部分是由于程序逻辑欠缺导致的，抛出异常是为了定位错误发生的地点和原因；如果逻辑上考虑或检查的比较完备，则理论上不会发生非受检异常。

但是有的时候确实会担心、也会发生考虑不周全的时候，（因为出现的次数少，感觉也不适合直接中断运行），这时候，我觉得可以在比较外层的地方try catch runtimeException，记录错误，并找出原因修复，同时主程序继续运行。

       try {
            Class12 class12 = new Class12(tradingDB);
            class12.completeSummaryItems(summaryItems);

            Report report = new Report(tradingDB, calendar.getTime());
            report.addSummaryItem(summaryItems);

            report.calculate();
            report.writeDB();
        } catch (RuntimeException e) {
            LOGGER.error("internal error", e);
        }

这个记录的目的是记录log，并且通过后台日志监控程序通知开发人员查看此bug，修复程序。如果直接崩溃，不一定会写入日志。

4. DB或连接类等基础类无需关心连接失效问题，由上层类或连接池关心。每一个模块或者类，都只需要关注自身应当具备的功能，超出的部分不应过多关心。久而久之，慢慢就成了面向对象咯（？）。

5. exception，交给调用者处理，如果认为所在层次应该处理此exception时，自己处理。

比如数据库连接类：

public class DB {

　　 public List<List<String>> select(String query) {
        List<List<String>> res = new ArrayList<List<String>>();
        Statement st = null;
        ResultSet rs = null;
        try {
            st = dbConn.createStatement();
            rs = st.executeQuery(query);
            while (rs.next()) {
                List<String> row = new ArrayList<String>();
                for (int i = 1; i <= rs.getMetaData().getColumnCount(); i++) {
                    row.add(rs.getString(i));
                }
                res.add(row);
            }
        } catch (SQLException e) {
            LOGGER.error("error while executing sql<" + query + ">.", e);
            res = null;
        } finally {
            if (st != null) {
                try {
                    st.close();
                } catch (SQLException e) {
                    LOGGER.warn("close db statement failed.", e);
                }
            }
        }
        return res;
    }
}

这个select函数自身处理了SQLException受检异常，是因为从程序整体上看，对于SQLException的处理为：写日志文件，并返回空集合。在select函数里是可以完成这一操作，且返回结果和抛出异常倒上一层的处理结果一致，那么就可以在这一层处理；另一方面在这一层处理，也可以避免抛出异常后，每次调用都要处理一下异常，减少修改量。

如果是在制作一个工具包，那么最好是抛出异常，由调用者处理（一般调用者也会像DB这个类一样做一个包装）。这里不是对外的工具包，所以不需要。

6. 准守api的约定很重要，包括自己编写api时，对约定的重视程度决定着api/代码的质量。如果约定不会返回null值，那么api就一定不要返回空值。如果返回null值是合理的，则说明返回的发生条件。

7. 如果在自身层次处理了exception，则返回值最好是可以让程序继续运行，但不会进一步处理数据的数值。比如：返回一个空的List，那么调用者接收到返回值后，不会中断程序，又由于返回的list个数为0，也不会往下一步运行。这一实现也需要程序整体上都是这么一个风格，即需要每一步都有对于空对象的处理。这样当exception发生后，调用者对数据的处理一视同仁，但是最后的结果能反映有错误发生。

8. 日志写入文件，信息要尽可能详细。不能太少，也不要重复。如果一个连接断开会导致不停的写日志，最好优化一下。

9. 日志格式需要统一，关键信息需写入日志文件。统一处理：日志监控程序，定时（半分钟）扫描一次日志，从上次读取的地方开始，发现有error字符串，则发邮件告警。

sub analyze {
  my ($fh, $pos, $words) = @_;
  my $lines = [];
  seek($fh, , ); # move to the end of file
  my $end = tell($fh);
  if ($end <= $pos) {
    ## size of file is smaller than recorded value, the file must be modified
    return ($lines, (($end<) ?  : $end));
  }
  my $hasOneLine = ;
  seek($fh, $pos, ); ## make file pointer points to the recorded position
  my $cur = $end;
  for(; my $line = readline($fh); $cur = tell($fh)) {
    if($line =~ /$words/) {
      $line =~ s/\n//;
      if (!$hasOneLine) {
        # only store one line
        push(@$lines, $line);
        $hasOneLine = ;
      }
    }
  }
  return ($lines, $cur);
}

对于通过crontab启动的程序，如果想要监控程序有没有正常启动，可以查看/var/log/cron日志，如果有新的启动记录，则正常。如果没有，那么可以到/var/spool/mail/root文件中查看原因（前提是crontab没有屏蔽错误信息）。这里的屏蔽错误信息指的是：

* * * * * $HOME/Workspace/monitor/admin/monitorReboot.pl >&  | cat >> $HOME/Workspace/monitor/admin/log

其中2>&1表示把错误信息流重定向，重定向则表示屏蔽了错误信息。如果把2>&1去掉：

* * * * * $HOME/Workspace/monitor/admin/monitorReboot.pl   | cat >> $HOME/Workspace/monitor/admin/log

则错误信息会记录在/var/spool/mail/root文件中。不过一般情况下，不用监控crontab，只要开始的时候人工确认一下执行了就行，linux系统还是值得信赖的。

ps. 对文件的操作需要注意inode的变化。有些软件如vim，在修改文件后会产生一个新的inode，需要特殊设置一下。

10. 日志的监控，如果需要高可靠性和实时性，可以考虑socket或 消息队列 等进程间通信方式。

11. 面向对象是一种思想，学习一种思想是一个长的过程。