Neden birçok istisna mesajı faydalı bilgiler içermiyor?

İstisna mesajlarının faydalı detaylar içermesi gerektiği konusunda belirli miktarda bir anlaşma olduğu anlaşılıyor .

Sistem bileşenlerinden kaynaklanan birçok genel istisna neden faydalı detaylar içermiyor?

Birkaç örnek:

• .NET Listendeksi erişim ArgumentOutOfRangeExceptionyok değil bana denenmiş ve geçersiz oldu endeks değeri anlatmak, ne de bana izin aralığını anlatıyor.
• Temel olarak, MSVC C ++ standart kütüphanesinden gelen tüm istisna mesajları tamamen kullanışsızdır (yukarıdaki ile aynı şekilde).
• .NET’te Oracle istisnaları, size "(TABLO VEYA GÖRÜNÜM bulunamadı") ifadesini söyler ( hangisi değil) .

Bu yüzden, bana göre, çoğu zaman istisna mesajları , faydalı olması için yeterli ayrıntı içermiyor gibi görünüyor . Beklentilerim doğrultusunda mı? Bunu fark etmeme rağmen istisnaları yanlış mı kullanıyorum? Ya da belki benim izlenim yanlıştır: istisnalar çoğunluğunun do aslında kullanışlı ayrıntıları?

İstisnalar, faydalı ayrıntılar içermez çünkü istisnalar kavramı yazılım mühendisliği disiplini içinde henüz yeterince olgunlaşmamıştır, bu nedenle birçok programcı onları tam olarak anlamamaktadır ve bu nedenle onlara düzgün davranmamaktadır.

Evet, IndexOutOfRangeExceptionmenzili dışında olan doğru dizini ve atıldığı sırada geçerli olan menzili içermelidir ve .NET çalışma zamanının oluşturucuları adına izin vermeyenler adına kabul edilemez. Evet, Oracle'ın table or view not foundistisnası, bulunamayan tablonun veya görüntünün adını içermeli ve yine, bundan kimin sorumlu olduğunu kabul etmemesi gerçeğini içermelidir.

Genel olarak, karışıklık, istisnaların insan tarafından okunabilir mesajlar içermesi gerektiği yönündeki yanlış yönlendirilmiş orijinal fikirden kaynaklanmaktadır;

İnsanlar istisnanın insan tarafından okunabilir bir mesaj içermesi gerektiğini düşündüklerinden, istisna tarafından taşınan her türlü bilginin aynı zamanda insan tarafından okunabilir mesaja da biçimlendirilmesi gerektiğine inanıyorlar ve sonra da insan tarafından okunabilen tüm mesajları yazmak için sıkılıyorlar. bina kodları, ya da bunu yapmaktan korkuyorlarsa, meraklı gözlerin mesajı görebilecekleri her ne olursa olsun, tavsiye edilemez miktarda bilgi açığa çıkaracaklarından korkuyorlar. (Diğer cevaplarda belirtilen güvenlik sorunları.)

Ama işin gerçeği istisna olmalıdır, çünkü onlar bu endişesi olmamalı ki değil bir insan tarafından okunabilir mesajı içerir. İstisnalar, yalnızca programcıların görmesi ve / veya başa çıkması gereken şeylerdir. Bir kullanıcıya arıza bilgisini sunma ihtiyacı varsa, çok yüksek bir seviyede, sofistike bir şekilde ve kullanıcının dilinde, istatistiksel olarak konuşması İngilizce olmayan bir dilde yapılmalıdır.

Bu nedenle, bizim için programcılar, istisnanın "mesajı" istisnanın sınıf adıdır ve istisnanın diğer bilgileri ne olursa olsun istisna nesnesinin (final / salt okunur) üye değişkenlerine kopyalanmalıdır. Tercihen, her bir düşünülen küçük bit. Bu şekilde, hiçbir mesajın üretilmesi gerekmez (ya da olmamalıdır) ve dolayısıyla meraklı gözler onu göremez.

Thomas Owens tarafından ifade edilen endişeyi aşağıdaki yorumda ele almak için:

