C# 中何時使用 Try 模式的最佳實踐

Question

在閱讀了一些關於該主題的內容后，我仍然不確定何時提供 TryGet*(someParameter, out someValue) 方法。 我理解當存在可以在失敗的情況下拋出異常的方法的變體時它是如何有用的，但是我不能真正形成一個通用規則來幫助我決定何時提供任何一種方法.

對此想到的一些問題：

• 為什么不讓非嘗試方法不拋出異常？
• 什么時候拋出異常比只返回 null 更好？
• 如果決定歸結為使用一種僅返回可空類型（或某些 Result 類型）的方法，是否應該始終反映在方法名稱中，因為它必須以“Try”為前綴？
• 在每種情況下都提供兩種類型的方法總是更好嗎？

我專門處理一個集合，我有一堆方法，比如： void GetAt(position) bool TryGetAt(position, out item)

我不確定這是否需要，但感覺我正在做的事情在某種程度上是錯誤的。

Answer 1

TryParse模式不（只是）關於防止異常。 這是一種向調用者顯示輸入可能無效並且他/她可以相應地處理false情況的方法。 所以你從方法中得到兩個信息：

1. 解析/解析的值，以防它成功
2. 一個bool ，指示該值是否可以成功解析

請注意，您無法從值本身獲取第二個信息，因為無論您在false情況下從方法返回什么，它都可能是有效值。

TryParse模式的唯一缺點，即返回一個bool值和作為out參數的值，是您不能將它與其他方法調用“鏈接”。 這就是為什么我有時會在解析原始類型時提供不同的方式： return Nullable<T> ：

public static class StringExtensions
{
    public static int? TryGetInt(this string input)
    {
        return int.TryParse(input, out int value) ? value : new int?();
    }
    // more methods like this...
}

為什么不讓非嘗試方法不拋出異常？

因為通常你不能這樣做，因為異常不是來自你的代碼。 但正如我所說，這不是為了防止異常，而是為了幫助方法的調用者理解它並處理結果。

什么時候拋出異常比只返回 null 更好？

在不正常程序流程的異常情況下。 但不是返回null你應該返回一個bool （try-get with out -parameter）或一個可為空的類型（原始類型）。

如果決定歸結為使用一種僅返回可空類型（或某些 Result 類型）的方法，是否應該始終反映在方法名稱中，因為它必須以“Try”為前綴？

是的，這將有助於理解該方法在成功時也會返回信息。

在每種情況下都提供兩種類型的方法總是更好嗎？

不，那只是迷惑人，應該使用什么方法？！

我專門處理一個集合，我有一堆方法，比如： void GetAt(position) bool TryGet(position, out item)

聽起來像是TryGet的合理用例，但不要同時提供兩者。 但是，您沒有提供足夠的信息。

Answer 2

對我來說， Try Pattern 開始發揮作用，當它經常發生時，你沒有匹配並且不是例外。

因此，根據您的具體情況，您的 class 被要求提供它無法提供的東西的可能性有多大？ 更重要的是，在這種情況下能做些什么呢？ 調用者是否可以做一些簡單的事情（例如調用其他一些Try -Method，回退到其他東西）或者使用無效的參數值調用您的方法確實是異常的事情，您所能做的就是拋出異常以擺脫整個堆棧？

根據每個案例中上述問題的答案，我決定通往 go 的路線。