Hata İşleme Nasıl Yapılır [kapalı]

Birkaç yıldır profesyonel düzeyde programlamış olmama rağmen hala hata işlemeyi tam olarak anlamıyorum. Uygulamalarım iyi çalışmasına rağmen, hata işleme profesyonel düzeyde uygulanmaz ve bir dizi tekniğin karışımı ve eşleşmesidir.

Hata işlememin arkasında bir yapı yok. Profesyonel düzeyde nasıl uygulandığını öğrenmek ve anlamak istiyorum. Bu, bilgim eksik olan bir alandır.

Ne zaman bir istisna kullanmalıyım ve ne zaman mantık akışında kontrol edilecek bir başarı durumu döndürmeliyim? İstisna ve durum döndürmeyi karıştırmak uygun mudur?

Ben esas olarak C # kod.

1. İstisnai şeyler, çok sık karşılaşmayı bekleyemeyeceğiniz şeyler, bir şeyin yanlış gittiğini gösteren şeyler için istisnalar kullanın. Örneğin, ağ kapalıysa, bir web sunucusu için olağanüstü bir şeydir. Veritabanı kullanılamıyorsa, bir şeylerin yanlış olduğu anlamına gelir. Yapılandırma dosyası eksikse, muhtemelen kullanıcının dosyaya bulaştığı anlamına gelir.

2. Yanlış kodu işlemek için istisnalar kullanmayın. Kodun doğruluğunu kontrol etmek için ya onaylamaları kullanmalısınız ya da .NET Framework 4 ve sonraki sürümlerinde Kod sözleşmeleri (iddiaların yerini alan ve ek, özellikle değerli özelliklere sahip).

3. İstisnai olmayan durumlarda istisna kullanmayın. Kullanıcının bir sayı girmesi istendiğinde, "köpek" girmesi bir istisnayı hak edecek kadar istisnai değildir.

4. İstisna türlerini seçerken dikkatli olun. Gerektiğinde kendi tiplerinizi oluşturun. Ebeveynleri yakalamanın çocukları da yakalayacağını akılda tutarak kalıtımı dikkatlice seçin. Asla throw Exception.

5. Hatalar için dönüş kodlarını kullanmayın. Hata kodları kolayca maskelenir, yoksayılır, unutulur. Bir hata varsa, ya onu tutun ya da üst yığına geçirin.

6. Bir yöntemin bir hata döndürmesi beklenen ve hatanın istisnai olmadığı durumlarda, numaralandırmaları kullanın, asla hata numaralarını kullanmayın. Misal:

   // Note that the operation fails pretty often, since it deals with the servers which are
   // frequently unavailable, and the ones which send garbage instead of the actual data.
   private LoadOperationResult LoadProductsFromWeb()
   {
       ...
   }
   

   Anlamı LoadOperationResult.ServerUnavailable, LoadOperationResult.ParsingErrorveri ayrıştırılamaz olduğunu - vs. o kod sunucusu kapalı olduğunu 12 aracı ve kod 13 hatırlayarak, demek, çok daha açık olduğunu.

7. Belirli bir alanda çalışan her geliştirici tarafından bilinen yaygın kodlara başvururken hata kodlarını kullanın. Örneğin, HTTP 404 Bulunamadı veya HTTP 500 Dahili Sunucu Hatası için bir enum değeri yeniden yaratmayın.

8. Boolelara dikkat edin. Er ya da geç, sadece belirli bir yöntemin başarılı olup olmadığını değil, nedenini bilmek isteyeceksiniz. İstisnalar ve sıralamalar bunun için çok daha güçlüdür.

9. Her istisnayı yakalamayın (yığının en üstünde değilseniz). Bir istisna yakalarsanız, bunu ele almaya hazır olmalısınız. Her şeyi yakalamak, kodunuzun doğru çalışıp çalışmadığını umursamadığınızı gösterir. Bu, "Şu anda nasıl düzeltileceğini aramak istemiyorum" u çözebilir, ancak er ya da geç size zarar verir.

10. C # 'da, böyle istisnaları asla tekrar etmeyin:

    catch (SomeException ex)
    {
        ...
        throw ex;
    }
    

    çünkü yığını kırıyorsun. Bunun yerine şunu yapın:

    catch (SomeException)
    {
        ...
        throw;
    }
    

