Trả lại giá trị ma thuật, ném ngoại lệ hoặc trả lại sai khi thất bại?

Đôi khi tôi cuối cùng phải viết một phương thức hoặc thuộc tính cho một thư viện lớp mà không có câu trả lời thực sự nào, nhưng đó là một thất bại. Một cái gì đó không thể được xác định, không có sẵn, không tìm thấy, hiện không thể hoặc không có thêm dữ liệu.

Tôi nghĩ có ba giải pháp khả thi cho một tình huống tương đối không đặc biệt như vậy để chỉ ra sự thất bại trong C # 4:

• trả về một giá trị ma thuật không có ý nghĩa khác (như nullvà -1);
• ném một ngoại lệ (ví dụ KeyNotFoundException);
• trả về falsevà cung cấp giá trị trả về thực tế trong một outtham số, (chẳng hạn như Dictionary<,>.TryGetValue).

Vì vậy, các câu hỏi là: trong trường hợp không đặc biệt nào tôi nên ném một ngoại lệ? Và nếu tôi không nên ném: khi nào trả về một giá trị ma thuật được xác định ở trên thực hiện một Try*phương thức với một outtham số ? (Đối với tôi, outtham số có vẻ bẩn và sử dụng đúng cách sẽ tốn nhiều công sức hơn.)

Tôi đang tìm kiếm câu trả lời thực tế, chẳng hạn như câu trả lời liên quan đến hướng dẫn thiết kế (tôi không biết gì về Try*phương pháp), tính khả dụng (khi tôi hỏi điều này đối với thư viện lớp), tính nhất quán với BCL và khả năng đọc.

Trong Thư viện lớp cơ sở .NET Framework, cả ba phương thức đều được sử dụng:

• trả về một giá trị ma thuật không có ý nghĩa khác:
  • Collection<T>.IndexOf trả về -1,
  • StreamReader.Read trả về -1,
  • Math.Sqrt trả lại NaN,
  • Hashtable.Item trả về null;
• ném một ngoại lệ:
  • Dictionary<,>.Item ném KeyNotFoundException,
  • Double.Parseném FormatException; hoặc là
• trả về falsevà cung cấp giá trị trả về thực tế trong một outtham số:
  • Dictionary<,>.TryGetValue,
  • Double.TryParse.

Lưu ý rằng như Hashtableđược tạo ra vào thời điểm khi không có tướng trong C #, nó sử dụng objectvà do đó có thể trở lại nullnhư một giá trị ma thuật. Nhưng với thuốc generic, các trường hợp ngoại lệ được sử dụng Dictionary<,>và ban đầu nó không có TryGetValue. Rõ ràng cái nhìn sâu sắc thay đổi.

Rõ ràng, Item- TryGetValuevà Parse- TryParselưỡng tính là có một lý do, vì vậy tôi cho rằng ném ngoại lệ cho những thất bại không phải là đặc biệt là trong C # 4 không được thực hiện . Tuy nhiên, các Try*phương thức không phải lúc nào cũng tồn tại, ngay cả khi Dictionary<,>.Itemtồn tại.

Tôi không nghĩ rằng các ví dụ của bạn thực sự tương đương. Có ba nhóm riêng biệt, mỗi nhóm có lý do riêng cho hành vi của nó.

1. Giá trị ma thuật là một lựa chọn tốt khi có một điều kiện "cho đến khi" như StreamReader.Readhoặc khi có một giá trị sử dụng đơn giản sẽ không bao giờ là câu trả lời hợp lệ (-1 cho IndexOf).
2. Ném ngoại lệ khi ngữ nghĩa của hàm là người gọi chắc chắn rằng nó sẽ hoạt động. Trong trường hợp này, khóa không tồn tại hoặc định dạng kép xấu thực sự đặc biệt.
3. Sử dụng một tham số out và trả về một bool nếu ngữ nghĩa là để thăm dò nếu hoạt động có thể hay không.

Các ví dụ bạn cung cấp hoàn toàn rõ ràng cho trường hợp 2 và 3. Đối với các giá trị ma thuật, có thể tranh luận nếu đây là một quyết định thiết kế tốt hay không trong mọi trường hợp.

Trả NaNvề bởi Math.Sqrtmột trường hợp đặc biệt - nó tuân theo tiêu chuẩn dấu phẩy động.

