2013-01-22 41 views
1

可以使用例如兩個查詢在一個try-catch塊?在一次嘗試上使用更多查詢的有效性?

try 
{ 
    $query1 = prepare("SELECT * FROM tbl1..."); 
    $query2 = prepare("SELECT * FROM tbl2..."); 
    $query1 = execute(); 
    $query2 = execute(); 
}catch (PDOException $e) 
{ 
    print "Error!: " . $e->getMessage(); 
    return false; 
} 

OR,它應該是:

try 
{ 
    $query1 = prepare("SELECT * FROM tbl1..."); 
    $query1 = execute(); 
}catch (PDOException $e) 
{ 
    print "Error!: " . $e->getMessage(); 
    return false; 
} 


try 
{ 
    $query2 = prepare("SELECT * FROM tbl2..."); 
    $query2 = execute(); 
}catch (PDOException $e) 
{ 
    print "Error!: " . $e->getMessage(); 
    return false; 
} 

如果這兩個方法都接受並使用的是他們之間有沒有differenc? (Speed?) 因爲我必須在索引中做更多的查詢,但我不想分開所有的

+0

「準備'和'執行'調用看起來不正確。你應該使用' - >'嗎? – SDC

+0

是的,這是不對的,我沒有使用它。這只是爲了說明我的想法(關注try-catch塊) – Gery

回答

2

這兩種方法都被接受,但第一種方法更具可讀性。一個try catch對於同一組功能就足夠了。

如果其中一個呼叫失敗,它將停止集團執行並直接轉至catch,因此將所有工作都放在try之內。

我懷疑在第二種方法中,編譯器可能會將兩個catchs中的代碼識別爲相同,並將其作爲第一個優化,但應該嘗試此操作。

+0

@Cobra_Fast:基於什麼證據?我無法真正看到單個try-catch塊的速度超過2個獨立塊的好理由。如果有的話,假設兩個查詢都相互依賴,使用2個塊可能會拋出2個錯誤對象,如果沒有處理異常_「正確」_ –

+0

謝謝你的回答 – Gery

+0

@Gery:不要忘記接受答案幫助你最好。 – Eregrith

1

它有什麼不同在你的propuse。如果一個查詢是相互依賴的,那麼它們應該處於try-catch狀態。如果不是,如果您不需要另一方的數據,並且如果您認爲頁面沒有第一次嘗試抓取的信息,那麼您可以繼續查詢。

至少我認爲這樣。

+0

謝謝你的回答 – Gery

2

如果根據哪個命令失敗需要不同的行爲,那麼您需要將每個(一對)命令包裝在它們自己的try/catch塊中。

如果你所擔心的是一些錯誤從任何線發生的事情,那麼你可以用所有的命令一起,處理所有異常一樣。

+0

謝謝你的回覆 – Gery

2

兩者都是完全有效的。正如其他人所說的那樣,這都是關於用例的。

我想添加到它的唯一的事情是,你可能也想使用一個事務。例如,如果第二個查詢失敗,您可以回滾。注意這也取決於用例。

+0

謝謝你的評論 – Gery

1

我會說盡可能多地使用一個try-catch塊。如果您的第二個查詢取決於您的第一個查詢的成功,則第二個查詢將在第一個查詢異常時執行。
在我眼中,一系列try-catch塊並不能提供非常易讀的代碼。一個可觀的嘗試抓住是可以的,只要你不去所有的口袋妖怪式(抓住他們所有)......我的意思是可以在一個try-block內執行5個查詢,但是當你正在處理同一個塊中的每個查詢的結果,這是太過分了。

如果您想知道哪種方法最有效:catch - 塊被拋出的Exception類的實例觸發。 catch塊內的代碼預計會處理該錯誤,所以腳本不需要完全失敗,並且可以恢復正常的服務。
如果您使用多個try-catch塊,則代碼片段可能會拋出多個Exception實例(本例中爲PDOException)。但「小」的開銷是,創建一個新的實例不是免費的。如果在行程結束時仍想向用戶顯示已成功查詢的數據並顯示一些數據未成功檢索的通知,則需要多次嘗試捕獲,如果要顯示一切,或什麼都不用,使用1個try-catch塊,並使用Exception實例來計算出什麼查詢失敗並向用戶顯示相應的錯誤信息(或者只是告訴他們全部出錯)

+0

謝謝你的回覆 – Gery