Ngoại lệ so với kết quả trống được đặt khi đầu vào hợp lệ về mặt kỹ thuật, nhưng không thỏa mãn

Tôi đang phát triển một thư viện dành cho phát hành công khai. Nó chứa các phương thức khác nhau để vận hành trên các bộ đối tượng - tạo, kiểm tra, phân vùng và chiếu các bộ thành các biểu mẫu mới. Trong trường hợp có liên quan, đó là thư viện lớp C # có chứa các tiện ích mở rộng kiểu LINQ IEnumerable, sẽ được phát hành dưới dạng gói NuGet.

Một số phương thức trong thư viện này có thể được cung cấp các tham số đầu vào không thỏa mãn. Ví dụ, trong các phương thức tổ hợp, có một phương thức để tạo ra tất cả các bộ n mục có thể được xây dựng từ một tập hợp nguồn của các mục m . Ví dụ: đưa ra tập hợp:

1, 2, 3, 4, 5

và yêu cầu kết hợp 2 sẽ tạo ra:

1, 2
1, 3
1, 4
v.v ...
5, 3
5, 4

Bây giờ, rõ ràng có thể yêu cầu những thứ không thể thực hiện được, như đưa cho nó một bộ 3 vật phẩm và sau đó yêu cầu kết hợp 4 vật phẩm trong khi đặt tùy chọn cho biết nó chỉ có thể sử dụng mỗi vật phẩm một lần.

Trong trường hợp này, mỗi tham số là hợp lệ riêng :

• Bộ sưu tập nguồn không phải là null và không chứa các mục
• Kích thước được yêu cầu của các kết hợp là một số nguyên khác không dương
• Chế độ được yêu cầu (chỉ sử dụng mỗi mục một lần) là một lựa chọn hợp lệ

Tuy nhiên, trạng thái của các tham số khi được thực hiện cùng nhau gây ra vấn đề.

Trong kịch bản này, bạn có muốn phương thức đưa ra một ngoại lệ (ví dụ InvalidOperationException:) hoặc trả về một bộ sưu tập trống không? Hoặc có vẻ hợp lệ với tôi:

• Do đó, bạn không thể tạo kết hợp n mục từ một nhóm m trong đó n> m nếu bạn chỉ được phép sử dụng mỗi mục một lần, do đó thao tác này có thể được coi là không thể, do đó InvalidOperationException.
• Tập hợp các kết hợp có kích thước n có thể được tạo từ các mục m khi n> m là một tập hợp trống; không có kết hợp có thể được sản xuất.

Đối số cho một tập hợp trống

Mối quan tâm đầu tiên của tôi là một ngoại lệ ngăn chặn các chuỗi phương thức theo kiểu LINQ khi bạn xử lý các bộ dữ liệu có thể có kích thước không xác định. Nói cách khác, bạn có thể muốn làm một cái gì đó như thế này:

var result = someInputSet
    .CombinationsOf(4, CombinationsGenerationMode.Distinct)
    .Select(combo => /* do some operation to a combination */)
    .ToList();

Nếu bộ đầu vào của bạn có kích thước thay đổi, hành vi của mã này là không thể đoán trước. Nếu .CombinationsOf()ném một ngoại lệ khi someInputSetcó ít hơn 4 phần tử, thì mã này đôi khi sẽ thất bại khi chạy mà không có một số kiểm tra trước. Trong ví dụ trên, việc kiểm tra này là không quan trọng, nhưng nếu bạn gọi nó là một nửa chuỗi LINQ dài hơn thì điều này có thể trở nên tẻ nhạt. Nếu nó trả về một tập hợp trống, thì nó resultsẽ trống, mà bạn có thể hoàn toàn hài lòng.

Đối số cho một ngoại lệ

Mối quan tâm thứ hai của tôi là việc trả lại một tập hợp trống có thể ẩn các vấn đề - nếu bạn đang gọi phương thức này ở giữa một chuỗi LINQ và nó lặng lẽ trả về một tập hợp trống, sau đó bạn có thể gặp phải các vấn đề sau đó hoặc thấy mình bị trống tập kết quả, và có thể không rõ ràng điều đó đã xảy ra như thế nào khi bạn chắc chắn có thứ gì đó trong bộ đầu vào.

Bạn mong đợi điều gì, và lý lẽ của bạn cho nó là gì?

Trả lại một tập hợp trống

Tôi sẽ mong đợi một bộ trống vì:

Có 0 kết hợp 4 số từ bộ 3 khi tôi chỉ có thể sử dụng mỗi số một lần

