Chen Jian

list的iterator的next()如果为空，并不返回NULL 而是抛出NoSuchElementException

    JDK会自动帮它加上

content.substring(0, Math.min(content.length(), 20))

它们都实现了Throwable接口 catch Exception 是捕捉不到Error的 而且，JAVA还要求我们不要捕捉Error： An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch. Most such errors are abnormal conditions. The ThreadDeath error, though a "normal" condition, is also a subclass of Error because most applications should not try to catch it.

反模式的缺点：       1.职责不清晰。这点相当致命，让看代码的人非常迷惑     2.让抽象、统一的东西给某个具体、特殊的东西开了后门，形成倒置了的依赖，极其不利于需求变更

这个方法返回的数据类型是java.sql.TimeStamp，而TimeStamp是java.util.Date的子类。 所以在JAVABEAN中仍然可以将字段类型定为Date

1.仅从表面现象判断出错的地方。 一个报文从A发到B收不到，从B发给B自己却能收到，这让我以为问题在操作系统或者TCP/IP协议方面。这样判断太草率，因为运行的环境不同，可能导致程序中不同语句的执行时序也不同。我的同事QQ曾提出一个通用的排错公式：           已知：环境A + 程序A = 出错     若       环境B  + 程序A = 正常     Then           环境A存在问题     若        环境A  + 程序B = 正常     Then           程序A存在问题     道理虽然简单，但在实际运行中我们往往只是无意识地运用这个公式，而不是有意识地。无意识=启发式 + 迅速， 有意识 = 穷举 + 完备 2. 日志比较重要。对于非致命的错误，界面的输出往往只是粗略的出错原因，日志才能告诉你更多的细节，如异常发生所在的类，所在的方法等等，必要的情况下，要将日志输出的级别设为最低，否则就查不到足够的信息。 3. 日志所记录的异常可能仍不是最原始的异常，这时候就要单步调试了。将断点设在日志所记录的出错处，然后一步一步地查找出错原因

    就像C语言里的“宏”一样。如果需求变了，导致常量的值变了，只需要在定义处改一次即可。如果不遵循这个模式，在使用常量的地方直接使用它的值，那么一旦常量值有变，每个使用此值的地方都要变。    不但常量值这样，每种策略、每种规则都应该这样：只定义一次，并作为存取的唯一入口。

配置文件可以这样写： handlers=java.util.logging.ConsoleHandler .level=<font color=red> ALL</font> java.util.logging.ConsoleHandler.level = <font color=red>ALL</font> java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter jdk的logging将日志分为七个级别，详细我就不列了 要修改日志级别，需要将上面两处红色的地方都替换掉 带LOG运行的方法是： java.exe <b>-Djava.util.logging.config.file=loggingfile.properties</b>  SomeClass

把successView当作http parameter传进来，可以方便重用Controller ==========================================================            private ModelAndView toSv(HttpServletRequest request, HttpServletResponse response, Map model) { String sv = request.getParameter("sv"); return new ModelAndView(sv, model); }