Bu mesajlar diğer geliştiriciler içindir.
Bu mesajların , uygulamada hata ayıklamalarına yardımcı olmak için geliştiriciler tarafından okunması beklenir . Bu iki şekilde olabilir:
Aktif hata ayıklama. Aslında kod yazarken ve ne olduğunu anlamaya çalışırken bir hata ayıklayıcı çalıştırıyorsunuz. Bu bağlamda, yararlı bir istisna, neyin yanlış gittiğini anlamayı kolaylaştırarak veya nihayetinde bir geçici çözüm önerdiğinde (bu isteğe bağlı olsa da) sizi yönlendirecektir.
Pasif hata ayıklama. Kod üretimde çalışır ve başarısız olur. Özel durum günlüğe kaydedilir, ancak yalnızca ileti ve yığın izini alırsınız. Bu bağlamda, yardımcı bir istisna mesajı hatayı hızlı bir şekilde lokalize etmenize yardımcı olacaktır.
Bu mesajlar sıklıkla günlüğe kaydedildiğinden, oraya hassas bilgileri dahil etmemeniz gerektiği anlamına gelir (örneğin, uygulamanın hatalarını ayıklamak için faydalı olsa bile)
Örneğin, IOSecurityExceptionbir dosya yazarken atılan bir istisna türü sorun hakkında çok açık değildir: bir dosyaya erişim iznimiz olmadığı için mi? Ya da belki okuyabiliriz ama yazamayız? Ya da belki dosya mevcut değil ve orada dosya oluşturma iznimiz yok mu? Veya belki de kilitlenmiştir (umarım, istisnanın türü bu durumda farklı olacaktır, ancak pratikte, türler bazen şifreli olabilir). Ya da belki Code Access Security herhangi bir G / Ç işlemi yapmamızı engelliyor mu?
Yerine:
IOSecurityException: dosya bulundu ancak içeriğini okuma izni reddedildi.
çok daha açık. Burada, dizindeki izinlerin doğru ayarlandığını hemen biliyoruz (aksi takdirde dosyanın var olduğunu bilemeyiz), ancak dosya düzeyindeki izinler sorunludur.
Bu, ayrıca istisna türünde olmayan herhangi bir ek bilgi sağlayamazsanız, mesajı boş tutabileceğiniz anlamına gelir. DivisionByZeroExceptionmesajın gereksiz olduğu iyi bir örnektir. Öte yandan, çoğu dilin mesajını belirtmeden bir istisna atmanıza izin vermesi, farklı bir nedenden dolayı yapılır: ya varsayılan mesaj zaten mevcut olduğundan ya da gerektiğinde daha sonra üretileceğinden (ve bunun nesnesinden mesaj, "OOPly" kelimesi için mükemmel bir anlam ifade eden istisna tipine eklenmiştir. konuşma .
Teknik (genellikle performans) nedenlerden dolayı, bazı mesajların olması gerekenden daha fazla şifreli olduğunu unutmayın. .NET'ler NullReferenceException:
Nesne referansı bir nesnenin örneğine atanmadı.
faydalı olmayan bir mesajın mükemmel bir örneğidir. Yararlı bir mesaj şudur:
Nesne başvurusu product, çağrıldığında bir nesnenin örneğine ayarlanmadı product.Price.
Bu mesajlar son kullanıcılar için değil!
Son kullanıcıların istisna mesajları görmesi beklenmiyor. Asla. Her ne kadar bazı geliştiriciler bu mesajları kullanıcılara gösterseler de, bu durum düşük kullanıcı deneyimi ve hayal kırıklığı yaratıyor. Gibi mesajlar:
Nesne referansı bir nesnenin örneğine atanmadı.
Son kullanıcı için kesinlikle hiçbir şey ifade etmiyor ve ne pahasına olursa olsun kaçınılması gerekiyor.
En kötü durum senaryosu, istisnayı kullanıcıya fırlatan ve uygulamadan çıkan küresel bir deneme / yakalama yapmaktır. Kullanıcıları ile ilgilenen bir uygulama:
İlk etapta istisnalar ele alır. Çoğu, kullanıcıyı rahatsız etmeden idare edilebilir. Ağ kapalı mı? Neden birkaç saniye bekleyip tekrar denemiyorsunuz?
Bir kullanıcının uygulamayı istisnai bir duruma yönlendirmesini önler. Kullanıcının iki sayı girmesini ve birincisini ikinciye bölmesini isterseniz, birkaç saniye sonra onu suçlamak için neden kullanıcının ikinci durumda sıfır girmesine izin verdiniz ? Metin kutusunun kırmızı olarak vurgulanması (sayının sıfırdan farklı olması gerektiğini söyleyen yararlı bir araç ipucu ile) ve alan kırmızı kalana kadar doğrulama düğmesini devre dışı bırakmaya ne dersiniz?
Bir kullanıcıyı, hata yapmayan bir biçimde bir işlem yapmaya davet eder. Bir dosyaya erişmek için yeterli izin yok mu? Neden kullanıcıdan idari izinler vermesini veya farklı bir dosya seçmesini istemiyorsunuz?
Başka hiçbir şey işe yaramazsa, kullanıcının sıkıntılarını azaltmak için özel olarak yazılmış, kullanıcının neyin yanlış gittiğini anlamalarına ve nihayetinde sorunu çözmelerine yardımcı olacak ve gelecekte de hatayı önlemeye yardımcı olacak (yararlı olduğunda) yardımcı olan, yararlı bir hata gösterir.
Sorunuzda, bir istisna dışında iki mesajınız olmasını önerdiniz: geliştiriciler için teknik ve son kullanıcılar için olan. Bu, bazı küçük durumlarda geçerli bir öneri olsa da, çoğu istisna, kullanıcılar için anlamlı bir mesaj üretmenin mümkün olmadığı bir düzeyde üretilir. Al DivisionByZeroExceptionve biz olmasını istisna engelleyemedi ve kendimizi işleyemez düşünün. Bölünme gerçekleştiğinde, çerçeve (istisnayı fırlatan iş kodu değil, çerçeve olduğu için) bir kullanıcı için ne kadar yararlı bir mesaj olacağını biliyor mu? Kesinlikle hayır:
Sıfıra bölünme gerçekleşti. [TAMAM]
Bunun yerine, kişi istisnayı atmasına izin verebilir ve daha sonra, iş bağlamını bildiğimiz ve son kullanıcıya gerçekten yardımcı olmak için buna göre davranabileceği daha yüksek bir seviyede yakalayabilir, böylece:
D13 alanı, E6 alanındaki ile aynı değere sahip olamaz, çünkü bu değerlerin çıkarılması bir bölen olarak kullanılır. [TAMAM]
ya da belki:
ATP servisi tarafından bildirilen değerler yerel veriler ile tutarsız. Bunun nedeni yerel verilerin senkronizasyon dışı kalması olabilir. Gönderim bilgilerini senkronize edip tekrar denemek ister misiniz? [Evet Hayır]
Bu mesajlar ayrıştırma değildir
İstisna mesajlarının da programlı olarak ayrıştırılması veya kullanılması beklenmemektedir . Arayan kişi tarafından ek bilgiye ihtiyaç duyulabileceğini düşünüyorsanız, mesajın yanına istisnada yazın. Bu önemlidir, çünkü mesaj önceden bildirilmeksizin değiştirilebilir. Tür, arabirimin bir parçasıdır, ancak mesaj: istisnaların işlenmesi için asla ona güvenmeyin.
İstisna mesajını hayal edin:
Önbellek bağlantısına bağlanma 500 ms bekledikten sonra zaman aşımına uğradı. Sunucu zamanındaki düşüşü belirlemek için zaman aşımını artırın veya performans izlemeyi kontrol edin. Önbellekleme sunucusu için ortalama bekleme süresi 6 ms idi. son ay için 4 ms. geçen hafta ve 377 msn. son bir saat için.
“500”, “6”, “4” ve “377” değerlerini çıkarmak istiyorsunuz. Ayrıştırma yapmak için kullanacağınız yaklaşım hakkında biraz düşünün ve ancak daha sonra okumaya devam edin.
Fikrin var mı? Harika.
Şimdi, orijinal geliştirici bir yazım hatası buldu:
Connecting to the caching sever timed out after waiting [...]
olmalı:
↓
Connecting to the caching server timed out after waiting [...]
Dahası, geliştirici ay / hafta / bir saatin özellikle ilgili olmadığını düşünüyor, bu yüzden ek bir değişiklik de yapıyor:
Önbellekleme sunucusu için ortalama bekleme süresi 6 ms idi. son ay için 5 ms. son 24 saat ve 377 msn. son bir saat için.
Ayrıştırma işleminize ne olacak?
Ayrıştırma yerine, istisna özelliklerini kullanıyor olabilir (veriler seri hale getirildikten sonra istediğini içerebilir):
{
message: "Connecting to the caching [...]",
properties: {
"timeout": 500,
"statistics": [
{ "timespan": 1, "unit": "month", "average-timeout": 6 },
{ "timespan": 7, "unit": "day", "average-timeout": 4 },
{ "timespan": 1, "unit": "hour", "average-timeout": 377 },
]
}
}
Bu verileri şimdi kullanmak ne kadar kolay?
Bazen (.NET içinde olduğu gibi), mesaj bile kullanıcının diline çevrilebilir (IMHO, bu mesajları çevirmek kesinlikle yanlıştır, çünkü herhangi bir geliştiricinin İngilizce okuyabilmesi beklenir). Bu tür mesajların ayrıştırılması imkansızdır.