【问题标题】:Long try statements长时间的尝试语句
【发布时间】:2013-02-16 18:51:34
【问题描述】:

将函数的大部分代码放在try statement 中是否有任何缺点。如果我做一些需要try statement 的事情,我通常最终会在 try 语句中为该函数做很多工作,因为我通常会在其中声明我的变量,并且如果我这样做,就不能在该范围之外使用它们。这是否普遍并被接受?人们是否通常在没有初始化变量之前声明变量,这样他们就不会在try statement 中做所有事情(包括对其他函数的调用)?还是很长也无所谓?

【问题讨论】:

  • 不确定你在做什么,但你可以在 try 块之外将变量初始化为某个默认值。
  • 如果它惹恼了你,你总是可以在你的方法头中添加一个throws 子句,并且只将方法调用包装在一个try/catch-block 中。
  • @nhahtdh 或者根本不初始化:int whatever; 在 Java 中有效。
  • @11684 在所有情况下这都不是个好主意。
  • 检查异常是 Java 中让我烦恼的地方,但它真的很有帮助

标签: java exception variables try-catch


【解决方案1】:

如果它很长,这很重要,但不是你想的那样。这很重要,因为它使您的代码难以阅读和测试。您最好将其重构为几种方法:

public void doComplexThing() {
    try {
        SomeObject o1 = doSomethingLessComplex();
        SomeOtherObject o2 = doSomethingElse(o1);
        doFinalThing(o2);
    }
    catch (SomeException e) {
        // handle the exception
    }
}

【讨论】:

    【解决方案2】:

    一个方法应该做一件事并且做好。在这种情况下,您的方法正在做两件事:业务逻辑和错误处理:

    public Foo bar() {
        try {
            //business logic that may throw
            //...
            //end even more
        } catch(BuzzException e) {
            //Error handling
        }
    }
    

    我经常发现自己将try 块的内容提取到一个单独的方法中而没有错误处理:

    public Foo bar() {
        try {
            return unsafeBar();
        } catch(BuzzException e) {
            //Error handling
        }
    }
    
    public Foo unsafeBar() throws BuzzException {
        //business logic that may throw
        //...
        //end even more
    }
    

    【讨论】:

      【解决方案3】:

      作为一名高级程序员,我理解完美地使用 try catch 而不是抛出异常的语句与代码整洁之间的混淆。

      这里我倾向于try catch over the statements that need it。

      首先让我们了解 try catch 的必要性。我们捕获异常,因为我们想在此时此地处理它。如果我们不把它扔给调用者。我们把它扔掉,这样我们以后就不会忘记处理它。从不,Oh!, let me finish this method and then I will worry about the exception handling later。在编写代码时执行此操作,想一想,您是否需要打印错误并返回 null,或者您是否需要用户知道有些事情搞砸了?您想将所有连接问题合并到recycle the connection 有点消息吗?如果是,则抛出您自己的自定义异常。但一定要处理好。忽略和做不好的异常处理是项目维护成本增加和客户烧心的根本原因。这就是好产品和马虎产品的区别。

      至于代码的简洁性,我发现 catch 块中的 cmets 让您觉得这一切都值得。是的,会有比你更高级的人,他不会明白捕捉确切语句的重要性,会直接捕捉catch (Exception e)。可悲的是,我会说。但是当你编码时,你应该坚持你的道德规范。做对了,做一次。

      【讨论】:

        【解决方案4】:

        如果try 块变得有点长,最好隔离实际上将异常抛出到它们自己的方法中的调用。这样,您就可以单独解决该块中可能引发的几种异常。

        如果您尝试测试或查找“神秘”错误,那么在 try 中用普通的旧 catch(Exception ex) 覆盖许多异常会在以后引起头痛。更不用说诸如适当的资源/流处理之类的事情了,这是许多检查异常的目的。

        【讨论】:

          猜你喜欢
          • 1970-01-01
          • 2011-07-25
          • 2015-12-14
          • 2012-02-25
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 2012-03-21
          相关资源
          最近更新 更多