İstisnalar - girişler teknik olarak geçerli, ancak karşılanamaz olduğunda belirlenen boş sonuç

Kamuya açıklanması amaçlanan bir kütüphane geliştiriyorum. Nesnelerin kümeleri üzerinde çalışmak için çeşitli yöntemler içerir - kümeleri oluşturmak, incelemek, bölümlemek ve kümeleri yeni biçimlere yansıtmak. İlgili olması durumunda, IEnumerableNuGet paketi olarak piyasaya sürülecek LINQ tarzı uzantıları içeren bir C # sınıfı kütüphanedir .

Bu kütüphanedeki yöntemlerden bazıları tatmin edici olmayan giriş parametreleri verilebilir. Örneğin, birleşik yöntemlerde, bir m öğesi kaynağından oluşturulabilecek tüm n öğesi kümesini üretmek için bir yöntem vardır . Örneğin, set verildiğinde:

1, 2, 3, 4, 5

ve 2 kombinasyonunun istenmesi şunları üretecektir:

1, 2
1, 3
1, 4
vb ...
5, 3
5, 4

Şimdi, 3 maddeden oluşan bir set vermek ve ardından her bir maddeyi yalnızca bir kez kullanabileceğini belirten seçeneği belirlerken, 4 maddeden oluşan bir kombinasyon istemek gibi, yapılamayan bir şeyi istemek açıkça mümkün.

Bu senaryoda, her parametre ayrı ayrı geçerlidir:

• Kaynak koleksiyonu boş değil ve öğe içeriyor
• İstenen kombinasyon boyutu pozitif olmayan sıfır tamsayıdır
• İstenen mod (her öğeyi yalnızca bir kez kullanın) geçerli bir seçimdir

Ancak, birlikte alındığında parametrelerin durumu sorunlara neden olur.

Bu senaryoda, yöntemin bir istisna (örneğin InvalidOperationException) atmasını veya boş bir koleksiyon döndürmesini bekler misiniz ? Her ikisi de benim için geçerli görünüyor:

• Sen kombinasyonlarını üretemez n kümesinden öğeleri m öğeleri nerede n> m sadece bir defa her öğeyi kullanma izni, bu nedenle bu işlem dolayısıyla imkansız varsayılması durumunda InvalidOperationException.
• N> m boş bir set olduğunda , m öğelerinden üretilebilecek n boyut kombinasyonları kümesi; hiçbir kombinasyon üretilemez.

Boş küme argümanı

İlk endişem, bir istisnanın, bilinmeyen büyüklükteki veri kümeleriyle çalışırken yöntemlerin deyimsel LINQ tarzı zincirlemesini önlemesidir. Başka bir deyişle, böyle bir şey yapmak isteyebilirsiniz:

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

Girdi kümeniz değişken boyuttaysa, bu kodun davranışı öngörülemez. Eğer .CombinationsOf()bir özel durum atar someInputSet4'ten daha az öğesi vardır, o zaman bu kod olacak bazen bazı ön denetimi olmadan zamanında başarısız. Yukarıdaki örnekte bu kontrol önemsizdir, ancak daha uzun bir LINQ zincirinin yarısına kadar çağırıyorsanız, bu sıkıcı olabilir. Boş bir küme döndürürse, resulttamamen memnun olabileceğiniz boş olacaktır.

Bir istisna argümanı

İkinci kaygım, boş bir setin geri dönmesinin problemleri gizleyebileceğidir - bu yöntemi bir LINQ zincirinin yarısına kadar çağırıyorsanız ve sessizce boş bir küme döndürürseniz, daha sonra birkaç adımda sorun yaşayabilir veya kendinizle boş Sonuç kümesinde ve giriş kümesinde kesinlikle bir şey olduğu göz önüne alındığında bunun nasıl gerçekleştiği açık olmayabilir.

Ne beklersiniz ve bunun konusundaki argümanınız nedir?

Boş Bir Küme Dön

Boş bir set beklerdim çünkü:

Her sayıyı yalnızca bir kez kullanabildiğimde, 3 kümeden 4 sayı 0 kombinasyon var.

Şüpheniz olduğunda, başka birine sorun.

Örnek fonksiyonunuz Python: 'da çok benziyor itertools.combinations. Nasıl çalıştığını görelim:

>>> 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))
[]

Ve bana çok iyi geliyor. Tekrarlayabileceğim bir sonuç bekliyordum ve bir tane aldım.

Ama apaçık bir şey soracak olsaydın, belli ki:

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

