Month: August 2008

因为这个字符永远也输入不了，用它作分隔符就不会跟有意义的文字混淆在一起 这是某公司的牛人说的

    它的API DOC中写着：    The top-level error handler does not print out a message if ThreadDeath is never caught.     如果你的各个线程相继死去，并且没有报错，那很有可能就是这个东西引起的    程序应该在run()方法内部捕捉这个异常，才能保证Thread不死    Tomcat容器会捕获这个错误    如果在Eclipse内执行某个程序，也会捕获这个错误

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