Khi nghi ngờ, hãy hỏi người khác.

Hàm ví dụ của bạn có một hàm rất giống trong Python : itertools.combinations. Hãy xem cách nó hoạt động:

>>> import itertools
>>> input = [1, 2, 3, 4, 5]
>>> list(itertools.combinations(input, 2))
[(1, 2), (1, 3), (1, 4), (1, 5), (2, 3), (2, 4), (2, 5), (3, 4), (3, 5), (4, 5)]
>>> list(itertools.combinations(input, 5))
[(1, 2, 3, 4, 5)]
>>> list(itertools.combinations(input, 6))
[]

Và nó cảm thấy hoàn toàn tốt với tôi. Tôi đã mong đợi một kết quả mà tôi có thể lặp đi lặp lại và tôi đã có một kết quả.

Nhưng, rõ ràng, nếu bạn định hỏi điều gì đó ngu ngốc:

>>> list(itertools.combinations(input, -1))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: r must be non-negative

Vì vậy, tôi muốn nói, nếu tất cả các tham số của bạn xác thực nhưng kết quả là một tập hợp trống trả về một tập hợp trống, bạn không phải là người duy nhất làm điều đó.

Như @Bakuriu đã nói trong các bình luận, điều này cũng tương tự đối với một SQLtruy vấn như thế nào SELECT <columns> FROM <table> WHERE <conditions>. Chừng nào <columns>, <table>, <conditions>cũng được lập được hình thành và tham khảo tên hiện tại, bạn có thể xây dựng một tập hợp các điều kiện loại trừ lẫn nhau. Truy vấn kết quả sẽ không mang lại hàng nào thay vì ném một InvalidConditionsError.

Trong điều khoản của Giáo dân:

• Nếu có lỗi, bạn nên đưa ra một ngoại lệ. Điều đó có thể liên quan đến việc thực hiện mọi thứ theo các bước thay vì trong một cuộc gọi bị xiềng xích để biết chính xác lỗi xảy ra ở đâu.
• Nếu không có lỗi nhưng tập kết quả trống, đừng đưa ra ngoại lệ, trả lại tập trống. Một bộ trống là một bộ hợp lệ.

Tôi đồng ý với câu trả lời của Ewan nhưng muốn thêm một lý do cụ thể.

Bạn đang xử lý các hoạt động toán học, vì vậy nó có thể là một lời khuyên tốt để gắn bó với các định nghĩa toán học tương tự. Từ quan điểm toán học, số lượng r -sets của n -set (tức là nCr ) được xác định rõ cho tất cả r> n> = 0. Nó bằng không. Do đó, trả về một tập hợp trống sẽ là trường hợp dự kiến ​​từ quan điểm toán học.

Tôi tìm thấy một cách tốt để xác định có nên sử dụng ngoại lệ hay không, là tưởng tượng mọi người tham gia vào giao dịch.

Lấy nội dung của tệp làm ví dụ:

1. Vui lòng tải cho tôi nội dung của tệp, "không tồn tại"

   a. "Đây là nội dung: một bộ sưu tập các ký tự trống"

   b. "Erm, có một vấn đề, tập tin đó không tồn tại. Tôi không biết phải làm gì!"

2. Vui lòng tìm nạp cho tôi nội dung của tệp, "tồn tại nhưng là void.txt"

   a. "Đây là nội dung: một bộ sưu tập các ký tự trống"

   b. "Erm, có một vấn đề, không có gì trong tập tin này. Tôi không biết phải làm gì!"

Chắc chắn một số người sẽ không đồng ý, nhưng với hầu hết dân gian, "Erm, có một vấn đề" có ý nghĩa khi tệp không tồn tại và trả về "một bộ sưu tập ký tự trống" khi tệp trống.

Vì vậy, áp dụng cách tiếp cận tương tự với ví dụ của bạn:

3. Xin vui lòng cho tôi tất cả sự kết hợp của 4 mục cho {1, 2, 3}

   a. Không có, đây là một bộ trống.

   b. Có một vấn đề, tôi không biết phải làm gì.

Một lần nữa, "Có một vấn đề" sẽ có ý nghĩa nếu ví dụ nullđược cung cấp dưới dạng tập hợp các mục, nhưng "đây là một tập hợp trống" có vẻ như là một phản ứng hợp lý cho yêu cầu trên.