Yani, tüm parametreleriniz doğrulanırsa ancak sonuç boş bir küme, boş bir küme döndürürseniz, bunu yapan sadece siz değilsiniz.

@Bakuriu tarafından yorumlarda belirtildiği gibi, bu aynı zamanda SQLgibi bir sorgu için aynıdır SELECT <columns> FROM <table> WHERE <conditions>. Sürece <columns>, <table>, <conditions>iyi oluşturulmuş ve mevcut isimleridir şekilde yer alır, birbirinizi dışarıda bir dizi şartı inşa edebilirsiniz. Sonuçta ortaya çıkan sorgu, sadece bir atmak yerine hiçbir satır vermeyecek InvalidConditionsError.

Layman'ın terimiyle:

• Bir hata varsa, bir istisna oluşturmalısınız. Bu, hatanın tam olarak nerede olduğunu bilmek için, zincirleme bir çağrı yerine adım adım işlerin yapılmasını içerebilir.
• Hata yoksa ancak sonuçta ortaya çıkan set boşsa, bir istisna yükseltme yapmayın, boş grubu geri getirin. Boş bir set geçerli bir set.

Ewan'ın cevabına katılıyorum ama belirli bir akıl yürütme eklemek istiyorum.

Matematiksel işlemlerle uğraşıyorsunuz, bu yüzden aynı matematiksel tanımlara uymak iyi bir tavsiye olabilir. Matematiksel bir bakış açısından sayısı r bir ve -Görüntüler N -SET (yani nCr ) de tüm r için tanımlandığı gibidir> n> = 0. sıfırdır. Bu nedenle, boş bir kümenin döndürülmesi, matematiksel bir açıdan beklenen durum olacaktır.

İstisna kullanıp kullanmamayı belirlemenin iyi bir yolunu buluyorum, insanların bu işlemde yer aldığını hayal etmektir.

Bir dosyanın içeriğini örnek alarak almak:

1. Lütfen bana dosya içeriğini getir, "değil.

   a. "İşte içeriği: boş bir karakter koleksiyonu"

   b. "Erm, bir sorun var, bu dosya yok. Ne yapacağımı bilmiyorum!"

2. Lütfen bana dosyanın içeriğini getir, "var ancak boş.

   a. "İşte içeriği: boş bir karakter koleksiyonu"

   b. "Erm, bir sorun var, bu dosyada hiçbir şey yok. Ne yapacağımı bilmiyorum!"

Hiç şüphe yok ki, bazıları aynı fikirde olmayacak, ancak çoğu kişi için "Erm, bir sorun var", dosyanın bulunmadığı bir anlam ifade ediyor ve dosya boşken "boş bir karakter koleksiyonu" döndürüyor.

Yani aynı yaklaşımı örneğinize uygulayın:

3. Lütfen bana 4 öğenin tüm kombinasyonlarını ver {1, 2, 3}

   a. Yok, işte boş bir küme.

   b. Bir sorun var, ne yapacağımı bilmiyorum.

Yine, örneğin bir nullöğe kümesi olarak teklif edildiyse "bir sorun var" mantıklı olur , ancak "burada boş bir küme" yukarıdaki talebe makul bir yanıt gibi görünüyor.

Boş bir değer döndürmek bir sorunu gizlerse (örneğin eksik bir dosya, a null), bunun yerine genel bir istisna kullanılmalıdır (seçtiğiniz dil option/maybetürleri desteklemediği sürece bazen daha anlamlı olur). Aksi takdirde, boş bir değerin geri verilmesi büyük olasılıkla maliyeti basitleştirir ve en az şaşkınlık ilkesine daha iyi uyar.

Genel amaçlı bir kütüphane için içgüdüm, son kullanıcının seçmesine izin vermek olacaktır .

Elimizdeki Parse()ve bizim için TryParse()uygun olan gibi , fonksiyondan hangi çıktıya ihtiyacımız olduğuna bağlı olarak kullanabileceğimiz bir seçeneğe sahip olabiliriz. İşlevin tek bir sürümünü seçmek yerine, istisnayı atmak için bir işlev sargısı yazıp bakımını yapmak için daha az zaman harcarsınız.

İşleviniz çağrıldığında verilen argümanları doğrulamanız gerekir. Ve aslına bakarsan, geçersiz argümanlarla nasıl başa çıkılacağını bilmek istiyorsun. Çoklu argümanların birbirine bağlı olması, argümanları doğruladığınız gerçeğini telafi etmemektedir.

Bu nedenle, kullanıcının neyin yanlış gittiğini anlaması için gerekli bilgileri sağlayan ArgumentException için oy kullanırdım.

