【问题标题】:Java Try Catch Block SizeJava Try Catch 块大小
【发布时间】:2014-06-20 20:25:24
【问题描述】:

这可能是一个奇怪的问题,但我仍然认为我会要求深入了解这一点,并阻止我在编码时做错事。

假设我有一个函数 func1(),在其中我调用了一个函数 func2()。 func2() 抛出异常 e1。我想在 func1() 中捕获这个异常。

所以我是否在函数本身的开头开始一个 try 块并在 func1() 的末尾用 catch 块结束它,而不是仅仅围绕我调用函数 func2( )。

我从编码人员的角度知道,如果抛出异常,他将能够准确地知道异常来自哪里。如果我们忽略这一点,将整个方法放在 try-catch 中是否还有其他不良影响?

编辑 - 代码片段

所以我将 JSON 字符串转换为 JSON 节点。此操作引发异常。但是,我没有用 try-catch 块包围这一语句,而是将整个函数放在 try 块中。它对我来说看起来更干净。 :)

public void storePublicData(String publicData, String twitterId) {

    try {

        Date date=new Date();
        SimpleDateFormat formatter = new SimpleDateFormat("yyyy-MM-dd");
        String day = formatter.format(date);

        BasicDBObject query = new BasicDBObject("date", day);
        query.append("brand_id", twitterId);

        JsonNode publicDataJsonNode;

        publicDataJsonNode = JSONOperations.castFromStringToJSONNode(publicData);


        DBObject document = BasicDBObjectBuilder.start()
                .add("brand_id", twitterId)
                .add("date", day)
                .add("followers", publicDataJsonNode.get("followersCount").asText())
                .add("tweets", publicDataJsonNode.get("tweetsCount").asText())
                .get();

        twitterCollection.update(query,new BasicDBObject("$set", document), true, false);

    } catch (JSONParamsException e) {
        // TODO Auto-generated catch block
        e.printStackTrace();
    }

}

【问题讨论】:

  • 如果您添加一些代码片段,您的问题会更有价值。 :) 无论如何,这个问题最好放在Code ReviewSoftware Engineering,也许吧。
  • 哈,这个问题的用户名非常合适 :) 同意,对程序员可能更好。
  • 添加了代码片段。 :) 我希望现在这是一个更有价值的问题.. :D

标签: java try-catch


【解决方案1】:

最大的缺点是你也可能捕捉到你打算捕捉的异常。

例如,假设您有一个可能抛出NullPointerException 的方法,您可以处理这种情况。 (这样的方法可能写得不好,但假设它是一个库方法,你不能改变它。)所以,你抓住了 NPE:

void func1() {
    try {
        func2();
        if (someString.equals("some value") {
            someOtherFunction();
        }
    } catch (NullPointerException e) {
        // handle func2()'s NPE somehow
    }

}

try 的正文中可能有两个的地方NPE:来自func2,或者如果someStringnull,则来自someString.equals。这段代码对两者的处理方式相同,这可能是一个错误。

一般来说,几乎在编程的所有方面(变量范围、try-catch 块、类成员等),范围越小,推理就越容易,编写错误的可能性也就越小。

【讨论】:

    【解决方案2】:

    您显然可以在方法的整个主体周围使用 try/catch 块,但将其限制在您预期会出错的区域会增加代码的可读性。我也相当确定它们非常缓慢,效率低下,没有必要“尝试”一些没有可能出现 IOException 的东西,例如 int i = 2 + 2;

    【讨论】:

    • 仅仅使用 try-catch 块并不是很慢,它会抛出(并记录)一个很慢的异常。如果没有抛出异常,关于 try-catch 性能的有趣问题:stackoverflow.com/questions/16451777/…
    • 感谢您的链接!非常有趣,尽管编译器不会在 try 中优化代码。
    【解决方案3】:

    我从编码人员的角度知道,如果抛出异常, 他将能够确切地知道异常来自哪里

    你在那儿搞定了:当你编写一个方法时,你就在你和用户之间建立了一个契约。如果您声明该方法引发异常 - 用户有责任捕获和处理该异常。如果有意义 - 您应该这样做(例如,如果您未能打开与数据库的连接,则抛出异常)。也就是说,在其他情况下,您可能希望执行回退并仅向用户报告操作是否成功,在这种情况下,您可以使用 try/catch 包围方法 2 中的所有代码并返回一个布尔值以保存您的用户处理异常的额外编码。

    【讨论】:

      【解决方案4】:

      好吧,如果你在调用funct2之后在funct1中有任何东西,如果你把整个方法放在try-catch中,它就不会被执行。

      【讨论】:

        【解决方案5】:

        我在引用 Clean Code Book:

        错误处理是一项工作,函数应该做一项工作。 因此,处理错误的函数不应该做任何其他事情。这意味着(如上面的示例)如果关键字 try 存在于函数中,它应该是函数中的第一个单词,并且存在 在 catch/finally 块之后应该什么都没有。

        所以你应该创建一个管理异常的方法,如下所示:

        public class Test {
        
        
          public void doSomthing(){
        
            // here i don't need to manage the exception because i have built parseDate(String date)
            Date date = parseDate("10-17-2016");
        
          }
        
        
          private Date parseDate(String date){
            Date result = null;
            try {
                result = new SimpleDateFormat().parse(date);//Throws Parse Exception
            } catch (ParseException e) {
                // Here you can:
                //1) Throws other exception (Checked or Unchecked)
                //2) Log the exception
                // I think you should not re-throws the exception because
                //is responsibility of this methods manage the exception
                e.printStackTrace();
            } 
            return result;
          }
        
        }
        

        【讨论】:

          猜你喜欢
          • 2016-05-21
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 2011-06-01
          • 2015-09-05
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          相关资源
          最近更新 更多