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, 0, 2); # 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<0) ? 0 : $end)); } my $hasOneLine = 0; seek($fh, $pos, 0); ## 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 = 1; } } } return ($lines, $cur);
}
对于通过crontab启动的程序，如果想要监控程序有没有正常启动，可以查看/var/log/cron日志，如果有新的启动记录，则正常。如果没有，那么可以到/var/spool/mail/root文件中查看原因（前提是crontab没有屏蔽错误信息）。这里的屏蔽错误信息指的是：
* * * * * $HOME/Workspace/monitor/admin/monitorReboot.pl 2>&1 | 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. 面向对象是一种思想，学习一种思想是一个长的过程。