Örnek olarak, public static TSource ElementAt<TSource>(this IEnumerable<TSource>, Int32)Linq içindeki işlevi kontrol edin . Dizin 0'dan küçük veya daha büyükse ya da kaynaktaki öğelerin sayısına eşitse, bu bir ArgumentOutOfRangeException değerini verir. Böylece indeks arayan tarafından sağlanan numaralandırılabilir açısından doğrulanır.

Aşağıdakilerden birini yapmalısınız (negatif sayıda kombinasyon gibi temel sorunlara sürekli olarak devam etmesine rağmen):

1. Biri girdiler saçma olduğunda diğeri boşa atıldığında boş bir set döndüren iki uygulama sağlayın. Onları aramayı dene CombinationsOfve CombinationsOfWithInputCheck. Ya da ne istersen. Bunu tersine çevirebilirsiniz, böylece giriş kontrolü daha kısa olan isim ve bir tane daha listelenir CombinationsOfAllowInconsistentParameters.

2. Linq yöntemleri için, boş IEnumerableolarak belirttiğiniz öncül tesiste boşa dönün . Ardından, bu Linq yöntemlerini kütüphanenize ekleyin:

   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;
         }
      }
   }
   

   Son olarak, böyle kullanın:

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

   veya bunun gibi:

   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();
   

   Özel yöntemin halka olanlardan farklı olmasının, atma veya aksiyon davranışının, linq zinciri oluşturulduktan bir süre sonra, numaralandırıldığı zaman gerçekleşmesi durumunda ortaya çıkması gerektiğini lütfen unutmayın. Sen istemek doğru atmak.

   Bununla birlikte, elbette, herhangi bir maddenin olup olmadığını belirlemek için en azından ilk maddeyi sayması gerektiğine dikkat edin. Bu çoğunlukla ileride izleyiciler oldukça kolay bir sonuç çıkarma gerçeğiyle hafifletilir düşünüyorum potansiyel bir dezavantajı ThrowIfEmptyyöntem vardır en az bir öğe numaralandırmak için, bu yüzden gerektiğini değil o böyle yaparak şaşırmayın. Ama sen asla bilemezsin. Bunu daha açık hale getirebilirsin ThrowIfEmptyByEnumeratingAndReEmittingFirstItem. Ama bu devasa bir overkill gibi görünüyor.

Bence # 2 oldukça iyi, harika! Şimdi, güç arama kodunda ve bir sonraki kod okuyucusu tam olarak ne yaptığını anlayacak ve beklenmeyen istisnalarla uğraşmak zorunda kalmayacak.

Her iki kullanım durumunun da argümanlarını görebiliyorum - aşağı kod, veri içeren kümeleri beklediğinde istisna harika. Öte yandan, eğer beklenirse boş bir set mükemmeldir.

Bunun bir hata veya kabul edilebilir bir sonuç olması durumunda, arayanın beklentilerine bağlı olduğunu düşünüyorum - bu yüzden seçimi arayana transfer ederim. Belki bir seçenek tanıtmak?

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

Açık bir cevap olup olmadığına karar vermek için iki yaklaşım vardır:

• Önce bir seçenek, sonra diğeri varsayılarak kod yazın. Hangisinin pratikte en iyi olacağını düşünün.

• Parametrelerin kesin olarak doğrulanmasını isteyip istemediğinizi belirtmek için bir "strict" boolean parametresi ekleyin. Örneğin, Java'nın , formatla tam olarak eşleşmeyen girişleri ayrıştırma girişimi için SimpleDateFormatbir setLenientyöntemi vardır . Elbette, varsayılanın ne olduğuna karar vermelisin.

Kendi analizinize dayanarak, boş setin geri dönüşü açıkça doğru gözüküyor - hatta bazı kullanıcıların gerçekten isteyebilecekleri ve bazı kullanımları yasaklayan tuzağa düşmemiş oldukları bir şeyi bile belirlediniz, çünkü onu kullanmak isteyenleri hayal bile edemezsiniz. bu taraftan.

Eğer gerçekten bazı kullanıcıların boşuna olmayan iadeleri zorlamak isteyebileceğini düşünüyorsanız, o zaman herkese zorlamak yerine, bu davranışı istemek için bir yol verin . Örneğin, şunları yapabilirsiniz:

• Hangi eylemi kullanıcı için eylem gerçekleştiriyorsa onu bir yapılandırma seçeneği yapın.
• Kullanıcının isteğe bağlı olarak işleve geçebileceği bir bayrak yap.
• AssertNonemptyZincirlerine koyabilecekleri bir çek sağlayın .
• Biri boş olmayan, diğeri olmayan iki işlev yapın.

