Sistem hatalarını ortaya çıkarma / tolere etme / kurtarmaya bir tasarım deseni / yaklaşımı, Özel durum işleme (Java'daki egs, C ++, Perl, PHP) önerme

Sistem hatalarını, Özel Durum işlemeyi (Java, C ++, Perl, PHP) ortaya çıkarmak / tolere etmek / kurtarmak için bir tasarım deseni / yaklaşımı önerebilir misiniz?

Bazı hataların bildirilmesi gerekir.

Bazı hatalar dahili olarak ele alınabilir (yeniden deneme yoluyla veya önemsizdir (yok sayılabilir).

Kodu yakalamak için nasıl yapılandırıyorsunuz?

Ancak tüm hataların günlüğe kaydedilmesi gerekir.

Hangi en iyi uygulamalar var?

Ve onları etkileyen bileşenleri tam olarak test edebilmek için simüle etmek için?

Bazı modern programlama dilleri için geçerli olan programlama diline özgü olmayan genel soru, Java, C ++, PHP ve Perl'deki örnek, yaklaşım ve felsefelerin örnek resimlerini memnuniyetle karşılayacaktır.

(Stackoverflow'da da sordu: /programming/7432596/recommend-a-design-pattern-approach-to-exposing-tolerating-recovering-from-system ama programcılara da sorulması gerektiğini düşündüm çünkü Bence programcılar Soru-Cevap daha geniş yazılım / programlama sorunlarını kapsamakta, oysa yığın akışı daha çok teknik uygulama IMHO ile ilgilidir).

Hızlı başarısız olmak harika bir tasarım yaklaşımıdır ve belki de bir desen olarak sayılabilir: http://en.wikipedia.org/wiki/Fail-fast

Ayrıca yararlı olacak bir dizi ilke buldum:

• Her bir işleve / modüle arayüzün bir parçası olarak istisnaları göz önünde bulundurun - örn. Bunları dokümante edin ve uygun olduğunda / diliniz destekliyorsa, kontrol edilen istisnaları kullanın.
• Bir arızayı asla geçiştirmeyin - başarısız olursa, nasıl devam edileceğini "varsaymaya" çalışarak devam etmeye çalışmayın. Örneğin, null durumlar için özel işlem genellikle bana bir kod kokusudur: yönteminizin null olmayan bir değere ihtiyacı varsa, null ile karşılaşırsa hemen bir istisna atmalıdır (NullPointerException veya ideal olarak daha açıklayıcı bir IllegalArgumentException).
• Olağan dışı durumların yanı sıra normal durumlar için birim testleri yazın - bazen bu tür testler ayarlamak zor olabilir, ancak sisteminizin arızalara karşı sağlam olduğundan emin olmak istediğinizde buna değer
• Hatanın yakalandığı ve işlendiği noktada oturum açın (hatanın günlüğe kaydedilmek için yeterli önem taşıdığı varsayılarak). Bunun nedeni, nedeni anladığınızı ve hatayı işlemek için bir yaklaşıma sahip olduğunuzu ima etmesidir, böylece günlük mesajını anlamlı hale getirebilirsiniz .....
• İstisnaları yalnızca gerçekten beklenmedik koşullar / arızalar için kullanın. İşleviniz gerçekten beklendiği şekilde "başarısız olursa" (örneğin, daha fazla giriş olup olmadığını görmek için yoklama ve hiçbirini bulma), o zaman normal bir yanıt döndürmelidir ("giriş yok"), bir istisna atmayın
• Başarısız bir şekilde başarısız olun (Steven Lowe'ye kredi verin) - mümkünse sonlandırmadan önce, genellikle değişiklikleri çözerek, işlemi geri alarak veya kaynakları "son olarak" ifadesinde veya eşdeğerinde serbest bırakarak temizleyin. Temizlik ideal olarak, netlik ve mantıksal tutarlılık uğruna kaynakların işlendiği düzeyde gerçekleşmelidir.
• Başarısız olmak zorundaysanız, yüksek sesle başarısız olun - kodunuzun hiçbir kısmının işleyemediği bir istisna (yani yakalanmadan + ele alınmadan üst seviyeye süzülen), dikkatinizi ona yönlendiren acil, yüksek ve görünür bir hataya neden olmalıdır. Genellikle programı veya görevi durdurur ve System.out'a tam bir özel durum raporu yazarım.

Java ve .NET'te istisnalarla çalıştıktan sonra ve istisnaları nasıl / ne zaman / neden yakaladığınızla ilgili birçok makale okuduktan sonra , sonunda olası bir istisna olduğunu gördüğümde kafamda attığım aşağıdaki adımları veya bir istisna (Java) yakalamalıyım ... asla olmasa bile (iç ...). Ve en azından benim için çalışıyor gibi görünüyor:

1. Bu istisna dışında yapabileceğim yararlı bir şey var mı (günlük kaydı hariç)? Yanıt evetse, geçici çözüm kodunu yazın ve geçici çözüm özel durumlar oluşturabilirse, 2'ye gidin:
2. İstisnayı bir çalışma zamanı istisnasının etrafına sarın, atın, 3'e gidin.
3. Olası bir veritabanı / işlem işleminin başlatıldığı üst düzey sınıfta, istisnayı yakalayın, işlemi geri alın, istisnayı yeniden oluşturun.
4. Üst düzey sınıfta (işlemin başlatıldığı sınıf olabilir), slf4j ( örneğin log4j ile birleştiğinde ) veya log4net gibi bir günlük çerçevesi kullanarak istisnayı günlüğe kaydedin . Mümkünse, istisnayı doğrudan uygulamanın geliştiricilerinden oluşan bir dağıtım listesine e-postayla gönderin.
5. Bir GUI varsa, soruna neyin neden olduğunu en kullanıcı dostu şekilde gösteren bir hata mesajı görüntüleyin; istisna / yığın izlemesini görüntüleme, kullanıcı umursamıyor ve bir NullPointerException olduğunu bilmesine gerek yok.

Ben de bazı karmaşık tedavi veri hataları nedeniyle yürütülemediğinde bilerek bir "iş" istisna ("istisna" sınıfı genişleterek oluşturduğum yeni bir istisna) dediğim atılan , adım 0 eklemeniz gerekir , AMA analiz sırasında istisna durumları olarak tanımlandıkları bilinmektedir.

Giriş kısmı hariç, "mikera" tarafından yazılan noktalara tamamen katılıyorum; Sadece istisnanın sadece bir kez günlüğe kaydedilmesi gerektiğini ekleyeceğim .

Ayrıca, yazdıklarınız bir API / Framework ise listelediğim adımlar farklı olabilir . Orada, geliştiricilerin hatalarını anlamalarına yardımcı olmak için iyi tasarlanmış istisnalar atmak zorunludur.

İstisnaları test etmek için, sahte nesneleri kullanarak, sınıflarınızın "bir şeyi yapmak için bir sınıf" en iyi uygulamalarına saygı göstermesi koşuluyla, istisna olsun ya da olmasın neredeyse her şeyi test edebilmelisiniz. Ben de şahsen en önemli ama gizli yöntemleri "özel" yerine "korumalı" olarak işaretlediğinizden emin olun, böylece onları çok fazla uğraşmadan test edebiliyorum. Bunun dışında, istisnaları test etmek basittir, sadece istisnayı kışkırtır ve bir istisnayı yakalayarak "bekle". Bir istisna almazsanız, birim test durumu hatasıyla karşılaşırsınız.

Nesnelerinizi doğru şekilde oluşturun, dış faktörler hakkında endişelenmeyin. İstisnalardan yararlanmayı seçerseniz, nesneleriniz bir şeyde başarısız olursa istisnalar atmasını sağlayın .

Tüm nesneleriniz doğru bir şekilde çalıştıktan sonra, tasarımınızda temiz bir hata işleme sorumluluk hiyerarşisi bulmak oldukça kolay olmalıdır.