Büyü değeri döndür, istisna fırlat veya başarısızlık durumunda yanlış döndür

Bazen gerçek bir cevabı değil, başarısızlığı istisnai olmayan bir sınıf kütüphanesi için bir yöntem veya özellik yazmak zorunda kalıyorum . Bir şey belirlenemiyor, mevcut değil, bulunamadı, şu anda mümkün değil veya daha fazla veri yok.

C # 4'teki başarısızlığı belirtmek için nispeten istisnai olmayan bir durum için üç olası çözüm olduğunu düşünüyorum :

• başka türlü bir anlamı olmayan bir sihir değeri döndürür ( nullve ve gibi -1);
• bir istisna atmak (örneğin KeyNotFoundException);
• return falseve gerçek dönüş değerini bir outparametrede (örneğin Dictionary<,>.TryGetValue) verin.

Öyleyse sorular şudur: hangi istisnai olmayan durumda bir istisna atayım? Ve eğer atmamalıysam: ne zaman Try*bir outparametresi olan bir yöntem uygulamak için yukarıda belirtilen sihirli bir değer dönüyor ? (Bana göre outparametre kirli görünüyor ve doğru kullanmak için daha fazla iş var.)

Tasarım kurallarını içeren ( Try*yöntemler hakkında hiçbir şey bilmiyorum ), kullanılabilirlik (bunu bir sınıf kütüphanesi için istediğim gibi), BCL ile tutarlılık ve okunabilirlik gibi gerçek cevaplar arıyorum .

.NET Framework Temel Sınıf Kütüphanesinde, üç yöntem de kullanılır:

• aksi halde anlamı olmayan bir sihir değeri döndürmek:
  • Collection<T>.IndexOf -1 döndürür
  • StreamReader.Read -1 döndürür
  • Math.Sqrt NaN döndürür,
  • Hashtable.Item null değerini döndürür;
• bir istisna atmak:
  • Dictionary<,>.Item KeyNotFoundException'ı fırlatır,
  • Double.ParseFormatException'ı atar; veya
• return falseve gerçek dönüş değerini bir outparametrede sağlayın :
  • Dictionary<,>.TryGetValue,
  • Double.TryParse.

HashtableC # 'da jenerik olmadığı zaman yaratıldığı gibi , bunun kullandığı objectve dolayısıyla nullsihirli bir değer olarak geri dönebileceğini unutmayın . Ancak jeneriklerle istisnalar kullanılıyor Dictionary<,>ve başlangıçta yoktu TryGetValue. Görünüşe göre değişim anlayışı.

Açıkçası, Item- TryGetValueve Parse- TryParsedualitenin bir nedeni var, bu yüzden istisnai olmayan başarısızlıklar için istisnalar atmanın C # 4'te yapılmadığını farz ediyorum . Ancak, Try*yöntemler olsa bile, her zaman mevcut Dictionary<,>.Itemdeğildi.

Örneklerinin gerçekten eşdeğer olduğunu sanmıyorum. Davranışları için her biri kendi mantığına sahip üç ayrı grup var.

1. Sihirli değer, "geçerli" bir koşul StreamReader.Readolduğunda veya hiçbir zaman geçerli bir cevap olmayacak kullanımı basit bir değer olduğunda (-1 için IndexOf) iyi bir seçenektir .
2. İşlevin semantiği, arayan kişinin çalışacağından emin olması durumunda istisna atar. Bu durumda mevcut olmayan bir anahtar veya hatalı bir çift format gerçekten istisnai bir durumdur.
3. Bir çık parametresi kullanın ve eğer anlamsal işlem mümkün ise araştırmalıdır.

Verdiğiniz örnekler vaka 2 ve 3 için tamamen açık. Sihir değerleri için, bunun iyi bir tasarım kararı olup olmadığı, her durumda verilemeyeceği söylenebilir.

NaNTarafından döndürülen Math.Sqrtözel bir durumdur - bu kayan nokta standardına uygundur.

API kullanıcısına ne yapmaları gerektiği hakkında iletişim kurmaya çalışıyorsunuz. Bir istisna atarsanız, onları yakalamaya zorlayan hiçbir şey yoktur ve yalnızca belgeyi okumak, tüm olasılıkların ne olduğunu bilmelerini sağlar. Şahsen, belirli bir yöntemin yol açabileceği tüm istisnaları bulmak için dokümantasyona girmeyi yavaş ve sıkıcı buluyorum (intellisense olsa bile, bunları manuel olarak kopyalamak zorundayım).