Bu gerçekten, kullanıcılarınızın ne beklediğine bağlı. (Biraz ilgisiz) bir örnek için, kodunuz bölme gerçekleştirirse, bir istisna atabilir veya geri döndürebilir Infveya NaNsıfıra bölebilirsiniz. Ne doğru ne de yanlış.

• Infbir Python kütüphanesine geri dönerseniz , insanlar gizleme hataları için size saldırırlar
• bir Matlab kütüphanesinde bir hataya neden olursanız, insanlar verileri eksik değerlerle işlememediğiniz için size saldıracaklardır

Senin durumunda, son kullanıcılar için en az şaşırtıcı olan çözümü seçerdim. Setlerle ilgili bir kütüphane geliştirdiğiniz için, boş bir set, kullanıcılarınızın başa çıkmayı umduğu bir şey gibi gözüküyor, bu yüzden geri dönmek mantıklı bir şey gibi geliyor. Ancak yanılıyor olabilirim: bağlamı, buradaki herkesten daha iyi anlıyorsunuz, bu nedenle, kullanıcılarınızın her zaman boş olmayan sete güvenmelerini beklerseniz, hemen bir istisna atmalısınız.

Kullanıcının seçmesine izin veren çözümler ("katı" bir parametre eklemek gibi) kesin değildir, çünkü orijinal soruyu yeni bir eşdeğerle değiştirirler: "Hangi değer strictvarsayılan olmalıdır?"

(Matematikte), bir küme üzerinde elemanlar seçtiğinizde, hiçbir eleman bulamayacağınız ve dolayısıyla boş bir küme elde edebileceğiniz yaygın bir kavramdır . Tabii bu yoldan gidersen, matematikle tutarlı olmalısın:

Ortak ayar kuralları:

• Set.Foreach (yüklem); // boş kümeler için her zaman true değerini döndürür
• Set.Exists (yüklem); // boş kümeler için her zaman false döndürür

Sorunuz çok ince:

• Fonksiyonunuzun girişinin bir sözleşmeye saygı duyması gerekebilir : Bu durumda herhangi bir geçersiz girişin bir istisna yaratması gerekir, işte bu, fonksiyon normal parametreler altında çalışmıyor.

• İşlev girişinin tam olarak bir küme gibi davranması gerekebileceği ve bu nedenle boş bir küme döndürebilmesi gerektiği olabilir.

Şimdi senin içinde olsam "Set" yoluna giderdim, ama büyük bir "AMA" ile.

"Hipotez yoluyla" sadece kız öğrencilerin olması gereken bir koleksiyonunuz olduğunu varsayalım:

class FemaleClass{

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

Artık koleksiyonunuz artık "saf bir set" değil, çünkü üzerinde bir sözleşmeniz var ve bu nedenle sözleşmenizi bir istisna dışında uygulamanız gerekiyor.

"Set" fonksiyonlarınızı saf bir şekilde kullandığınızda, boş set durumunda istisnalar atmamalısınız, fakat artık "saf set" olmayan koleksiyonlarınız varsa, uygun durumlarda istisnalar atmalısınız .

Her zaman daha doğal ve tutarlı hissettiren şeyleri yapmalısınız: bana göre bir küme kurallar koymaya uymalı, kümeler olmayan şeyler ise doğru şekilde düşünülmüş kurallara sahip olmalıdır.

Senin durumunda yapmak iyi bir fikir gibi görünüyor:

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;
}

Ancak bu gerçekten iyi bir fikir değil, şu anda rastgele anlarda çalışma zamanında meydana gelebilecek geçersiz bir durumumuz var, ancak bu sorunla örtülü olduğundan, onu kaldıramayacağız, istisnayı bazı hizmet yönteminin içinde taşıyabileceğimize emin olabiliriz (bu tam olarak aynı kod, farklı yerlere taşındı), fakat bu yanlış ve temelde yapabileceğiniz en iyi şey , normal kurallara uymak .

Sadece yeni sorgulamalar ekleyerek, linq sorgulama yöntemlerini yazabildiğini göstermek için problemine değmez gibi görünüyor , eğer OP bize etki alanı hakkında daha fazla bilgi verirse, muhtemelen istisnanın gerçekten gerekli olduğu noktayı bulabileceğimize eminim (eğer hiç de, sorunun hiç bir istisna gerektirmemesi mümkündür).