Bạn đang cố gắng truyền đạt cho người dùng API những gì họ phải làm. Nếu bạn ném một ngoại lệ, sẽ không có gì buộc họ phải nắm bắt nó và chỉ đọc tài liệu sẽ cho họ biết tất cả các khả năng là gì. Cá nhân tôi thấy chậm và tẻ nhạt khi đào sâu vào tài liệu để tìm tất cả các ngoại lệ mà một phương pháp nhất định có thể đưa ra (ngay cả khi nó trong intellisense, tôi vẫn phải sao chép chúng ra bằng tay).

Một giá trị ma thuật vẫn yêu cầu bạn đọc tài liệu và có thể tham khảo một số constbảng để giải mã giá trị. Ít nhất là nó không có chi phí ngoại lệ cho những gì bạn gọi là sự cố không đặc biệt.

Đó là lý do tại sao mặc dù outcác tham số đôi khi được tán thành, tôi thích phương thức đó, với Try...cú pháp. Đó là cú pháp .NET và C # chuẩn. Bạn đang liên lạc với người dùng API rằng họ phải kiểm tra giá trị trả về trước khi sử dụng kết quả. Bạn cũng có thể bao gồm một outtham số thứ hai với thông báo lỗi hữu ích, một lần nữa giúp gỡ lỗi. Đó là lý do tại sao tôi bỏ phiếu cho giải pháp Try...với outtham số.

Một lựa chọn khác là trả về một đối tượng "kết quả" đặc biệt, mặc dù tôi thấy điều này tẻ nhạt hơn nhiều:

interface IMyResult
{
    bool Success { get; }
    // Only access this if Success is true
    MyOtherClass Result { get; }
    // Only access this if Success is false
    string ErrorMessage { get; }
}

Sau đó, chức năng của bạn có vẻ đúng bởi vì nó chỉ có các tham số đầu vào và nó chỉ trả về một điều. Chỉ là một thứ mà nó trả lại là một loại tuple.

Trong thực tế, nếu bạn thích kiểu đó, bạn có thể sử dụng các Tuple<>lớp mới được giới thiệu trong .NET 4. Cá nhân tôi không thích thực tế là ý nghĩa của từng trường ít rõ ràng hơn vì tôi không thể đưa ra Item1và Item2tên hữu ích.

Như các ví dụ của bạn đã cho thấy, mỗi trường hợp như vậy phải được đánh giá riêng biệt và có một dải màu xám đáng kể giữa "hoàn cảnh đặc biệt" và "kiểm soát dòng chảy", đặc biệt nếu phương pháp của bạn dự định có thể sử dụng lại và có thể được sử dụng theo các mẫu khá khác nhau hơn nó được thiết kế ban đầu cho. Đừng hy vọng tất cả chúng ta ở đây đồng ý về ý nghĩa "không đặc biệt", đặc biệt nếu bạn thảo luận ngay về khả năng sử dụng "ngoại lệ" để thực hiện điều đó.

Chúng tôi cũng có thể không đồng ý về thiết kế nào giúp mã dễ đọc và duy trì nhất, nhưng tôi sẽ cho rằng người thiết kế thư viện có tầm nhìn cá nhân rõ ràng về điều đó và chỉ cần cân bằng nó với các cân nhắc khác có liên quan.

Câu trả lời ngắn

Theo dõi cảm xúc của bạn ngoại trừ khi bạn đang thiết kế các phương pháp khá nhanh và mong đợi khả năng tái sử dụng không lường trước được.

Câu trả lời dài

Mỗi người gọi trong tương lai có thể tự do dịch giữa các mã lỗi và ngoại lệ theo ý muốn theo cả hai hướng; điều này làm cho hai cách tiếp cận thiết kế gần như tương đương ngoại trừ hiệu năng, thân thiện với trình gỡ lỗi và một số bối cảnh tương tác bị hạn chế. Điều này thường làm giảm hiệu suất, vì vậy hãy tập trung vào đó.

• Theo nguyên tắc thông thường, mong đợi rằng việc ném một ngoại lệ chậm hơn 200 lần so với lợi nhuận thông thường (trong thực tế, có một sự khác biệt đáng kể trong đó).