Büyü değeri, hala belgeleri okumanızı constve değeri çözmek için bazı tablolara başvurmanızı gerektirir. En azından istisnai olmayan bir durum olarak adlandırdığınız şeyin istisna yükü yoktur.

Bu yüzden outparametreler bazen kaşlarını çatmasa da, Try...sözdizimi ile bu yöntemi tercih ederim . Kanonik .NET ve C # sözdizimi. API kullanıcısına, sonucu kullanmadan önce dönüş değerini kontrol etmeleri gerektiğini bildirirsiniz. Ayrıca outhata ayıklamaya yardımcı olan, yararlı bir hata mesajı içeren ikinci bir parametre de ekleyebilirsiniz . Bu yüzden Try...ile outparametre çözümü için oy kullanıyorum .

Başka bir seçenek de, bunu çok daha sıkıcı bulmama rağmen, özel bir "sonuç" nesnesi döndürmek:

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

Sonra fonksiyonunuz doğru görünüyor çünkü sadece giriş parametreleri var ve sadece bir şey döndürüyor. Sadece döndürdüğü tek şey bir çeşit para.

Aslında, eğer böyle bir şeyle karşılaşıyorsanız, Tuple<>.NET 4'te tanıtılan yeni sınıfları kullanabilirsiniz . Şahsen, her alanın anlamının daha az açık olması hoşuma gitmiyor, çünkü veremiyorum. Item1ve Item2faydalı isimler.

Örnekleriniz zaten gösterdiği gibi, bu tür vakaların her biri ayrı ayrı değerlendirilmelidir ve özellikle istisna yönteminiz yeniden kullanılması düşünüldüğünde ve oldukça farklı şekillerde kullanılabiliyorsa "istisnai durumlar" ve "akış kontrolü" arasında belirgin bir gri renk yelpazesi vardır. aslında için tasarlandığından daha. Hepimizin burada, "istisnai olmayan" ın ne anlama geldiğine karar vermesini beklemeyin, özellikle bunu uygulamak için "istisnalar" kullanma ihtimalini hemen tartışırsanız.

Ayrıca, hangi tasarımın kodu okumayı ve sürdürmeyi en kolay hale getirdiği konusunda hemfikir olmayabiliriz, ancak kütüphane tasarımcısının bununla ilgili net bir vizyonu olduğunu ve yalnızca ilgili diğer hususlarla dengelenmesi gerektiğini varsayalım.

Kısa cevap

Oldukça hızlı yöntemler tasarladığınız ve öngörülmeyen yeniden kullanım olasılığını beklediğiniz durumlar dışında, bağırsak hislerinizi takip edin.

Uzun cevap

Gelecekteki her arayan, her iki yönde de istediği gibi hata kodları ve istisnalar arasında serbestçe çeviri yapabilir; bu, iki tasarım yaklaşımını performans, hata ayıklayıcı dostu ve bazı sınırlı birlikte çalışabilirlik bağlamları dışında neredeyse eşdeğer yapar. Bu genellikle performansa kayıyor, bu yüzden buna odaklanalım.

• Genel bir kural olarak, bir istisna atmanın normal getiriden 200 kat daha yavaş olmasını bekleyin (gerçekte, bunun önemli bir farkı vardır).

• Başka bir kural olarak, bir istisna atmak çoğu zaman sihirli değerlerin en küçüğüne kıyasla daha temiz bir koda izin verebilir, çünkü programcıya birden fazla müşteri kodu katmanına doğru ilerlerken hata kodunu başka bir hata koduna çevirmeye güvenmiyorsunuzdur. Tutarlı ve yeterli bir şekilde ele almak için yeterli bağlamın olduğu bir nokta. (Özel durum: nullburada bazı büyü NullReferenceExceptiontürlerinde kendini otomatik olarak çevirme eğilimi nedeniyle tüm büyü türlerine göre daha iyi ücret alma eğilimindedir , genellikle kusurun kaynağına yakındır, ancak her zaman değil. )

Peki ders nedir?

Bir uygulamanın kullanım ömrü boyunca (uygulamanın başlatılması gibi) yalnızca birkaç kez çağrılan bir işlev için, kodu daha temiz ve anlaşılması daha kolay olan bir şey kullanın. Performans kaygı verici olamaz.

Bir fırlatma fonksiyonu için, size daha temiz kod veren her şeyi kullanın. Ardından, bazı profiller yapın (gerekirse) ve ölçümlere veya genel program yapısına bağlı olarak şüphelenilen üst darboğazlar arasındaysa kodları döndürmek için istisnaları değiştirin.

