Question

将您的大多数代码放在try statement中是否有任何缺点。如果我做了需要try statement的事情，我通常最终会在try语句中为该函数做很多工作，因为我经常在那里声明我的变量，如果我那样做就不能在那个范围之外使用它们。这是常见的并被接受吗？人们通常在没有初始化之前声明变量，所以他们没有在try statement内做所有事情（包括调用其他函数）吗？或者它是否很长并不重要？

Answer 1

一种方法应该做一件事，做得好。在这种情况下，您的方法正在做两件事：业务逻辑和错误处理：

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
}

Answer 2

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

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

Answer 3

如果try块变得有点长，那么将实际抛出异常的调用隔离到自己的方法中是个好主意。这样你就可以单独解决在该块中抛出的几种异常。

如果您正在尝试测试或发现“神秘”错误，那么在try中使用普通的旧catch(Exception ex)覆盖许多异常会导致后来的麻烦。这就是正确的资源/流处理之类的事情，这是许多经过检查的例外情况。

Answer 4

作为一名高级程序员，我理解使用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块中的注释使得它值得你花时间。是的，会有一些高级的人不理解捕获确切语句的重要性，并会直接捕获catch (Exception e)。可怜，我会说。但是在编码时你应该坚持自己的道德规范。做得对，一直做。

长期尝试声明

4 个答案: