Hata işlemeyi gerçekleştirmenin modern yolu ...

Bu problemi bir süredir tartışıyorum ve sürekli olarak uyarılar ve çelişkiler bulurken kendimi sürekli buluyorum, bu yüzden birinin aşağıdakilere bir sonuç verebileceğini umuyorum:

Hata kodları üzerindeki istisnaları tercih etme

Bildiğim kadarıyla, dört yıldır sektörde çalışmaktan, kitap okumak, blog okumak, vb. Hataları düzeltmek için en iyi uygulama hata kodlarını döndürmek yerine istisnalar atmaktır (mutlaka bir hata kodu değil, fakat hatayı temsil eden tür).

Ama - Bana göre bu çelişkili görünüyor ...

Arayüzlere kodlama, uygulamalara değil

Birleşmeyi azaltmak için arayüzleri ve soyutlamaları kodlarız Bir arabirimin belirli bir türünü ve uygulamasını bilmiyoruz veya bilmek istiyoruz. Öyleyse, hangi istisnaları yakalamak istediğimizi nasıl bilebiliriz? Uygulama 10 farklı istisna atabilir veya hiçbirini atmayabilir. Kesinlikle bir istisna yakaladığımızda, uygulama hakkında varsayımlarda bulunuyoruz?

Tabi - arayüzde ...

İstisna özellikleri

Bazı diller, geliştiricilerin belirli yöntemlerin belirli istisnalar attığını belirtmelerine izin verir (örneğin, Java throwsanahtar kelimeyi kullanır .) Arama kodunun bakış açısına göre bu iyi görünüyor - hangi istisnaları yakalamamız gerekebileceğini açıkça biliyoruz.

Ancak - bu bir ...

Sızdıran soyutlama

Bir arabirim neden hangi istisnaların atılabileceğini belirtmelidir? Uygulamanın bir istisna atması gerekmiyorsa veya başka istisnalar atması gerekiyorsa? Bir uygulama düzeyinde, bir uygulamanın hangi istisnaları atmak isteyebileceğini bilmek mümkün değildir.

Yani...

Sonuçlandırmak

Yazılımın en iyi uygulamalarıyla çelişiyor gibi göründüğünde (gözlerimin içinde) neden istisnalar tercih ediliyor? Ve eğer hata kodları çok kötüyse (ve hata kodlarından başka birine satılmam gerekmiyor), başka bir alternatif var mı? Yukarıda ana hatları verilen en iyi uygulamaların gerekliliklerini karşılayan, ancak hata kodlarının dönüş değerini kontrol eden kod çağırmaya dayanmayan, hata yönetimi için mevcut durum (veya yakın zamanda) nedir?

Her şeyden önce, bu ifadeye katılmıyorum:

Hata kodları üzerindeki istisnaları tercih etme

Bu her zaman böyle değildir: örneğin, Objective-C'ye bir göz atın (Foundation çerçevesi ile). Burada, bir Java geliştiricisinin gerçek istisnalar olarak adlandırdığı şeyin varlığına rağmen, NSError hataları ele almanın tercih edilen yoludur: @try, @catch, @throw, NSException sınıfı, vb.

Ancak, birçok arayüzün soyutlamaları atılan istisnalarla sızdırdığı doğrudur. Benim inancım, bunun “istisna” tarzında bir hata üretme / kullanma tarzının hatası olmadığıdır. Genel olarak, hata işlemeyle ilgili en iyi tavsiyenin bu olduğuna inanıyorum:

Hata / istisna ile mümkün olan en düşük seviyede işlem yapın.

Sanırım biri bu kurallara sadık kalırsa, soyutlamalardan gelen "sızıntı" miktarı çok sınırlı ve içerilebilir.

Bir yöntem tarafından atılan istisnaların beyannamenin bir parçası olması gerekip gerekmediğine göre, inanıyorum ki: bunlar bu arayüz tarafından tanımlanan sözleşmenin bir parçası : Bu yöntem A yapıyor veya B veya C ile başarısız.