Nếu trả về giá trị trống sẽ che giấu một vấn đề (ví dụ: tệp bị thiếu, a null), thì thường nên sử dụng ngoại lệ (trừ khi ngôn ngữ bạn chọn hỗ trợ option/maybecác loại, đôi khi chúng có ý nghĩa hơn). Mặt khác, trả về một giá trị trống sẽ có khả năng đơn giản hóa chi phí và tuân thủ tốt hơn với nguyên tắc ít gây ngạc nhiên nhất.

Vì nó là một thư viện cho mục đích chung, bản năng của tôi sẽ là cho phép người dùng cuối chọn.

Giống như chúng ta có Parse()và TryParse()có sẵn cho chúng ta, chúng ta có thể có tùy chọn mà chúng ta sử dụng tùy thuộc vào đầu ra mà chúng ta cần từ hàm. Bạn sẽ dành ít thời gian hơn để viết và duy trì trình bao bọc hàm để ném ngoại lệ hơn là tranh cãi về việc chọn một phiên bản duy nhất của hàm.

Bạn cần xác thực các đối số được cung cấp khi hàm của bạn được gọi. Và như một vấn đề thực tế, bạn muốn biết cách xử lý các đối số không hợp lệ. Thực tế là nhiều đối số phụ thuộc lẫn nhau, không bù đắp cho thực tế là bạn xác thực các đối số.

Do đó, tôi sẽ bỏ phiếu cho ArgumentException cung cấp thông tin cần thiết cho người dùng để hiểu những gì đã sai.

Ví dụ, kiểm tra public static TSource ElementAt<TSource>(this IEnumerable<TSource>, Int32)chức năng trong Linq. Việc ném một ArgumentOutOfRangeException nếu chỉ số nhỏ hơn 0 hoặc lớn hơn hoặc bằng số lượng phần tử trong nguồn. Do đó, chỉ số được xác nhận liên quan đến số lượng được cung cấp bởi người gọi.

Bạn nên thực hiện một trong những điều sau đây (mặc dù tiếp tục liên tục đưa ra các vấn đề cơ bản như số lượng kết hợp âm):

1. Cung cấp hai triển khai, một triển khai trả về một tập hợp trống khi các đầu vào cùng nhau là vô nghĩa và một thực hiện ném. Hãy thử gọi cho họ CombinationsOfvà CombinationsOfWithInputCheck. Hoặc bất cứ điều gì bạn thích. Bạn có thể đảo ngược điều này để cái kiểm tra đầu vào là tên ngắn hơn và danh sách là CombinationsOfAllowInconsistentParameters.

2. Đối với các phương thức Linq, trả lại khoảng trống IEnumerabletrên tiền đề chính xác mà bạn đã vạch ra. Sau đó, thêm các phương thức Linq này vào thư viện của bạn:

   public static class EnumerableExtensions {
      public static IEnumerable<T> ThrowIfEmpty<T>(this IEnumerable<T> input) {
         return input.IfEmpty<T>(() => {
            throw new InvalidOperationException("An enumerable was unexpectedly empty");
         });
      }
   
      public static IEnumerable<T> IfEmpty<T>(
         this IEnumerable<T> input,
         Action callbackIfEmpty
      ) {
         var enumerator = input.GetEnumerator();
         if (!enumerator.MoveNext()) {
            // Safe because if this throws, we'll never run the return statement below
            callbackIfEmpty();
         }
         return EnumeratePrimedEnumerator(enumerator);
      }
   
      private static IEnumerable<T> EnumeratePrimedEnumerator<T>(
         IEnumerator<T> primedEnumerator
      ) {
         yield return primedEnumerator.Current;
         while (primedEnumerator.MoveNext()) {
            yield return primedEnumerator.Current;
         }
      }
   }

   Cuối cùng, sử dụng như vậy:

   var result = someInputSet
      .CombinationsOf(4, CombinationsGenerationMode.Distinct)
      .ThrowIfEmpty()
      .Select(combo => /* do some operation to a combination */)
      .ToList();

   hoặc như thế này:

   var result = someInputSet
      .CombinationsOf(4, CombinationsGenerationMode.Distinct)
      .IfEmpty(() => _log.Warning(
         $@"Unexpectedly received no results when creating combinations for {
            nameof(someInputSet)}"
      ))
      .Select(combo => /* do some operation to a combination */)
      .ToList();

   Xin lưu ý rằng phương thức riêng khác với phương thức chung là bắt buộc đối với hành vi ném hoặc hành động xảy ra khi chuỗi linq được tạo thay vì một thời gian sau khi được liệt kê. Bạn muốn nó ném ngay lập tức.

   Tuy nhiên, lưu ý rằng tất nhiên nó phải liệt kê ít nhất là mục đầu tiên để xác định xem có mục nào không. Đây là một nhược điểm tiềm năng mà tôi nghĩ là chủ yếu được giảm nhẹ bởi thực tế là bất kỳ người xem tương lai có thể khá dễ dàng suy luận rằng một ThrowIfEmptyphương pháp có liệt kê ít nhất một mục, vì vậy nên không ngạc nhiên bởi nó làm như vậy. Nhưng bạn không bao giờ biết. Bạn có thể làm điều này rõ ràng hơn ThrowIfEmptyByEnumeratingAndReEmittingFirstItem. Nhưng điều đó có vẻ như quá mức cần thiết.

