Java重构异常处理最佳实践

时间:2012-07-30 12:40:26

标签: java exception-handling refactoring

说明 我总是告诉人们一直检查所有参数,这导致了大量的检查和尝试捕获。

问题: 在下面的代码中,我清理了代码,以便只有处理异常处理的方法是公开公开而不是重构的私有帮助方法的根方法。这种做法好吗?

我没有处理更接近它们可能发生的方法的异常,但代码更清晰。

代码备注:

  • 方法不包括validateInputs()。
  • 参数对象a是从通过“someCode”创建的参数派生出来的,它表示我想要传递的参数。每当我需要超过2个参数时,我将这些参数重构为参数对象。

代码:

public class UnderTest {

    public UnderTest() {}

    public boolean runWork(  String someValue ) throws CustomException
    {
        try
        {
            validateInputs();
            // someCode
            .
            .
            processWork(  ParameterObject a );
        }
        catch( Exception e )
        {
            logError(e);
        }
    }

    private void processWork( ParameterObject a  )
    {
        Operation1( ParameterObject a  );
        Operation2( ParameterObject a  );
    }

    private void Operation1( ParameterObject a  )
    {
        // someCode
    }

    private void Operation2( ParameterObject a  )
    {
        // someCode
    }

    private void logError(Exception e)
    {    
        throw new CustomException(e,"Message");
    }        
}

2 个答案:

答案 0 :(得分:1)

我会选择两者兼而有之。验证输入总是一个好主意,诸如Apache commons-lang Validate类之类的库可以使这更容易。一般来说,不正确的参数应该导致运行时异常(通常为IllegalArgumentExceptionNullPointerException)。你进入私人方法进行输入验证的深度是一个品味问题。请记住,越早发现无效参数,错误消息就会越有用。

当然,这假设您很好地记录了面向公众的API(理想情况下也是您的内部方法)。明确哪些内容对您的输入有效。

答案 1 :(得分:1)

我倾向于在一些公共API进入类时检查参数。在私有方法中,我只通过断言检查或根本不检查。这意味着我更信任自己的班级。