Pahalı tekrar kullanılabilir bir fonksiyon için, size daha temiz kod veren her şeyi kullanın. Temel olarak her zaman bir ağ gezintisine tabi tutmanız veya diskteki bir XML dosyasını ayrıştırmanız gerekirse, bir istisna atmanın ek yükü büyük olasılıkla ihmal edilebilirdir. "İstisnai olmayan bir başarısızlıktan" daha hızlı bir şekilde geri dönmekten ziyade, herhangi bir hatanın ayrıntılarını kaybetmemek, hatta yanlışlıkla bile önemli değildir.

Yalın yeniden kullanılabilir bir fonksiyon daha fazla düşünce gerektirir. İstihdam istisnalar ederek, vardır zorlayarak fonksiyonun gövdesi çok hızlı çalıştırır eğer, onların (birçok) aramaların yarısında istisna göreceksiniz arayanlar üzerinde yavaşlatmak 100 defa böyle bir şey. İstisnalar hala bir tasarım seçeneğidir, ancak bunu karşılayamayan arayanlar için düşük bir genel gider alternatifi sunmanız gerekecektir. Bir örneğe bakalım.

Dictionary<,>.ItemGevşek bir şekilde konuşursak, nulldeğerlerin döndürülmesinden KeyNotFoundException.NET 1.1 ve .NET 2.0 arasında atmaya kadar değişen harika bir örnek listeliyorsunuz (yalnızca Hashtable.Itempratik olarak jenerik olmayan öncüsü olmayı düşünmek istiyorsanız ). Bu "değişimin" nedeni burada ilgisiz değil. Değer türlerinin performans optimizasyonu (daha fazla boks yok) orijinal sihir değerini ( null) bir seçenek haline getirmedi; outparametreler performans maliyetinin sadece küçük bir kısmını geri getirecektir. Bu ikinci performans değerlendirmesi, fırlatma ek yüküne kıyasla tamamen ihmal edilebilirKeyNotFoundException , ancak istisna tasarım burada hala üstündür. Neden?

• ref / out parametreleri sadece "arıza" durumunda değil, her zaman maliyetlerini ortaya çıkarır
• Önemseyen herkes Contains, indeksleyiciyi aramadan önce arayabilir ve bu desen tamamen doğal olarak okunur. Bir geliştirici aramak istiyor ancak aramayı unutuyorsa Contains, hiçbir performans sorunu içeri giremez; KeyNotFoundExceptionfarkedilmek ve düzeltilmek için yeterince yüksek.

Böylesine istisnai olmayan bir durumda başarısızlığı belirtmek için yapılacak en iyi şey nedir ve neden?

Başarısızlığa izin vermemelisin.

Biliyorum, el dalgalı ve idealist ama beni dinle. Tasarım yaparken, başarısızlık modları olmayan bir sürümü tercih etme şansına sahip olduğunuz bazı durumlar vardır. LINQ başarısız olan bir 'FindAll'a sahip olmak yerine, sadece boş bir numaralandırılabilir döndüren bir where cümlesini kullanır. Kullanılmadan önce başlatılması gereken bir nesneye sahip olmak yerine, yapıcının nesneyi başlatmasına izin verin (veya başlatılmadığında algılandığında başlat). Anahtar, tüketici branşındaki başarısızlık dalını kaldırmaktır. Sorun bu, buna odaklanın.

Bunun için bir başka strateji de KeyNotFoundsscenario. 3.0'dan beri çalıştığım hemen hemen her kod tabanında, bu uzantı yöntemine benzer bir şey var:

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

Bunun için gerçek bir başarısızlık modu yok. ConcurrentDictionarybenzer bir GetOrAddyapıya sahiptir.

Bütün bunlar, daima kaçınılmaz olduğu zamanlar olacak. Üçünün de bir yeri var, ama ilk seçeneği tercih ederim. Tüm bunlar null tehlikesiyle karşı karşıya olmasına rağmen, iyi bilinmektedir ve “istisnai olmayan başarısızlık” setini oluşturan “bulunamayan” veya “sonuç uygulanamaz” senaryolarının çoğuna uyar. Özellikle null değeri olan tipler yaparken, “bu başarısız olabilir” in önemi kodda çok açık ve unutulması / sökülmesi zor.