Evet, tabii ki, bazı düzeyde, sen olacaktır istisna ile ilgili bir günlük mesajı oluşturmak. Ancak söylediklerinizle ilgili sorunu zaten görüyorsunuz: bir yandan, yığın izlemesiz bir istisna günlüğü mesajı kullanışsız, ancak diğer yandan, kullanıcının tüm istisna yığın izlemesini görmesine izin vermek istemiyorsunuz. Yine buradaki sorunumuz, perspektifimizin geleneksel uygulamalarla çarpıtılmış olmasıdır. Günlük dosyaları geleneksel olarak düz metin olmuştur, disiplimiz henüz başlangıç ​​aşamasındayken iyi olabilirdi, ama belki de artık değil: bir güvenlik kaygısı varsa, o zaman günlük dosyasının ikili ve / veya şifreli olması gerekir.

İkili veya düz metin olsun, günlük dosyası, uygulamanın hata ayıklama bilgilerini seri hale getirdiği bir akış olarak düşünülmelidir. Böyle bir akış yalnızca programcıların gözünde olur ve bir istisna için hata ayıklama bilgisi oluşturma görevi, istisnayı hata ayıklama günlük akışına seri hale getirmek kadar basit olmalıdır. Bu şekilde, günlüğe bakarak, istisna sınıf adını (daha önce de belirttiğim gibi, tüm pratik amaçlar için "mesaj") göreceksiniz), istisna üye değişkenlerinin her birini tanımlayan her şeyi tanımlayan ve pratikte bir log-içine-dahil etmek ve tüm yığın iz. Bir insan tarafından okunabilir istisna mesajının biçimlendirme bariz nasıl Not eksik bu süreçten.

PS

Bu konudaki düşüncelerimden birkaçı bu cevapta bulunabilir: İyi bir istisna mesajı nasıl yazılır?

PPS

Birçok insan ikili günlük dosyaları hakkında benim öneri tarafından kapalı bilet ediliyordu görünür, bu yüzden ne Burada önerdiğim şey daha net olduğundan emin olmak için bir kez daha cevap değiştirilmiştir değil günlük dosyası olduğu gerektiğini ikili olabilir, ama bu günlük dosyası olabilir , gerekirse ikili olun.

Sistem bileşenlerinden kaynaklanan birçok genel istisna neden faydalı detaylar içermiyor?

Deneyimlerime göre, istisnaların yararlı bilgiler içermemesinin birkaç nedeni var. Bu tür sebeplerin sistem bileşenlerine de uygulanacağını umuyorum - ama kesin olarak bilmiyorum.

• Güvenlik odaklı insanlar istisnaları bir bilgi sızıntısı kaynağı olarak görür ( örneğin ). İstisnaların varsayılan davranışı, bu bilgiyi kullanıcıya göstermek olduğundan, programcılar bazen dikkatli olunur.
• C ++ 'da, catch bloklarında bellek tahsis etmeye karşı argümanlar duydum (en azından iyi mesajları vermek için bağlamın bir kısmı). Bu tahsisatın yönetilmesi zor ve daha da kötüsü, bellek yetersizliği istisnasına neden olabilir - genellikle uygulamanızı kilitleyebilir veya belleği sızdırıyor olabilir. İstisnaları bellek ayırmadan güzel bir şekilde biçimlendirmek zordur ve bu uygulama programcılar gibi diller arasında geçiş yapmış olabilir.
• Bilmiyorlar. Yani, orada olan kod vardır senaryolar hiçbir neyin yanlış gittiğini fikir. Kod bilmiyorsa - size söyleyemem.
• Yerelleşmeyle ilgili kaygıların İngilizce'yi sadece dizgilerin sisteme girmesini engellediği yerlerde çalıştım - sadece İngilizce konuşan destek personeli tarafından okunabilecek istisnalar için bile.
• Bazı yerlerde, daha çok iddia gibi kullanılan istisnalar gördüm. Gelişme sırasında bir şeyin yapılmadığı ya da bir yerde bir değişiklik yapıldığı ancak başka bir yerde olmadığı konusunda net ve yüksek bir mesaj vermek için oradalar. Bunlar genellikle iyi bir mesajın çoğaltılmış çaba veya basitçe kafa karıştırıcı olacağı şekilde benzersizdir.
• İnsanlar tembel, programcılar çoğundan daha fazla. Olağanüstü yolda mutlu yoldan çok daha az zaman harcıyoruz ve bu bir yan etki.

Beklentilerim doğrultusunda mı? İstisnaları yanlış mı kullanıyorum, bunu bile fark ettim mi?