• Như một quy tắc khác, việc ném một ngoại lệ thường có thể cho phép mã sạch hơn nhiều so với giá trị ma thuật thô sơ nhất, bởi vì bạn không dựa vào lập trình viên dịch mã lỗi sang mã lỗi khác, vì nó đi qua nhiều lớp mã khách hàng một điểm có đủ bối cảnh để xử lý nó một cách nhất quán và đầy đủ. (Trường hợp đặc biệt: nullcó xu hướng giá tốt hơn ở đây so với các giá trị ma thuật khác vì xu hướng tự động dịch sang NullReferenceExceptiontrường hợp của một số, nhưng không phải tất cả các loại khiếm khuyết; thông thường, nhưng không phải lúc nào cũng khá gần với nguồn gốc của khuyết điểm. )

Vậy bài học là gì?

Đối với một chức năng được gọi chỉ một vài lần trong suốt vòng đời của một ứng dụng (như khởi tạo ứng dụng), hãy sử dụng bất cứ thứ gì mang lại cho bạn mã sạch hơn, dễ hiểu hơn. Hiệu suất không thể là một mối quan tâm.

Đối với chức năng vứt bỏ, hãy sử dụng bất cứ thứ gì cung cấp cho bạn mã sạch hơn. Sau đó thực hiện một số hồ sơ (nếu cần thiết) và thay đổi ngoại lệ thành trả lại mã nếu chúng nằm trong số các tắc nghẽn hàng đầu bị nghi ngờ dựa trên các phép đo hoặc cấu trúc chương trình tổng thể.

Đối với một chức năng tái sử dụng đắt tiền, hãy sử dụng bất cứ thứ gì cung cấp cho bạn mã sạch hơn. Nếu về cơ bản bạn luôn phải trải qua một vòng mạng hoặc phân tích tệp XML trên đĩa, thì chi phí ném ngoại lệ có thể không đáng kể. Điều quan trọng hơn là không mất chi tiết về bất kỳ thất bại nào, thậm chí không vô tình, hơn là trở về từ một "thất bại không đặc biệt" cực nhanh.

Một chức năng tái sử dụng nạc đòi hỏi nhiều suy nghĩ. Bằng cách sử dụng các ngoại lệ, bạn đang buộc một số thứ như làm chậm 100 lần đối với người gọi, những người sẽ thấy ngoại lệ trên một nửa số cuộc gọi của họ, nếu cơ thể của hàm thực thi rất nhanh. Các ngoại lệ vẫn là một tùy chọn thiết kế, nhưng bạn sẽ phải cung cấp một giải pháp thay thế chi phí thấp cho những người gọi không đủ khả năng này. Hãy xem một ví dụ.

Bạn liệt kê một ví dụ tuyệt vời Dictionary<,>.Item, trong đó, nói một cách lỏng lẻo, đã thay đổi từ trả về nullgiá trị sang ném KeyNotFoundExceptiongiữa .NET 1.1 và .NET 2.0 (chỉ khi bạn sẵn sàng coi Hashtable.Itemlà tiền thân không chung chung thực tế của nó). Lý do của sự "thay đổi" này không phải là không có hứng thú ở đây. Tối ưu hóa hiệu suất của các loại giá trị (không có thêm quyền anh) làm cho giá trị ma thuật ban đầu ( null) không còn tùy chọn; outcác tham số sẽ chỉ mang lại một phần nhỏ của chi phí hiệu suất trở lại. Việc xem xét hiệu suất sau này là hoàn toàn không đáng kể so với chi phí ném KeyNotFoundException, nhưng thiết kế ngoại lệ vẫn vượt trội ở đây. Tại sao?

• tham số ref / out phát sinh chi phí của họ mọi lúc, không chỉ trong trường hợp "thất bại"
• Bất cứ ai quan tâm đều có thể gọi Containstrước bất kỳ cuộc gọi nào đến người lập chỉ mục và mẫu này đọc hoàn toàn tự nhiên. Nếu một nhà phát triển muốn nhưng quên cuộc gọi Contains, không có vấn đề về hiệu suất nào có thể xảy ra; KeyNotFoundExceptionlà đủ lớn để được chú ý và cố định.

Điều tốt nhất để làm trong một tình huống tương đối không đặc biệt như vậy để chỉ ra thất bại, và tại sao?

Bạn không nên cho phép thất bại.