İkinci seçenek, kullanıcı aptalca bir şey yaptığında yeterince iyidir. Size yanlış formatı olan bir dize verir, tarihi 42 Aralık'a ayarlamaya çalışır ... test sırasında kötü kodun tanımlanması ve düzeltilmesi için işlerin hızlı ve çarpıcı şekilde patlamasını istediğiniz bir şeydir.

Son seçenek giderek daha fazla sevmediğim bir seçenek. Out parametreleri zordur ve yöntemlere bakarken, bir şeye odaklanmak ve yan etkileri olmamak gibi en iyi uygulamalardan bazılarını ihlal etme eğilimindedir. Ayrıca, çıkış param genellikle başarı sırasında sadece anlamlıdır. Bununla birlikte, genellikle eşzamanlılık endişeleriyle sınırlanan belirli işlemler veya performans hususları için zorunludur (örneğin, DB'ye ikinci bir gezi yapmak istemediğiniz yerlerde).

Dönüş değeri ve dış param önemsiz değilse, Scott Whitlock'un bir sonuç nesnesiyle ilgili önerisi tercih edilir (Regex'in Matchsınıfı gibi ).

Her zaman bir istisna atmayı tercih et. Başarısız olabilecek tüm fonksiyonlar arasında düzgün bir arayüze sahip ve başarısızlığı mümkün olduğunca gürültülü olarak gösteriyor - çok arzulanan bir özellik.

Not Parseve TryParsegerçekten arıza modları dışında aynı şey değildir. TryParseDeğeri de döndürebilen gerçeği , biraz ortogonal. Örneğin, bazı girişleri doğruladığınız durumu göz önünde bulundurun. Aslında değerin ne olduğu umrunda değil, geçerli olduğu sürece. Ve bir çeşit IsValidFor(arguments)işlev sunmanın yanlış bir yanı yok . Ancak asla birincil operasyon modu olamaz .

Diğerlerinin de belirttiği gibi, sihirli değer (bir boolean dönüş değeri dahil), bir "aralık sonu" işareti dışında o kadar da iyi bir çözüm değildir. Sebep: Nesnenin yöntemlerini inceleseniz bile anlambilim açık değildir. Aslında tüm nesnenin tam dokümantasyonunu "ah evet, -42, bla bla bla" anlamına gelirse) aşağıya doğru okumak zorundasınız.

Bu çözüm tarihsel nedenlerden dolayı veya performans nedenleriyle kullanılabilir, ancak başka şekilde kaçınılması gerekir.

Bu iki genel durum bırakır: Sondalama veya istisnalar.

Buradaki temel kural, programın / istemeden / bir koşulu ihlal ettiği zaman işlenmesi dışında istisnalara tepki vermemesi gerektiğidir. Bunun olmamasını sağlamak için sondaj kullanılmalıdır. Bu nedenle, bir istisna ya ilgili araştırmanın önceden gerçekleştirilmediği ya da tamamen beklenmeyen bir şey olduğu anlamına gelir.

Örnek:

Belirli bir yoldan bir dosya oluşturmak istiyorsunuz.

Bu yolun dosya oluşturma veya yazma için yasal olup olmadığını önceden değerlendirmek için File nesnesini kullanmalısınız.

Programınız bir şekilde yasadışı veya başka bir şekilde yazılabilir olmayan bir yola yazmaya çalışıyorsa, bir istisna almalısınız. Bu durum bir yarış durumu nedeniyle olabilir (bazı kullanıcılar bu dizini kaldırdıktan sonra dizini kaldırdılar veya salt okunur hale getirdiler)

Beklenmeyen bir arızanın ele alınması (bir istisna ile bildirilir) ve işlemlerin önceden işlem için uygun olup olmadığının kontrol edilmesi (problama) genellikle farklı şekilde yapılandırılır ve bu nedenle farklı mekanizmalar kullanmalıdır.

TryKod sadece ne olduğunu gösterdiğinde , modelin en iyi seçim olduğunu düşünüyorum . Paramdan nefret ediyorum ve null olabilecek nesne gibi. Aşağıdaki sınıfı oluşturdum

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

bu yüzden aşağıdaki kodu yazabilirim

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

Null'a benziyor ama sadece değer türüne göre değil

Başka bir örnek

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

Eğer "sihirli değer" rotasıyla ilgileniyorsanız, bunu çözmenin bir başka yolu da Tembel sınıfın amacını aşırı yüklemektir. Tembel örnekleme ertelemek için tasarlanmış olsa da, hiçbir şey bir Belki veya Seçenek gibi kullanmanıza engel olamaz. Örneğin:

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