Tôi nghĩ # 2 là khá, tốt, tuyệt vời! Bây giờ sức mạnh nằm trong mã gọi và người đọc mã tiếp theo sẽ hiểu chính xác những gì nó đang làm và sẽ không phải đối phó với các ngoại lệ không mong muốn.

Tôi có thể thấy các đối số cho cả hai trường hợp sử dụng - một ngoại lệ là tuyệt vời nếu mã xuôi dòng mong đợi các tập hợp chứa dữ liệu. Mặt khác, chỉ cần một bộ trống là tuyệt vời nếu điều này được mong đợi.

Tôi nghĩ rằng nó phụ thuộc vào sự mong đợi của người gọi nếu đây là lỗi hoặc kết quả chấp nhận được - vì vậy tôi sẽ chuyển sự lựa chọn cho người gọi. Có thể giới thiệu một lựa chọn?

.CombinationsOf(4, CombinationsGenerationMode.Distinct, Options.AllowEmptySets)

Có hai cách tiếp cận để quyết định nếu không có câu trả lời rõ ràng:

• Viết mã giả sử một tùy chọn đầu tiên, sau đó khác. Xem xét cái nào sẽ làm việc tốt nhất trong thực tế.

• Thêm một tham số boolean "nghiêm ngặt" để cho biết bạn có muốn các tham số được xác minh nghiêm ngặt hay không. Ví dụ: Java SimpleDateFormatcó một setLenientphương pháp để phân tích cú pháp các đầu vào không khớp hoàn toàn với định dạng. Tất nhiên, bạn phải quyết định mặc định là gì.

Dựa trên phân tích của riêng bạn, việc trả lại tập hợp trống dường như rõ ràng đúng - bạn thậm chí đã xác định đó là điều mà một số người dùng thực sự muốn và không rơi vào cái bẫy cấm sử dụng vì bạn không thể tưởng tượng người dùng muốn sử dụng nó theo cách đó

Nếu bạn thực sự cảm thấy rằng một số người dùng có thể muốn buộc trả lại tiền không phải trả tiền, thì hãy cho họ một cách để yêu cầu hành vi đó thay vì ép buộc mọi người. Ví dụ: bạn có thể:

• Làm cho nó trở thành một tùy chọn cấu hình trên bất kỳ đối tượng nào đang thực hiện hành động cho người dùng.
• Làm cho nó trở thành một cờ người dùng có thể tùy ý chuyển vào chức năng.
• Cung cấp một AssertNonemptykiểm tra họ có thể đưa vào chuỗi của họ.
• Thực hiện hai chức năng, một chức năng khẳng định không trống và một chức năng không.

Nó thực sự phụ thuộc vào những gì người dùng của bạn mong đợi nhận được. Đối với ví dụ (hơi không liên quan) nếu mã của bạn thực hiện phép chia, bạn có thể ném ngoại lệ hoặc trả về Infhoặc NaNkhi bạn chia cho số không. Không có đúng hay sai, tuy nhiên:

• nếu bạn quay lại Infthư viện Python, mọi người sẽ tấn công bạn để che giấu lỗi
• nếu bạn gây ra lỗi trong thư viện Matlab, mọi người sẽ tấn công bạn vì không xử lý dữ liệu bị thiếu

Trong trường hợp của bạn, tôi sẽ chọn giải pháp ít gây ngạc nhiên nhất cho người dùng cuối. Vì bạn đang phát triển thư viện xử lý các bộ, một bộ trống có vẻ như là thứ mà người dùng của bạn sẽ xử lý, do đó, việc trả lại nó nghe có vẻ là một việc hợp lý. Nhưng tôi có thể nhầm: bạn hiểu rõ hơn về bối cảnh hơn bất kỳ ai khác ở đây, vì vậy nếu bạn mong muốn người dùng của mình dựa vào bộ luôn không trống, bạn nên ném ngoại lệ ngay lập tức.