Örneğin, bir sınıf bir XML Ayrıştırıcı ise, tasarımının bir kısmı, sağlanan XML dosyasının tamamen yanlış olduğunu belirtmek olmalıdır. Java’da normalde, karşılaşmayı umduğunuz istisnaları bildirerek ve bunları throwsyöntem bildiriminin bir bölümüne ekleyerek yaparsınız . Öte yandan, ayrıştırma algoritmalarından biri başarısız olursa, bu istisnayı işlenmemiş olanın üstüne çıkarmak için hiçbir neden yoktur.

Hepsi tek bir şeyle kaynar: İyi arayüz tasarımı. Arayüzünüzü yeterince iyi tasarlarsanız, hiçbir istisnalar sizi rahatsız etmemelidir. Aksi takdirde, sadece sizi rahatsız edecek istisnalar değildir.

Ayrıca, Java yaratıcılarının bir yöntem bildirimi / tanımı istisnaları dahil etmek için çok güçlü güvenlik nedenleri olduğunu düşünüyorum.

Sonuncusu: Örneğin bazı diller, Eiffel gibi, hata işleme için başka mekanizmalara sahiptir ve atma yeteneklerini içermez. Orada, bir rutin için bir şart koşulu yerine getirilmediğinde bir "istisna" otomatik olarak ortaya çıkar.

Sadece istisnaların ve hata kodlarının, hatalarla ve alternatif kod yollarıyla baş etmenin tek yolu olmadığını belirtmek isterim.

Aklın tepesinden, Haskell'in aldığı hatalara benzer bir yaklaşıma sahip olabilirsiniz; burada hatalar birden fazla kurucu ile soyut veri türleri (işaretli ayırımlar veya boş işaretçiler, ancak yazı tipi güvencesi ve sözdizimi ekleme olasılığı ile) kod akışının iyi görünmesini sağlamak için şeker veya yardımcı işlevler).

func x = do
    a <- operationThatMightFail 10
    b <- operationThatMightFail 20
    c <- operationThatMightFail 30
    return (a + b + c)

operationThatMightfail, Belki de içine sarılmış bir değer döndüren bir işlevdir. Boş bir işaretçi gibi çalışır, ancak gösterim, a, b veya c'nin herhangi birinin başarısız olması durumunda her şeyin boş olduğunu değerlendirir. (ve derleyici sizi yanlışlıkla NullPointerException yapmaktan korur)

Diğer bir olasılık, bir hata işleyici nesnesini, çağırdığınız her işleve ekstra bir argüman olarak geçirmektir. Bu hata işleyicisi, her bir olası "istisna" için, onu ilettiğiniz işlev tarafından işaretlenebilen ve bu işlev tarafından, istisnalar dışında yığını geri sarmak zorunda kalmadan istisnaları tedavi etmek için kullanılabilecek bir yönteme sahiptir.

Yaygın LISP bunu yapar ve sözdizimi desteğine (örtük argümanlar) dayanarak ve yerleşik işlevlerin bu protokolü izlemesini mümkün kılar.

Evet, istisnalar sızdıran soyutlamalara neden olabilir. Ancak bu konuda hata kodları daha da kötü değil mi?

Bu problemin üstesinden gelmenin bir yolu, arayüzün hangi şartlar altında hangi istisnaların atılabileceğini tam olarak belirlemesini sağlamak ve gerekli olduğunda istisnaları yakalamak, dönüştürmek ve tekrar fırlatmak suretiyle uygulamaların kendi istisna modellerini bu şartnameye eşlemesi gerektiğini beyan etmektir. Bir "kaymakam" arayüzü istiyorsanız, bu şekilde gitmek.

Uygulamada, genellikle arayüzün mantıksal bir parçası olan ve bir müşterinin hakkında bir şeyler yakalamak ve yapmak isteyebileceği istisnalar belirlemek yeterlidir. Genellikle düşük seviyeli hatalar oluştuğunda veya bir hata tezahür ettiğinde ve bir müşterinin yalnızca bir hata mesajı göstererek ve / veya uygulamayı kapatarak yapabileceği başka istisnalar olabileceği anlaşılmaktadır. En azından istisna, sorunu teşhis etmeye yardımcı olan bilgileri hala içerebilir.

Aslında, hata kodları ile hemen hemen aynı şey, sadece daha örtük bir biçimde ve bitmek üzere olan bilgilerin kaybolması ve uygulamanın tutarsız bir durumda sonuçlanmasıyla sonuçlanır.

Burada birçok güzel şey var, sadece normal kontrol akışının bir parçası olarak istisnalar kullanan kodlara karşı dikkatli olmamız gerektiğini eklemek isterim. Bazen insanlar, olağan dava olmayan her şeyin bir istisna haline geldiği tuzağa girerler. Bir döngü sonlandırma koşulu olarak kullanılan bir istisna bile gördüm.

İstisnalar, "burada idare edemeyeceğim bir şey oldu, ne yapılacağını bulmak için başkasına gitmem gerek" anlamına geliyor. Geçersiz giriş yazan bir kullanıcı bir istisna değildir (bu, tekrar sorarak vb. Tarafından yerel olarak ele alınması gerekir).

Gördüğüm bir başka istisnai durum örneği de, ilk yanıtı "istisna atmak" olan insanlar. Bu neredeyse her zaman mandal yazmadan yapılır (temel kural: önce mandalı, sonra throw ifadesini yazın). Büyük uygulamalarda, yakalanmamış bir istisna ağ bölgelerinden toplanıp programı havaya uçurduğunda sorunlu hale gelir.

İstisnalar haricinde değilim, ancak birkaç yıl önceki tekillere benziyorlar: çok sık ve uygunsuz olarak kullanıldılar. Amaçlanan kullanım için mükemmeller, ancak bu dava sanılan kadar geniş değil.

Sızdıran soyutlama

Bir arabirim neden hangi istisnaların atılabileceğini belirtmelidir? Uygulamanın bir istisna atması gerekmiyorsa veya başka istisnalar atması gerekiyorsa? Bir uygulama düzeyinde, bir uygulamanın hangi istisnaları atmak isteyebileceğini bilmek mümkün değildir.

Hayır! İstisna özellikleri, return ve argüman tipleri ile aynı kovadadır - bunlar arayüzün bir parçasıdır. Bu şartnameye uyamıyorsanız, arayüzü uygulamayın. Asla atmazsan, sorun değil. Bir arabirimde istisnalar belirtme konusunda sızan bir şey yok.

Hata kodları kötü değil. Berbatlar. Her arama için her seferinde onları kontrol edip çoğaltmayı elle hatırlamanız gerekir. Bu, bir başlangıç ​​için DRY'yi ihlal eder ve hata işleme kodunuzu büyük ölçüde hızlandırır. Bu tekrarlama, istisnaların karşılaştığından çok daha büyük bir sorundur. Bir istisnayı asla sessizce görmezden gelemezsiniz, ancak insanlar dönüş kodlarını sessizce görmezden gelebilir - kesinlikle kötü bir şey.

İstisna işleme yönetimi kendi arayüz uygulamalarına sahip olabilir. Atılan istisnanın türüne bağlı olarak, istenen adımları uygulayın.

Tasarım probleminizin çözümü iki arayüz / soyutlama uygulamasına sahip olmaktır. Biri işlevsellik, diğeri istisna işlemesi için. İstisna türüne bağlı olarak, uygun istisna tip sınıfını arayın.

Hata kodlarının uygulanması, istisnai durumların ortodoks bir yoludur. String vs. string builder kullanımı gibidir.

IM-very-HO istisnaları duruma göre değerlendirilecektir, çünkü kontrol akışını kırarak kodunuzun gerçek ve algılanan karmaşıklığını artıracak, çoğu durumda gereksiz yere. İşlevlerinize istisnalar atma ile ilgili tartışmayı bir kenara koymak - ki bu aslında çağrı akışını kullanarak istisnalar atmak için kontrol sınırlamanızı artırabilir: Aşağıdakileri göz önünde bulundurun:

Bir callee'nin kontrol akışınızı kırmasına izin vermek herhangi bir gerçek fayda sağlamayabilir ve istisna ile baş etmek için anlamlı bir yol olmayabilir. Direkt bir örnek için, eğer Gözlenebilir bir model uyguluyorsa (her yerde olayların olduğu throwsve tanımda açık olmayan C # gibi bir dilde ), Gözlemcinin çarpması durumunda kontrol akışınızı kırmasına izin vermek için gerçek bir sebep yoktur ve Eşyalarıyla uğraşmanın anlamlı bir yolu yok (elbette, iyi bir komşu gözlem yaparken atmamalı, ama hiç kimse mükemmel değildir).

Yukarıdaki gözlem, gevşek bir şekilde bağlanmış herhangi bir arayüze (belirttiğiniz gibi) genişletilebilir; Aslında 3-6 yığın çerçevesini oluşturduktan sonra, yakalanmamış bir istisnadan birinin ya da kodun bir bölümünde bitmesi muhtemel bir norm olduğunu düşünüyorum:

• istisnanın kendisi kaydedilmiş olsa bile, istisnayı anlamlı bir şekilde ele almak için çok soyut;
• genel bir işlev gerçekleştiriyor (neden bir ileti pompası ya da gözlemlenebilir gibi başarısız olduğunuzu daha az önemsemiyorsunuz);
• belirli, ancak farklı bir sorumlulukla ve gerçekten endişelenmemeli;

Yukarıdakileri göz önüne alarak, throwsanlamsallık ile arayüzleri dekore etmek sadece marjinal bir işlevsel kazanımdır, çünkü arayüz sözleşmeleri yapan birçok arayan, sadece başarısız olmanız durumunda, neden olmasın umurunda olur.

O zaman bunun bir zevk ve rahatlık meselesi haline geldiğini söyleyeceğim: öncelikli odak noktanız, bir “istisna” dan sonra hem arayan hem de arayanda durumunuzu zarif bir şekilde kurtarmaktır; Bir C arka plandan) veya istisnaların kötüye dönebileceği bir ortamda çalışıyorsanız (C ++), etrafınıza bir şeyler atmanın, eski, güvenemeyeceğiniz güzel ve temiz OOP için çok önemli olduğuna inanmıyorum. eğer rahatsız olursanız kalıplar. Özellikle de SoC’yu kırmaya yol açarsa.

Teorik bir bakış açısına göre, bir SoC-koşer istisnaları ele alma yolunun doğrudan doğrudan arayanın çoğu zaman neden başarısız olduğunuzu umursamadığı yönündeki gözlemden elde edilebileceğini düşünüyorum. Callee fırlar, çok yakın biri (2-3 kare) yukarıdan yükseltilmiş bir versiyonunu yakalar ve asıl istisna her zaman özel bir hata işleyicisine batırılır (sadece izlese bile) - bu AOP'ın kullanışlı olacağı yer, çünkü bu işleyiciler yatay olması muhtemeldir.

Hata kodları üzerindeki istisnaları tercih etme

• Her ikisi de bir arada olmalı.

• Belirli bir davranış öngördüğünde hata kodunu döndür.

• Bazı davranışlar beklemiyorsanız istisna döndürün.

• İstisna tipi kaldığında hata kodları normal olarak tek bir mesajla ilişkilendirilir, ancak mesaj değişebilir

• İstisna, hata kodu olmadığında yığın izine sahiptir. Bozuk sistemde hata ayıklamak için hata kodları kullanmıyorum.

Uygulamalara değil arayüzlere kodlama

Bu JAVA'ya özgü olabilir, ancak arayüzlerimi ilan ettiğimde, bu arayüzün bir uygulaması tarafından hangi istisnaların atılabileceğini belirtmiyorum, sadece mantıklı gelmiyor.

Kesinlikle bir istisna yakaladığımızda, uygulama hakkında varsayımlarda bulunuyoruz?

Bu tamamen size kalmış. Çok özel bir istisna türü deneyebilir ve sonra daha genel bir durum yakalayabilirsiniz Exception. Neden istisnanın yığını ilerletip sonra kullanmasına izin vermiyorsun? Alternatif olarak, istisna işlemenin "takılabilir" bir görünüme dönüştüğü görünüş programlamasına bakabilirsiniz.

Uygulamanın bir istisna atması gerekmiyorsa veya başka istisnalar atması gerekiyorsa?

Neden senin için bir sorun olduğunu anlamıyorum. Evet, istisnaları hiçbir zaman başarısız olmayan veya istisnalar ortaya koyan bir uygulamanız olabilir ve istisnasız olarak sürekli başarısız olan ve atanan farklı bir uygulamanız olabilir. Bu durumda, arabirimde herhangi bir istisna belirtmeyin ve sorununuz çözüldü.

Bir istisna yerine uygulamanızın bir sonuç nesnesi döndürmesi bir şeyleri değiştirir mi? Bu nesne, eyleminizdeki sonuçları ve varsa hata / başarısızlıkları içerir. Daha sonra bu nesneyi sorgulayabilirsiniz.

Sızdıran soyutlama

Bir arabirim neden hangi istisnaların atılabileceğini belirtmelidir? Uygulamanın bir istisna atması gerekmiyorsa veya başka istisnalar atması gerekiyorsa? Bir uygulama düzeyinde, bir uygulamanın hangi istisnaları atmak isteyebileceğini bilmek mümkün değildir.

Tecrübelerime göre, hatayı alan kod (istisna, hata kodu veya başka herhangi bir şey yoluyla olabilir) normalde hatanın kesin sebebini dikkate almaz - aynı şekilde, herhangi bir arızaya aynı şekilde tepki verirdi; error (bir hata diyalogu veya bir günlük kaydı olabilir); ve bu raporlama, başarısızlık prosedürü olarak adlandırılan koda ortogonal olarak yapılacaktır. Örneğin, bu kod, hatayı belirli hataların nasıl bildirileceğini bilen başka bir kod parçasına iletebilir (örneğin, bir mesaj dizesini biçimlendirme gibi), muhtemelen bazı bağlam bilgilerini ekleyebilir.

Tabii ki, bazı durumlarda olduğu hatalara özgü semantiğini takmak için gerekli ve farklı hata oluştu hangi dayalı tepki. Bu gibi durumlar arayüz şartnamesinde belgelenmelidir. Bununla birlikte, arayüz özel bir anlamı olmayan başka istisnalar hariç tutma hakkını saklı tutar.

İstisnaların, hataların raporlanması ve ele alınması için daha yapısal ve özlü bir kod yazılmasına izin verdiğini tespit ediyorum: hata kodlarını kullanmak, her aramadan sonra dönüş değerlerini kontrol etmeyi ve beklenmeyen bir sonuç durumunda ne yapılacağına karar vermeyi gerektirir.

Öte yandan, istisnaların, bir arayüzü çağıran koda saklanması gereken uygulama detaylarını ortaya koyduğunu kabul ediyorum. Hangi kod parçasının hangi istisnaları (Java'daki yöntem imzasında belirtilmediği sürece) hangi istisnaları atabileceğini bilmek mümkün olmadığından, istisnaları kullanarak, kodun farklı kısımları arasında çok karmaşık örtük bağımlılıklar getiriyoruz. bağımlılıkların en aza indirilmesi ilkesine karşı.

Özetleme:

• Bence istisnalar daha temiz bir koda izin verir ve test ve hata ayıklamaya daha agresif bir yaklaşım sağlar çünkü yakalanmamış istisnalar hata kodlarından çok daha görünür ve göz ardı edilmek zordur (yakında başarısız olur).
• Öte yandan, test sırasında keşfedilmemiş yakalanmamış istisna hataları üretim ortamında bir çarpışma şeklinde görünebilir. Bazı durumlarda bu davranış kabul edilebilir değildir ve bu durumda hata kodlarının kullanılmasının daha sağlam bir yaklaşım olduğunu düşünüyorum.

Her ikisi de sağ taraflı.

Görmezden gelinemez, ele alınması gerekir, tamamen şeffaftır. Doğru solak hata tipini kullanırsanız, java istisnası ile aynı bilgileri iletir.

Dezavantaj? Hata işleme uygun kod iğrenç görünüyor (tüm mekanizmalar için geçerlidir).