那么这部分代码需要覆盖嘛？需要。假设代码误写成：

LOGGER.debug(String.format("[util]convert [%] to [%s]"， path， returnPath));

　　某天日志级别设为debug，会发现报错。类似的还有日志中经常输出某个对象信息，但是该对象可能是null，从而抛出空指针异常。

　　提示：日志也是代码的一部分，需要通过调整日志级别来覆盖。

　　5、JVM等参数

　　程序的配置参数会直接影响代码路径覆盖，不仅包括业务上的一些配置，也包括依赖平台的参数，例如JVM参数除了会影响性能，也会影响代码的覆盖情况，例如断言相关参数：

-ea[:...|:] 和-da[:...|:]

　　分别是启用和关闭用户断言（-esa/-eda，针对系统断言），在JAVA中断言是默认关闭的，所以涉及断言的代码默认无法覆盖。

　　提示：一些代码路径能否覆盖与JVM等参数有关，需要通过调整参数来覆盖

　　6、main()方法

　　一些程序员喜欢临时写一个main()方法方便于测试，完成测试后寻思以后还能方便测试留了下来。导致产品代码中的这些代码无法被覆盖。在产品代码中，应该删除这些，部署的毕竟是产品代码，不是测试代码。

　　提示：main()方不需要被覆盖，产品代码不保留测试代码

　　7、编码习惯写法

　　在编码过程中，常常有一些习惯写法，常见的比如：（1）覆盖toString()方法；（2）以意义配对形式写一些方法：比如数据连接中Connect()搭配DisConnect()，枚举中常用的toString()搭配fromString()，这些惯用的写法告诉读者一些涵义，但是不见得所有的方法都必须被调用，例如在产品应用中，我们可能启动起一个周期性的job，但是本身尚未添加“取消“功能（或本来不需要停止）。自然也无法调用：但是它应该不应该存在？笔者认为作为完整的功能应该存在。类似的还有异常定义的时候，会定义很多重载的方法，虽然不见得每个都调用，但是不定某天会被调用。

　　提示：编码习惯写法造成的未覆盖代码需要被覆盖，是代码的一部分。

　　8、项目的使用方式

　　下面两种使用方式会造成代码不能全部被覆盖：

　　1）客户端Jar方式：部分代码作为客户端Jar包形式提供给他人使用；

　　2）分布式系统交互：分布式系统之间存在交互时，例如从系统1复制文件到系统2，如果始终按照从1到2的顺序，又仅仅统计系统1的代码覆盖肯定不能覆盖全部。需要覆盖的代码虽出于一处，但是使用方式不同也会导致在不合并覆盖数据情况下代码未覆盖。

　　提示：项目使用方式造成的代码覆盖统计数据分散需要通过合并数据来覆盖。

　　9、常用佳实践

　　一些很难覆盖的佳实践：例如对于一些资源（IO，lock）的释放，可能直接try…catch然后记录异常，这些异常一般很难发生。

public static void close(InputStream inputStream)
{
         try {
             inputStream.close();
         } catch (Exception e) {
             LOGGER.warn("fail to close inputstream");
         }
}

　　提示：常用佳实践可以不覆盖。