Tür? Demek istediğim, istisnalar hoş mesajlara sahip olmalı, fakat aynı zamanda istisnalar da . İstisnai koşullardan kaçınmak için kod tasarlarken ya da istisnai koşulları işlemek için kod yazarak (mesajı yok sayarak) kodlama yaparken bunları etkileşimli bir geri bildirim mekanizması olarak kullanmamanız gerekir. Bunları hata ayıklama amacıyla kullanmak kaçınılmazdır, ancak çoğu durumda minimumda tutulması gerekir. Bu sorunun farkına varmanız beni önleme konusunda yeterince iyi bir iş yapmamanız konusunda endişelendiriyor.

Aşırı derecede C # deneyimine veya özellikle C ++ deneyimine sahip değilim, ancak şunu söyleyebilirim: geliştirici tarafından yazılan istisnalar, 10 kereden 9'u, bulabileceğiniz herhangi bir genel istisnadan daha yararlıdır.

İdeal olarak evet, genel bir istisna, hatanın tam olarak neden olduğunu size bildirir ve bunu kolaylıkla düzeltebilirsiniz - ancak gerçekçi olarak, çok çeşitli istisnalar veya farklı istisnalar atabilen çok sınıflı büyük uygulamalarda Aynı tür istisnalar dışında, hata çıktısı için kendi çıktınızı yazmak, varsayılan mesaja dayanmaktan her zaman daha değerlidir.

Bu o kadar çok insan işaret çünkü bazı uygulamalar yok, nasıl olmalı istiyorum bunlar kullanıcı güvenlik nedeniyle, görmek ya da bunları kafa karıştırıcı önlemek istemiyorum bir hata mesajı atmak.

Bunun yerine, tasarımınızda uygulamanızda ne tür hatalar atılabileceğini tahmin etmelisiniz (ve her zaman hatalar olacaktır) ve sorunu tanımlamanıza yardımcı olacak hata bulma mesajları yazmalısınız.

Bu her zaman size yardımcı olmaz - çünkü hangi hata mesajının faydalı olacağını her zaman tahmin edemezsiniz - ancak uzun vadede kendi uygulamanızı daha iyi anlamak için ilk adımdır.

Soru özellikle, "sistem bileşenleri" (aka standart kütüphane sınıfları) tarafından atılan bu kadar çok istisnanın neden faydalı detaylar içermediğini soruyor.

Ne yazık ki, çoğu geliştirici temel bileşenleri standart kütüphanelerde yazmaz, ayrıca ayrıntılı tasarım belgeleri veya zorunlu olarak kamusallaştırılan diğer tasarım gerekçeleri değildir. Başka bir deyişle, asla kesin olarak bilemeyiz.

Bununla birlikte, ayrıntılı istisna bilgilerinin neden istenen veya önemli olamayacağına dair akılda tutulması gereken iki önemli nokta vardır:

1. Bir istisna, herhangi bir şekilde kod çağırarak kullanılabilir: standart bir kütüphane, istisnanın nasıl kullanıldığına kısıtlamalar getiremez. Spesifik olarak, kullanıcıya gösterilebilir. Sınırların dışında bir dizi dizini göz önünde bulundurun: bu, bir saldırgana faydalı bilgiler verebilir. Dil tasarımcısı, bir uygulamanın atılan istisnayı nasıl kullanacağı veya ne tür bir uygulama (örneğin web uygulaması veya masaüstü) kullanacağı konusunda hiçbir fikri yoktur, bu nedenle bilgileri dışarıda bırakmak güvenlik açısından daha güvenli olabilir.

2. İstisnalar olmamalıdır kullanıcıya gösterilecektir. Bunun yerine, dostça bir hata mesajı görüntüleyin ve istisnayı bir saldırganın erişemeyeceği bir konuma kaydedin (varsa). Hata tanımlandıktan sonra, bir geliştirici kod boyunca hata ayıklamak, yığın çerçevelerini ve mantık yollarını incelemek zorundadır. Bu noktada, geliştirici, sahip olabileceği herhangi bir istisnadan daha fazla bilgiye sahiptir.

Öncelikle, diag mesajı 4 saniye içinde sizi tam kod satırına ve alt komuta götüren bilgilerle yüklenmiş olsa bile, bir baloncuk patlamasına izin verin, kullanıcıların asla yazmalarını ya da destekçilere iletmemeleri ihtimali ve size söylenecek "Peki, ihlal hakkında bir şeyler söyledi ... Bunun karmaşık göründüğünü bilmiyorum!"

30 yıldan uzun bir süredir yazılım ve diğer yazılımların sonuçlarını destekliyorum ve kişisel olarak, bir istisna mesajının şu anki kalitesinin, sonuçların kendi modellerine nasıl uyduğuna bakılmaksızın neredeyse güvenlikle ilgisi yok. evren, endüstrimizdeki o kadar çok kişinin aslında kendi kendine öğretildiği ve iletişim derslerine hiç yer vermedikleri gerçeğiyle ilgili çok daha fazlası. Belki tüm yeni kodlayıcıları neyin yanlış gittiğini bulmakla uğraşmak zorunda kaldıkları birkaç yıl boyunca bakım pozisyonuna zorlarsak, en azından bir çeşit hassasiyetin önemini anlarlar.

Son zamanlarda yeniden yapılan bir uygulamada, iade kodlarının üç gruptan birine gireceğine karar verildi:

• 0'dan 9'a kadar ek bilgi ile başarı ile başarı olacaktır.
• 10'dan 99'a kadar ölümcül olmayan (kurtarılabilir) hatalar olabilir ve
• 101'den 255'e kadar ölümcül hatalar olur.

(100 nedense bırakıldı)

Herhangi bir iş akışında, düşüncemiz yeniden kullanılmıştı ya da genel kod, ölümcül hatalar için genel geri dönüşler (> 199) kullanır, bu da bizi bir iş akışı için olası 100 ölümcül hatayla karşılar. Mesajdaki küçük farklılaşan verilerle, bulunamayan dosya gibi hataların tümü aynı kodu kullanabilir ve mesajlarla farklılaşabilir.

Kod müteahhitlerden geri döndüğünde, neredeyse HER BİR TEKLİ FATAL HATASI'nın iade kodu 101 olduğu zaman sürprizimize inanmazsınız.

Tek düşününce, sorunuza cevabım mesajlar çok anlamsızdır, çünkü ilk yaratıldığında, hiç kimsenin geri dönmediği yer tutucular olurlardı. Sonunda millet, mesajlar nedeniyle değil, sorunu çözdüğümde sorunların nasıl çözüleceğini buldu.