Tôi biết, đó là sóng tay và lý tưởng, nhưng hãy nghe tôi nói. Khi thực hiện thiết kế, có một số trường hợp bạn có cơ hội ủng hộ một phiên bản không có chế độ thất bại. Thay vì thất bại 'Find ALL', LINQ sử dụng mệnh đề where chỉ đơn giản trả về một số không có giá trị. Thay vì có một đối tượng cần được khởi tạo trước khi sử dụng, hãy để hàm tạo khởi tạo đối tượng (hoặc khởi tạo khi không phát hiện được khởi tạo). Điều quan trọng là loại bỏ nhánh thất bại trong mã người tiêu dùng. Đây là vấn đề, vì vậy hãy tập trung vào nó.

Một chiến lược khác cho điều này là KeyNotFoundsscenario. Trong hầu hết mọi cơ sở mã mà tôi đã làm việc kể từ 3.0, một cái gì đó giống như phương thức mở rộng này tồn tại:

public static class DictionaryExtensions {
    public static V GetValue<K, V>(this IDictionary<K, V> arg, K key, Func<K,V> ifNotFound) {
        if (!arg.ContainsKey(key)) {
            return ifNotFound(key);
        }

        return arg[key];
    }
}

Không có chế độ thất bại thực sự cho việc này. ConcurrentDictionarycó một tương tự GetOrAddđược xây dựng trong.

Tất cả những gì đã nói, sẽ luôn có những lúc đơn giản là không thể tránh khỏi. Cả ba đều có vị trí của họ, nhưng tôi sẽ ủng hộ lựa chọn đầu tiên. Bất chấp tất cả những gì được tạo ra từ sự nguy hiểm của null, nó nổi tiếng và phù hợp với rất nhiều trường hợp 'không tìm thấy' hoặc 'kết quả không thể áp dụng' tạo nên tập hợp "không phải là thất bại đặc biệt". Đặc biệt là khi bạn đang tạo các loại giá trị vô giá trị, tầm quan trọng của 'điều này có thể thất bại' rất rõ ràng trong mã và khó có thể quên / làm hỏng.

Tùy chọn thứ hai là đủ tốt khi người dùng của bạn làm điều gì đó ngớ ngẩn. Cung cấp cho bạn một chuỗi có định dạng sai, cố gắng đặt ngày thành ngày 42 tháng 12 ... một cái gì đó mà bạn muốn mọi thứ sẽ nổ tung nhanh chóng và ngoạn mục trong quá trình thử nghiệm để mã xấu được xác định và sửa chữa.

Lựa chọn cuối cùng là một cái tôi ngày càng không thích. Các tham số out rất khó xử và có xu hướng vi phạm một số thực tiễn tốt nhất khi thực hiện các phương pháp, như tập trung vào một thứ và không có tác dụng phụ. Thêm vào đó, thông số out thường chỉ có ý nghĩa trong quá trình thành công. Điều đó nói rằng, chúng rất cần thiết cho một số hoạt động nhất định thường bị hạn chế bởi các mối quan tâm đồng thời hoặc cân nhắc về hiệu suất (ví dụ bạn không muốn thực hiện chuyến đi thứ hai đến DB).

Nếu giá trị trả về và tham số out là không tầm thường, thì đề xuất của Scott Whitlock về một đối tượng kết quả được ưu tiên (như Matchlớp của Regex ).

Luôn luôn thích ném một ngoại lệ. Nó có một giao diện thống nhất trong số tất cả các chức năng có thể bị lỗi và nó cho thấy sự thất bại càng nhiều càng tốt - một đặc tính rất đáng mong đợi.

Lưu ý rằng Parsevà TryParsekhông thực sự giống nhau ngoài các chế độ thất bại. Thực tế TryParsecũng có thể trả về giá trị là hơi trực giao, thực sự. Xem xét tình huống, ví dụ, bạn đang xác nhận một số đầu vào. Bạn không thực sự quan tâm giá trị là gì, miễn là nó hợp lệ. Và không có gì sai khi cung cấp một loại IsValidFor(arguments)chức năng. Nhưng nó không bao giờ có thể là chính phương thức hoạt động.

Như những người khác đã lưu ý, giá trị ma thuật (bao gồm giá trị trả về boolean) không phải là một giải pháp tuyệt vời, ngoại trừ như một điểm đánh dấu "cuối phạm vi". Lý do: Các ngữ nghĩa không rõ ràng, ngay cả khi bạn kiểm tra các phương thức của đối tượng. Bạn phải thực sự đọc tài liệu đầy đủ cho toàn bộ đối tượng để "oh yeah, nếu nó trả về -42 có nghĩa là bla bla bla".

