Fortify分析翻译5
上一篇 / 下一篇 2008-08-27 15:09:37 / 个人分类：Fortify
Fortify分析翻译5
http://user.qzone.qq.com/281696143/blog/1219648603 Ronger
13. Poor error handling:Overly broad catch(Structural)：
13.1.AcceptApplicationBackingBean.java
catch(Exception e){
13.2.原文：The catch block handles a broad swath of exceptions,
potentially trapping dissimilar issues or problems
that should not be dealt with at this point in the program..
翻译：这个捕捉异常的块可以处理所有的异常，潜在的陷入了在这段程序中不能处理的不同问题。
理解：如果捕捉exception,就不能让处理异常的逻辑细化，
也就是所有的异常都按照同样的逻辑处理是不行的。
13.3.EXPLANATION 解释
Multiple catch blocks can get ugly and repetitive,
but "condensing" catch blocks by catching a high-level class like Exception can obscure exceptions
that deserve special treatment or that should not be caught at this point in the program.
Catching an overly broad exception essentially defeats the purpose of Java's typed exceptions,
and can become particularly dangerous
if the program grows and begins to throw new types of exceptions.
The new exception types will not receive any attention.
多重的异常捕捉块可能会变得丑陋和重复的，
但是通过一个高层异常(比如Exception)"浓缩"的捕捉块将模糊异常，
这个异常应该有不同的处理，并且在程序的这个点上不能捕捉到。
捕捉一个过分广泛的异常将从本质上违背了Java对异常分类的目的，
如果程序修改并且增加一个新类型的异常，会变得特别的危险。
新异常类型将不会接受异常处理。
Example: The following code excerpt handles three types of exceptions in an identical fashion.
例如：下面的代码摘录以同样的方式处理三种异常。
try {
doExchange();
}
catch (IOException e) {
logger.error("doExchange failed", e);
}
catch (InvocationTargetException e) {
logger.error("doExchange failed", e);
}
catch (SQLException e) {
logger.error("doExchange failed", e);
}
At first blush, it may seem preferable to deal with these exceptions in a single catch block,
as follows:
马上，它可以使用一个单独的捕捉异常块更好的处理这些异常，像下面：
try {
doExchange();
}
catch (Exception e) {
logger.error("doExchange failed", e);
}
However, if doExchange() is modified to throw a new type of exception
that should be handled in some different kind of way,
the broad catch block will prevent the compiler from pointing out the situation.
Further, the new catch block
will now also handle exceptions derived from RuntimeException such as ClassCastException,
and NullPointerException, which is not the programmer's intent.
但是，如果doExchange()被修改抛出一个新类型的异常，这个异常需要以一些不同的方式来处理，
宽泛的捕捉块将防止编译器指向这种情况。
更多的，新的捕捉块现在也可以处理起源于RuntimeException的异常，比如ClassCastException,
和NullPointException,这些都不是程序员的意图。
13.4.RECOMMENDATIONS 建议
Do not catch broad exception classes like Exception, Throwable, Error,
or <RuntimeException> except at the very top level of the program or thread.
除非在程序或者线程的顶部，不要捕捉宽泛的异常类，类似于:Exception,Throwable,Error，
或者RuntimeException。
13.5.TIPS 提示
Fortify will not flag an overly broad catch block
if the catch block in question immediately throws a new exception.
Fortify不能标记一个过分宽泛的捕捉块，
如果这个捕捉块有问题，马上就会抛出一个新异常。
14. Poor logging practice:logger not declared static final(structual):
14.1.CreditRatingApprovalDisplayUCCImpl.java
private Logger logger = Logger.getLogger
(CustomerManagerTeamBSImpl.class);
原文：Declare loggers to be static and final..
翻译：定义日志工具必须是static和final的。
14.2.EXPLANATION 解释
It is good programming practice to share a single logger object
between all of the instances of a particular class
and to use the same logger for the duration of the program.
它是好的编程习惯，在所有特殊类的实例之间共享一个单独的日志对象，
并且在程序的持续时间中使用相同的日志组件。
Example 1: The following statement errantly declares a non-static logger.
例子1：下面的语句定义了一个non-static日志组件。
private final Logger logger =
Logger.getLogger(MyClass.class);
14.3.RECOMMENDATIONS 建议
Declare loggers to be static and final.
Example 2: The code in Example 1 could be rewritten in the following way:
定义日志组件为static和final类型。
例子2：在例子1中的代码可以以下面的方式改写：
private final static Logger logger =
Logger.getLogger(MyClass.class);
15. Code correctness:null argument to equals(Structual):
SystemCommonParameters.java
if (obj==null||obj.equals(null)) {
15.1.原文：The expression obj.equals(null) will always be false.
翻译：表达式obj.equals(null)总是为false.
15.2.EXPLANATION 解释
The program uses the equals() method to compare an object with null.
This comparison will always return false, since the object is not null.
(If the object is null, the program will throw a NullPointerException).
程序使用equals()方法来比较对象和null.
这个比较将一直返回false,当然这是这个对象不是null的情况下.
(如果这个对象是null,程序将抛出NullPointException).
15.3.RECOMMENDATIONS 建议
It is possible that the programmer intended to check to see if the object was null.
可能是，程序员打算去检查,object对象是不是null.
Instead of writing 更换下面的写法
obj.equals(null)
they intended 他们打算
obj == null
15.4.REFERENCES 引用
[1] JavaDoc for Object, Sun Microsystems,
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Object.html#equals(java.lang.Object)
对象的Java文档地址
http://user.qzone.qq.com/281696143/blog/1219648603 Ronger
13. Poor error handling:Overly broad catch(Structural)：
13.1.AcceptApplicationBackingBean.java
catch(Exception e){
13.2.原文：The catch block handles a broad swath of exceptions,
potentially trapping dissimilar issues or problems
that should not be dealt with at this point in the program..
翻译：这个捕捉异常的块可以处理所有的异常，潜在的陷入了在这段程序中不能处理的不同问题。
理解：如果捕捉exception,就不能让处理异常的逻辑细化，
也就是所有的异常都按照同样的逻辑处理是不行的。
13.3.EXPLANATION 解释
Multiple catch blocks can get ugly and repetitive,
but "condensing" catch blocks by catching a high-level class like Exception can obscure exceptions
that deserve special treatment or that should not be caught at this point in the program.
Catching an overly broad exception essentially defeats the purpose of Java's typed exceptions,
and can become particularly dangerous
if the program grows and begins to throw new types of exceptions.
The new exception types will not receive any attention.
多重的异常捕捉块可能会变得丑陋和重复的，
但是通过一个高层异常(比如Exception)"浓缩"的捕捉块将模糊异常，
这个异常应该有不同的处理，并且在程序的这个点上不能捕捉到。
捕捉一个过分广泛的异常将从本质上违背了Java对异常分类的目的，
如果程序修改并且增加一个新类型的异常，会变得特别的危险。
新异常类型将不会接受异常处理。
Example: The following code excerpt handles three types of exceptions in an identical fashion.
例如：下面的代码摘录以同样的方式处理三种异常。
try {
doExchange();
}
catch (IOException e) {
logger.error("doExchange failed", e);
}
catch (InvocationTargetException e) {
logger.error("doExchange failed", e);
}
catch (SQLException e) {
logger.error("doExchange failed", e);
}
At first blush, it may seem preferable to deal with these exceptions in a single catch block,
as follows:
马上，它可以使用一个单独的捕捉异常块更好的处理这些异常，像下面：
try {
doExchange();
}
catch (Exception e) {
logger.error("doExchange failed", e);
}
However, if doExchange() is modified to throw a new type of exception
that should be handled in some different kind of way,
the broad catch block will prevent the compiler from pointing out the situation.
Further, the new catch block
will now also handle exceptions derived from RuntimeException such as ClassCastException,
and NullPointerException, which is not the programmer's intent.
但是，如果doExchange()被修改抛出一个新类型的异常，这个异常需要以一些不同的方式来处理，
宽泛的捕捉块将防止编译器指向这种情况。
更多的，新的捕捉块现在也可以处理起源于RuntimeException的异常，比如ClassCastException,
和NullPointException,这些都不是程序员的意图。
13.4.RECOMMENDATIONS 建议
Do not catch broad exception classes like Exception, Throwable, Error,
or <RuntimeException> except at the very top level of the program or thread.
除非在程序或者线程的顶部，不要捕捉宽泛的异常类，类似于:Exception,Throwable,Error，
或者RuntimeException。
13.5.TIPS 提示
Fortify will not flag an overly broad catch block
if the catch block in question immediately throws a new exception.
Fortify不能标记一个过分宽泛的捕捉块，
如果这个捕捉块有问题，马上就会抛出一个新异常。
14. Poor logging practice:logger not declared static final(structual):
14.1.CreditRatingApprovalDisplayUCCImpl.java
private Logger logger = Logger.getLogger
(CustomerManagerTeamBSImpl.class);
原文：Declare loggers to be static and final..
翻译：定义日志工具必须是static和final的。
14.2.EXPLANATION 解释
It is good programming practice to share a single logger object
between all of the instances of a particular class
and to use the same logger for the duration of the program.
它是好的编程习惯，在所有特殊类的实例之间共享一个单独的日志对象，
并且在程序的持续时间中使用相同的日志组件。
Example 1: The following statement errantly declares a non-static logger.
例子1：下面的语句定义了一个non-static日志组件。
private final Logger logger =
Logger.getLogger(MyClass.class);
14.3.RECOMMENDATIONS 建议
Declare loggers to be static and final.
Example 2: The code in Example 1 could be rewritten in the following way:
定义日志组件为static和final类型。
例子2：在例子1中的代码可以以下面的方式改写：
private final static Logger logger =
Logger.getLogger(MyClass.class);
15. Code correctness:null argument to equals(Structual):
SystemCommonParameters.java
if (obj==null||obj.equals(null)) {
15.1.原文：The expression obj.equals(null) will always be false.
翻译：表达式obj.equals(null)总是为false.
15.2.EXPLANATION 解释
The program uses the equals() method to compare an object with null.
This comparison will always return false, since the object is not null.
(If the object is null, the program will throw a NullPointerException).
程序使用equals()方法来比较对象和null.
这个比较将一直返回false,当然这是这个对象不是null的情况下.
(如果这个对象是null,程序将抛出NullPointException).
15.3.RECOMMENDATIONS 建议
It is possible that the programmer intended to check to see if the object was null.
可能是，程序员打算去检查,object对象是不是null.
Instead of writing 更换下面的写法
obj.equals(null)
they intended 他们打算
obj == null
15.4.REFERENCES 引用
[1] JavaDoc for Object, Sun Microsystems,
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Object.html#equals(java.lang.Object)
对象的Java文档地址
相关阅读:
- Fortify分析翻译6 (flashtree, 2008-8-27)
- Fortify分析翻译7 (flashtree, 2008-8-27)
TAG: Fortify
