Acıyan istisnalar atmamak nasıl?

Eric Lippert'in istisnalar hakkındaki makalesini okumak , hem üretici hem de tüketici olarak istisnalara nasıl yaklaşmam gerektiği konusunda kesinlikle bir göz açıcıydı. Bununla birlikte, hala rahatsız edici istisnalar atmamaktan kaçınmak için bir kılavuz tanımlamakta zorlanıyorum.

özellikle:

• Başarısız olabilecek bir Kaydet yöntemine sahip olduğunuzu varsayalım, çünkü a) Başkası kaydı sizden önce değiştirdi veya b) Oluşturmaya çalıştığınız değer zaten var . Bu şartlar beklenir ve istisnai değildir, bu nedenle bir istisna atmak yerine, kaydetmenin başarılı olup olmadığını belirten bir boolean döndüren yönteminizin TrySave sürümünü deneyin. Ancak başarısız olursa, tüketici sorunun ne olduğunu nasıl bilecek? Yoksa sonucu belirten bir numara döndürmek en iyisidir, ne tür bir Ok / RecordAlreadyModified / ValueAlreadyExists? İnteger.TryParse ile bu problem mevcut değildir, çünkü yöntemin başarısız olmasının tek bir nedeni vardır.
• Önceki örnek gerçekten sinir bozucu bir durum mu? Yoksa bu durumda bir istisna atmak tercih edilen yol olabilir mi? Entity çerçevesi de dahil olmak üzere çoğu kütüphanede ve çerçevede böyle yapıldığını biliyorum.
• Yöntemin çalışıp çalışmadığını önceden test etmek için bir yöntem sağlayarak, yönteminizin bir Dene sürümünü ne zaman oluşturacağınıza nasıl karar verirsiniz? Şu anda bu yönergeleri takip ediyorum:
  • Bir yarış koşulu olasılığı varsa, bir Dene sürümü oluşturun. Bu, tüketicinin dışsal bir istisna yakalama ihtiyacını önler. Örneğin, daha önce açıklanan Kaydet yönteminde.
  • Durumu test etme yöntemi, orijinal yöntemin yaptığı her şeyi yaparsa, bir Try sürümü oluşturun. Örneğin, integer.TryParse ().
  • Başka bir durumda, durumu test etmek için bir yöntem oluşturun.

Başarısız olabilecek bir Kaydet yöntemine sahip olduğunuzu varsayalım, çünkü a) Biri daha önce kaydı değiştirdi veya b) Oluşturmaya çalıştığınız değer zaten var. Bu şartlar beklenir ve istisnai değildir, bu nedenle bir istisna atmak yerine, kaydetmenin başarılı olup olmadığını belirten bir boolean döndüren yönteminizin TrySave sürümünü deneyin. Ancak başarısız olursa, tüketici sorunun ne olduğunu nasıl bilecek?

İyi soru.

Aklıma gelen ilk soru şudur: eğer veriler zaten oradaysa, kaydetme hangi anlamda başarısız oldu ? Bana başarılı oldu gibi geliyor eminim. Fakat argüman uğruna, bir operasyonun neden başarısız olabileceğine dair birçok farklı nedeninizin olduğunu varsayalım.

Aklıma gelen ikinci soru şudur: Kullanıcıya geri dönmek istediğiniz bilgiler uygulanabilir mi? Yani, bu bilgilere dayanarak bir karar verecekler mi?

"Motor kontrol edin" ışığı yandığında, kaputu açarım, arabamda yanmayan bir motor olduğunu doğrulayın ve garaja götürün. Elbette garajda, kontrol motoru ışığının neden yandığını söyleyen her türlü özel amaçlı teşhis ekipmanına sahipler, ancak benim görüşüme göre , uyarı sistemi iyi tasarlanmış. Sorunun, oksijen sensörünün yanma odasında anormal bir oksijen seviyesi kaydetmesi nedeniyle veya rölanti devri dedektörü fişinin çekilmemiş olması veya herhangi bir şekilde olması nedeniyle umurumda değil. Aynı işlemi yapacağım, başka birisinin bunu çözmesine izin vereceğim .

Arayan kişi tasarrufun neden başarısız olduğunu önemsiyor mu? Bu konuda vazgeçmek ya da tekrar denemek dışında bir şey yapacaklar mı?

Argüman uğruna, işlemin başarısız olmasının nedenine bağlı olarak arayanın gerçekten farklı işlemler yapacağını varsayalım.

Akla gelen üçüncü soru şudur: başarısızlık modu istisnai midir? Sana kafa karıştırıcı olabileceğini düşünüyorum mümkün olan sakatlıklar . İki kullanıcının aynı kaydı, aynı anda olağan bir durum değil, istisnai ama mümkün bir durumla değiştirmeye çalıştığını düşünürdüm.

Tartışması uğruna istisnasız olduğunu varsayalım.

Akla gelen dördüncü soru şudur: Önümüzdeki kötü durumu güvenilir bir şekilde saptamanın bir yolu var mı?

Kötü durum benim "dışsal" kovamdaysa, hayır. "Başka bir kullanıcı bu kaydı değiştirdi mi?" Demenin güvenilir bir yolu yok. çünkü siz soruyu sorduktan sonra değiştirebilirler . Cevap üretilir üretilmez bayat .

Akla gelen beşinci soru şudur: API'yi kötü durumun önlenmesi için tasarlamanın bir yolu var mı?

Örneğin, "kaydet" işleminin iki adım gerektirmesini sağlayabilirsiniz. Birinci adım: değiştirilmekte olan kayıtta bir kilit elde edin. Bu işlem başarılı veya başarısız olur ve bir Boole döndürür. Arayan daha sonra başarısızlıkla nasıl başa çıkılacağına dair bir politika izleyebilir: bir süre bekleyin ve tekrar deneyin, vazgeçmeyin, ne olursa olsun. İkinci adım: kilit alındıktan sonra, kaydetme işlemini yapın ve kilidi açın. Artık tasarruf her zaman başarılı oluyor ve bu nedenle herhangi bir hata işleme konusunda endişelenmenize gerek yok. Eğer kaydetme başarısız olursa, bu gerçekten istisnai bir durumdur.

ValueAlreadyExists durum kolayca kontrol edilebilir eğer örnekte, bu olmalıdır kontrol edilmeli ve bir istisna Kaydet denemeden önce yükseltilmiş olması, bir deneyin bu durumda gerekli olmalıdır sanmıyorum. Yarış koşulunun vaktinden önce kontrol edilmesi daha zordur, bu yüzden bu durumda Kaydetmeyi Deneyin, muhtemelen çok iyi bir fikirdir.

Genel olarak, çok muhtemel olduğunu düşündüğüm bir durum varsa (örneğin NoDataReturned, DivideByZero, vb.) VEYA kontrol etmesi çok kolaydır (boş bir koleksiyon veya NULL değeri gibi), kontrol etmeye çalışıyorum Bir istisna yakalamak zorunda olduğum noktaya gelmeden önce vaktinden önce uğraşır ve onunla ilgilenirim. Kabul ediyorum ki, bu koşulları önceden bilmek her zaman kolay değildir, bazen kod yalnızca zorlu testler altındayken ortaya çıkarlar.

save()Yöntemi bir özel durum olmalıdır.

En üstteki katman , Unix benzeri bir komut satırı programları olmadıkça, programı sonlandırmadan , kullanıcıyı sonlandırmalı ve bilgilendirmelidir; bu durumda sonlandırılması uygundur.

İade değerleri istisnaları yönetmek için iyi bir yol değildir.