正確和高效的編程風格

有一個類X. 方法method()在X類拋出SomeException。正確和高效的編程風格

我不知道哪種處理異常的方法更好 - 效率更高。如果它圍繞try-block方法拋出異常和所有依賴關係，或者在try-block之外保持依賴關係，但在失敗後從方法返回。

public void test() { 
    X x = new X(); 

    try { 
      T temp = tx.method(); 
      temp.doWhatever(); 
    } 

    catch(SomeException e) { handleException(e); } 
}

或

public void test() { 
    X x = new X(); 
    T temp = null; 
    try { 
      temp = tx.method(); 
    } 

    catch(SomeException e) { 
      handleException(e); 
      return; 
    } 

    temp.doWhatever(); 
}

編輯：（註解之後）

更重要的是我undersand我的代碼這樣的：那麼這將excetuted接下來的事情就是catch

1. tx.method()會拋出異常 - 塊。它並沒有消失，temp仍然是null，因爲程序跳過temp.doWhatever();行，並且不會有NullPointerException。

2. 這裏我用return指令，因爲我不想執行temp.doWhatever()因爲temp是null

來源

2012-07-12 squixy

選項1對我來說更加清晰 – Eric 2012-07-12 17:32:34

（1）爲什麼一個'public void test'和另一個'public static void main'？（2）你意識到在第二塊代碼中，它意味着'temp.doWhat''不會有例外被捕獲？ – 2012-07-12 17:32:57

@notfed：對於你的問題（2），雖然（我們可以假設沒有任何東西被拋出），但OP沒有提及任何關於'doWhatever'拋出'Exception'的信息。 – nhahtdh 2012-07-12 17:33:51

第二種情況甚至不會編譯（甚至沒有意義），因爲temp在try塊之外是不可見的。在任何情況下，我會去這樣的：

public void test() { 
    X x = new X(); 

    try { 
      T temp = tx.method(); 
      temp.doWhatever(); 
    } 

    catch(SomeException e) { handleException(e); } 
}

，因爲如果初始化temp失敗，則temp操作的其餘部分應不會執行。

來源

2012-07-12 17:32:01 Tudor

「因爲如果初始化temp失敗，其餘的temp操作不應該執行。」我同意你的看法，這就是爲什麼我把第二個例子放回去的原因。 – squixy 2012-07-12 18:11:01

@squixy：現在你的兩個片段是相同的。我仍然會選擇第一個，因爲不建議在方法中散佈「return」語句，因爲它更難以理解代碼的行爲方式。 – Tudor 2012-07-12 19:46:49

-1

我看不出這兩種方法有什麼區別。

來源

2012-07-12 17:29:43

他們做什麼沒有區別......但這是一個_coding style_問題。這纔是重點。 – Eric 2012-07-12 17:31:43

只有第一個可能，因爲臨時聲明在裏面。

我個人選擇第一個，否則需要在嘗試之前聲明：T temp = null。

臨第一

第一個代碼少跳轉指令和變量temp是更多的地方，並且無空初始化：

問題的修正之後。

此外，編碼風格更緊湊，沒有空初始化，可能的錯誤點。

此外，異常應該保持在視野之外;它更容易閱讀第一個版本。異常不應該中斷線性編碼和讀取過程。

Pro的第二

更清楚其中的異常可以幹。

來源

2012-07-12 17:31:54

現在編輯。 – squixy 2012-07-12 18:09:59

異常工作方式的一個關鍵點是您可以使用您的樣式編號1：讓一個代碼塊放心地執行，無論它何時中斷，流程都會中斷並處理錯誤。所以我會一直建議第一種風格。

來源

2012-07-12 17:34:16

在方法中有多個返回是不好的。但那只是爲了有可理解的代碼。您可以通過布爾和ifs避免返回。

我認爲沒有效率問題。如果第一條語句發生異常，則不執行第二條語句。如果沒有例外，那麼...嗯...我認爲應該沒有開銷，因爲第二種方法。你可以通過try catch告訴你「彙編器」的代碼是怎麼樣的：D

在我看來，編寫難以置信的代碼更重要。現今的編譯器非常好，優化了最好的東西。

來源

2012-07-12 17:42:52 AxP

選項二由於可擴展性原因而不利。假設稍後有人決定test（）應該在test.doWhatever（）之後做某件事情，即使遇到異常情況。他們必須在當時重新將代碼重構爲選項一。由於從一開始就使用選項1沒有成本，所以他們不應該這樣做。

此外，儘管編譯器仍然會接受，但try/catch塊的設計原則被catch塊返回所侵犯。對於捕獲是一個返回點，它應該拋出一個異常，因爲由於特殊情況而調用該操作。

來源

2012-07-12 18:33:09 user1482813

正確和高效的編程風格

回答

相關問題