O zamandan beri, kendi kendine öğretilen insanlara hiçbir zaman bir istisnanın içermesi gerektiği konusunda iyi bir örnek olmadı. Buna ek olarak, daha fazla kullanıcı mesajları okumaz, daha az destek vermek için iletmeye çalışırsınız (Daha sonra kullanılan yorumlarla birlikte gönderilmeden önce kullanılan ve kesilen ve yapıştırılan hata mesajlarını gördüm. çok fazla bilgi gibiydi ve hepsini istemem mümkün değildi, bu yüzden rastgele bir kısmını kaldırdılar.

Gelecek nesil kodlayıcılardan çok fazla (hepsi değil ama fazlası kadar) ile yüzleşelim, eğer daha fazla çalışırsa ve flaş eklemiyorsa, buna değmez ...

Son not: Eğer bir hata mesajı bir hata / dönüş kodu içeriyorsa, bana öyle geliyor ki, çalıştırılan modüllerde bir yerde "eğer durum kodu geri dönüş değeri" ise, "neden koşulu dönüş kodu değeri" gibi bir şey okuyan bir satır olmalı ve şartlar size neden dönüş kodunu söylemeli oluştu. Bu basit bir mantıksal yaklaşım gibi gözüküyor, ancak benim yaşamım boyunca, Windows yükseltme CODE 80241013 veya başka bir çok benzersiz tanımlayıcıda başarısız olduğunda ne olduğunu Microsoft'a anlatmak için YTL. Biraz üzgün değil mi?

Bununla birlikte, istisnaların mümkün olduğunca fazla bilgi içermesi gerektiği veya en azından daha az jenerik olması gerektiği konusunda hemfikirim. Tabloda bulunmayan durumda, tablo adı iyi olurdu.

Ancak, istisna aldığınız koddaki yerde ne yapmaya çalıştığınız hakkında daha fazla bilgi sahibi olursunuz. Kontrolünüz dışındaki bir kütüphanede bir şeyler ters gittiğinde durumu düzeltmek için gerçekten pek bir şey yapamayacak olsanız da, bir durumda yanlış giden şeyler hakkında daha faydalı bilgiler ekleyebilirsiniz.

Bulunamayan tablonun bulunamaması durumunda, bulunamayan tablonun ÖĞRENCİLER olarak adlandırılması söylenir, çünkü böyle bir tablonuz yok ve bu dize kodunuzda hiçbir yerde yok.

Ancak, istisnayı yakalar ve yürütmeye çalıştığınız SQL ifadesiyle yeniden ifade ederseniz, daha iyi olursunuz ; DROP TABLO ÖĞRENCİLERİ; (Her zaman bir xkcd vardır!)

Bilgilendirici istisnalar dışında daha az şeyle savaşmak için: yapmaya çalıştığınız şeye özgü daha fazla bilgiyi deneyin.

Muhtemelen, bunun neden soruya daha fazla cevap vermesi gerektiğini sormalıyım, bunun sebebi, kütüphanecilerin üreticilerinin odağının neden istisna mesajlarını daha iyi hale getirmemelerinin muhtemel bir nedeni olduğunu bilmemeleridir. Neden bir şey bu denenmiş başarısız oldu, bu mantık arama kodunda.

Biraz farklı bir cevap vermek için: Suçlu kod muhtemelen spec:

• Fonksiyon X alır ve Y ile döner
• X geçersizse, Z istisnasını atın

Tam zamanında ve minimum telaşla tam olarak (inceleme / testte reddedilme korkusu) spekülasyona baskı yapmak için baskı ekleyin, ardından tamamen uyumlu ve yararsız olmayan bir kütüphane istisnası için tarifiniz olur.

İstisnaların dile ve uygulamaya özel bir maliyeti vardır.

Örneğin, C ++ istisnaları, çağrı çerçevesini fırlatma ve çağrı çerçevesini yakalama arasındaki tüm canlı verileri yok etmek için gereklidir ve bu pahalıdır. Dolayısıyla, programcılar istisnaları çok fazla kullanmak istememektedir.

Ocaml'da istisna atma neredeyse bir C kadar hızlıdır setjmp(maliyeti, aktarılan çağrı çerçevelerinin sayısına bağlı değildir), bu nedenle geliştiriciler büyük miktarda kullanabilir (istisnai olmayan, çok yaygın durumlar için bile). Buna karşılık, C ++ istisnaları yeterince ağır olduğundan, muhtemelen onları Ocaml'daki gibi kullanmayacaksınız.

Tipik bir örnek, oldukça derin bir özyinelemede "durdurulabilen" bazı özyinelemeli araştırma veya keşiflerdir (örneğin bir ağaçta bir yaprak veya bir birleştirme işlevi bulma). Bazı dillerde bu durumu her arayan kişiye yaymak daha hızlı (yani daha aptalca). Diğer dillerde bir istisna atmak daha hızlıdır.

Bu nedenle dile (ve onu kullanan geliştiricilerin alışkanlıklarına) bağlı olarak, bir istisna birçok faydalı ayrıntı taşıyabilir veya tam tersine yerel olmayan hızlı bir sıçrama olarak kullanılabilir ve yalnızca çok yararlı verileri taşır.

Ne endeks değeri veya gerekli aralık veya tablonun adı düşündürüyor olan bir istisna, yararlı bir detay?

İstisnalar, hata işleme mekanizması değildir; Onlar bir kurtarma mekanizmasıdır.

İstisnaların amacı, istisnayı idare edebilecek kod seviyesine çıkarmaktır. Bu seviyenin neresinde olursanız olun ya gerekli bilgiye sahipsiniz ya da alakalı değil. İhtiyacınız olan ancak anında erişime sahip olmayan bir bilgi varsa , istisnayı uygun seviyede ele almazsınız.

Ek bilgilerin nerede yararlı olabileceğini bir kez düşünebilirim, uygulamanızın çökmesine ve bir hata dökümü yayacağınıza mutlak üst düzeydedir; ancak bu bilgilere erişmek, derlemek ve saklamak istisna değildir.

Her yere "yeni İstisna atma" koyabilirsin ve iyi diyebilirsin, kötü istisnalar yazmak mümkündür. Ancak, alakasız bilgilerin yer alması, onları doğru kullanmak için gerekli değildir.