11. İstisna mesajları yazarken çaba gösterin. Kaç kere throw Exception("wrong data")ya da gibi bir şey gördüm throw Exception("shouldn't call this method in this context"). Altı ay sonra kendiniz de dahil olmak üzere diğer geliştiriciler, hangi verilerin yanlış olduğunu ve neden veya neden bir bağlamda bir yöntem dememeliyiz veya tam olarak hangi bağlamı bilmememiz gerektiğini bilemezler.

12. İstisna mesajlarını kullanıcıya gösterme. Sıradan insanlar için beklenmezler ve genellikle geliştiricilerin kendileri için bile okunamazlar.

13. İstisna mesajlarını yerelleştirmeyin. Yerelleştirilmiş bir iletinin belgelerinde arama yorucu ve anlamsızdır: her iletinin yalnızca İngilizce ve İngilizce olması gerekir.

14. Sadece istisnalara ve hatalara odaklanmayın: kayıtlar da son derece önemlidir.

15. .NET'te, yöntemin XML belgelerine istisnalar eklemeyi unutmayın:

    /// <exception cref="MyException">Description of the exception</exception>

    XML belgelerine istisnalar eklemek, kitaplığı kullanan kişi için işleri çok daha kolaylaştırır. Hangi istisnanın bir yöntemle ve neden atılabileceğini tahmin etmeye çalışmaktan daha can sıkıcı bir şey yoktur.

    Bu anlamda, Java istisna yönetimi daha katı ve daha iyi bir yaklaşım sağlar. Sizi, çağrılan yöntemlerle potansiyel olarak atılan istisnalarla uğraşmaya zorlar veya kendi yönteminizde, işlemediğiniz istisnaları atabileceğini ve özellikle şeffaf hale getireceğini beyan eder.

^{¹ Bununla birlikte, dilin istisnaları kontrol ettiği ve kontrol etmediği göz önüne alındığında, istisnalar ve hatalar arasındaki Java ayrımını oldukça yararsız ve kafa karıştırıcı buluyorum. Neyse ki, .NET Framework'te yalnızca istisnalar vardır ve hata yoktur.}

Sanırım MainMa'nın listesi çok eksiksiz. Sadece birkaç tanesini ekleyeceğim:

1. Eric Lippert'in istisnaları nasıl sınıflandırdığına dair makalesini okuyun . Özellikle önemli olan, gerçekte kodunuzdaki hatalar olan istisnaları yakalamamasıdır. Bunun yerine kodu düzeltin!
2. Bir istisnanın meydana gelebileceğini biliyorsanız VE bu konuda bir şeyler yapabilirsiniz, halledin, ancak deneme-yakalama kapsamınızı sınırlandırın ve beklediğiniz özel istisnayı yakalayın. Yani, bunu yapma:

public void Foo() {
    try {
        //get input from use
        //do calculations
        //open file
    }
    catch (Exception ex) {
       //handle exception
    }
}

Bunun yerine şunu yapın:

public void Foo() {
    //get input from use
    //do calculations
    try {
        //open file
    }
    catch (FileOpenException ex) {
       //handle exception
    }
}

• Kontrol akışı için istisnalar kullanmayın. Örneğin, bir arama iletişim kutusuna ClientNotFoundException oluşturmayın (bu durumda bir istemci bulunamadı, bu durumda istisnai değildir) ve bu durumda arama kodunun "Sonuç bulunamadı" mesajı göstermesini bekleyin.

• İstisnaları yutmayın!

• Bir istisnayı gerçekten ele almanın sadece 3 anlama gelebileceğini unutmayın:

  1. İşlemi tekrar deneyin. Yalnızca sorun geçiciyse geçerlidir.
  2. Bir alternatif deneyin.
  3. Sorun hakkında birini bilgilendirin. Yalnızca bildirim işlem yapılabilir olduğunda geçerlidir, yani kullanıcı bu konuda bir şeyler yapabilir.

  Bu seçeneklerin hiçbiri geçerli değilse, bu istisnayı yakalamamalısınız. Yine de günlüğe kaydetmeli ve sonra işlemi iptal etmeli veya kapatmalısınız. Elbette bu, doğruluğa karşı sağlamlığa ilişkin gereksinimlerinizin ne olduğuna bağlıdır.