Các giải pháp cho phép người dùng chọn (như thêm tham số "nghiêm ngặt") không dứt khoát, vì chúng thay thế câu hỏi ban đầu bằng một câu hỏi tương đương mới: "Giá trị nào strictnên được mặc định?"

Một quan niệm phổ biến (trong toán học) là khi bạn chọn các phần tử trên một tập hợp, bạn không thể tìm thấy phần tử nào và do đó bạn có được một tập hợp trống . Tất nhiên bạn phải phù hợp với toán học nếu bạn đi theo cách này:

Quy tắc thiết lập chung:

• Set.Foreach (vị ngữ); // luôn trả về true cho các tập hợp trống
• Set.Exists (vị ngữ); // luôn trả về false cho các tập hợp trống

Câu hỏi của bạn rất tinh tế:

• Có thể là đầu vào của chức năng của bạn phải tôn trọng hợp đồng : Trong trường hợp đó, bất kỳ đầu vào không hợp lệ nào cũng sẽ đưa ra một ngoại lệ, đó là chức năng không hoạt động theo các tham số thông thường.

• Có thể là đầu vào của hàm của bạn phải hoạt động chính xác như một tập hợp , và do đó sẽ có thể trả về một tập hợp trống.

Bây giờ nếu tôi ở trong bạn, tôi sẽ đi theo con đường "Đặt", nhưng với một "NHƯNG" lớn.

Giả sử bạn có một bộ sưu tập "do thôi miên" chỉ nên có sinh viên nữ:

class FemaleClass{

    FemaleStudent GetAnyFemale(){
        var femaleSet= mySet.Select( x=> x.IsFemale());
        if(femaleSet.IsEmpty())
            throw new Exception("No female students");
        else
            return femaleSet.Any();
    }
}

Bây giờ bộ sưu tập của bạn không còn là "bộ thuần túy", bởi vì bạn có hợp đồng trên đó, và do đó bạn nên thực thi hợp đồng của mình với một ngoại lệ.

Khi bạn sử dụng các chức năng "tập hợp" của mình một cách thuần túy, bạn không nên đưa ra các ngoại lệ trong trường hợp tập hợp trống, nhưng nếu bạn có các bộ sưu tập không còn là "tập hợp thuần túy" thì bạn nên đưa ra các ngoại lệ phù hợp .

Bạn nên luôn luôn làm những gì cảm thấy tự nhiên và nhất quán hơn: với tôi một bộ nên tuân thủ các quy tắc, trong khi những thứ không phải là bộ nên có quy tắc suy nghĩ đúng đắn của chúng.

Trong trường hợp của bạn, có vẻ là một ý tưởng tốt để làm:

List SomeMethod( Set someInputSet){
    var result = someInputSet
        .CombinationsOf(4, CombinationsGenerationMode.Distinct)
        .Select(combo => /* do some operation to a combination */)
        .ToList();

    // the only information here is that set is empty => there are no combinations

    // BEWARE! if 0 here it may be invalid input, but also a empty set
    if(result.Count == 0)  //Add: "&&someInputSet.NotEmpty()"

    // we go a step further, our API require combinations, so
    // this method cannot satisfy the API request, then we throw.
         throw new Exception("you requsted impossible combinations");

    return result;
}

Nhưng nó không thực sự là một ý tưởng hay, hiện tại chúng ta có trạng thái không hợp lệ có thể xảy ra trong thời gian chạy ngẫu nhiên, tuy nhiên đó là vấn đề tiềm ẩn nên chúng ta không thể loại bỏ nó, chắc chắn chúng ta có thể di chuyển ngoại lệ bên trong một số phương thức tiện ích (chính xác là cùng một mã, được di chuyển ở những nơi khác nhau), nhưng điều đó sai và về cơ bản, điều tốt nhất bạn có thể làm là tuân theo các quy tắc được đặt thông thường .

Hoàn toàn thêm độ phức tạp mới chỉ để cho thấy bạn có thể viết các phương thức truy vấn linq dường như không có giá trị cho vấn đề của bạn , tôi khá chắc chắn rằng nếu OP có thể cho chúng tôi biết thêm về miền đó, có lẽ chúng ta có thể tìm thấy vị trí ngoại lệ thực sự cần thiết (nếu tất cả, có thể vấn đề không yêu cầu bất kỳ ngoại lệ nào cả).