Giải pháp này có thể được sử dụng vì lý do lịch sử hoặc vì lý do hiệu suất, nhưng nếu không thì nên tránh.

Điều này để lại hai trường hợp chung: Thăm dò hoặc ngoại lệ.

Ở đây nguyên tắc chung là chương trình không nên phản ứng với các ngoại lệ ngoại trừ để xử lý khi chương trình / vô ý / vi phạm một số điều kiện. Probing nên được sử dụng để đảm bảo rằng điều này không xảy ra. Do đó, một ngoại lệ có nghĩa là việc thăm dò có liên quan đã không được thực hiện trước hoặc điều gì đó hoàn toàn bất ngờ đã xảy ra.

Thí dụ:

Bạn muốn tạo một tập tin từ một đường dẫn nhất định.

Bạn nên sử dụng đối tượng Tệp để đánh giá trước xem đường dẫn này có hợp pháp để tạo hoặc ghi tệp hay không.

Nếu chương trình của bạn bằng cách nào đó vẫn kết thúc cố gắng viết vào một con đường bất hợp pháp hoặc nếu không không thể ghi được, bạn sẽ nhận được một đoạn trích. Điều này có thể xảy ra do một điều kiện cuộc đua (một số người dùng khác đã xóa thư mục hoặc làm cho nó chỉ đọc, sau khi bạn gặp phải)

Nhiệm vụ xử lý một lỗi không mong muốn (được báo hiệu bởi một ngoại lệ) và kiểm tra xem các điều kiện phù hợp với hoạt động trước (thăm dò) thường sẽ được cấu trúc khác nhau, và do đó nên sử dụng các cơ chế khác nhau.

Tôi nghĩ rằng Trymô hình là sự lựa chọn tốt nhất, khi mã chỉ cho biết những gì đã xảy ra. Tôi ghét param và thích đối tượng nullable. Tôi đã tạo lớp sau

public sealed class Bag<TValue>
{
    public Bag(TValue value, bool hasValue = true)
    {
        HasValue = hasValue;
        Value = value;
    }

    public static Bag<TValue> Empty
    {
        get { return new Bag<TValue>(default(TValue), false); }
    }

    public bool HasValue { get; private set; }
    public TValue Value { get; private set; }
}

để tôi có thể viết mã sau

    public static Bag<XElement> GetXElement(this XElement element, string elementName)
    {
        try
        {
            XElement result = element.Element(elementName);
            return result == null
                       ? Bag<XElement>.Empty
                       : new Bag<XElement>(result);
        }
        catch (Exception)
        {
            return Bag<XElement>.Empty;
        }
    }

Trông giống như nullable nhưng không chỉ cho loại giá trị

Một vi dụ khac

    public static Bag<string> TryParseString(this XElement element, string attributeName)
    {
        Bag<string> attributeResult = GetString(element, attributeName);
        if (attributeResult.HasValue)
        {
            return new Bag<string>(attributeResult.Value);
        }
        return Bag<string>.Empty;
    }

    private static Bag<string> GetString(XElement element, string attributeName)
    {
        try
        {
            string result = element.GetAttribute(attributeName).Value;
            return new Bag<string>(result);
        }
        catch (Exception)
        {
            return Bag<string>.Empty;
        }
    }

Nếu bạn quan tâm đến con đường "giá trị ma thuật", thì một cách khác để giải quyết điều này là làm quá tải mục đích của lớp Lazy. Mặc dù Lazy có ý định trì hoãn việc khởi tạo, nhưng không có gì thực sự ngăn cản bạn sử dụng như Có thể hoặc Tùy chọn. Ví dụ:

    public static Lazy<TValue> GetValue<TValue, TKey>(
        this IDictionary<TKey, TValue> dictionary,
        TKey key)
    {
        TValue retVal;
        if (dictionary.TryGetValue(key, out retVal))
        {
            var retValRef = retVal;
            var lazy = new Lazy<TValue>(() => retValRef);
            retVal = lazy.Value;
            return lazy;
        }

        return new Lazy<TValue>(() => default(TValue));
    }