Hata kodlarını nasıl atarsınız?


13

Orta ölçekli bir proje geliştirirken hata kodlarını nasıl belirler, yaratır ve sürdürürsünüz?

Hayatım boyunca bunu yapmanın basit ve temiz bir yöntemini düşünemiyorum. Bazı fikirlerim sınıf adlarını ve yöntem adını bir tamsayı dizesine dönüştürüyor, ancak yöntem adlarının ve sınıf adlarının değişebileceği gerçeği üzerine kullanıcıya gösterilmesi uzun sürüyor (umarım değil!). Diğerleri sadece artan bir günlük sistemi kullanıyor (yani, yeni bir hata mesajı oluşturduğumda, sadece son hata mesajı kimliğine 1 ekleyin). Ama bu tamamen örgütlenmemiş.

Daha spesifik olmak gerekirse ben gibi hata kodu hakkında konuşuyorum:

Error 401 Unauthorized.


1
hata kodları? "Sihirli sayılar" gibi mi? Mesela ... HATA 001. Sonra bir listeye gidip HATA 001'i okursunuz, bla bla bla demektir ... Evet?
wleao

@wleao - Yessir. Bunu kapsamak için sorumu düzenleyeceğim. Teşekkür ederim.
ahodder


Sorunuzda düzenlediğiniz gibi. Http ile nasıl yaptıklarına bakın. Sihirli sayılar kullanmanın iyi bir fikir olup olmadığını bilmiyorum. Ancak, gerçekten yapmaya istekli iseniz, onların kavramlarını takip edin. Örneğin, bir hata sınıflandırması var (sizde var mı?).
wleao

@wleao - henüz değil, ama siz ve Péter Török sayesinde kesinlikle bir tane yaratacağım. :)
ahodder

Yanıtlar:


16

Hayır.

Hata kodları bir anakronizmdir, çıktının gerçekten zor ve pahalı olduğu eski günlerden kaynaklanırlar ve bir hata durumunu bildirmenin tek yolu bir dizi ön panel ışıklarından olabilir: pdp11 / 70 ön panel

Bugünlerde, hemen hemen her ana dilde yerleşik olgun istisna işleme sahibiz. Kullanın. Kullanıcıya çalışabilecekleri bilgileri verin; teknik blah-blah ile rahatsız etmeyin, aksine kabaca neyin yanlış gittiğini ve bu konuda ne yapabileceklerini söyleyin. Günlüğe kaydetme için, istisnalarınıza açıklayıcı adlar verin ve adı günlüğe kaydedin. Hatırlaması daha kolay ve grep veya benzeri arama araçlarını kullanarak bulmak daha kolay.

İstisna, elbette, gömülü sistemler veya ağ protokolleri gibi çıktının hala zor ve pahalı olduğu durumlar için programlama yaparken. HTTP hala sayısal yanıt kodlarını kullanıyor çünkü verimli bir şekilde ayrıştırmak son derece kolay - bazı durumlarda sadece ilk basamağı okumak size yeterince şey söyleyebilir ve paketin geri kalanını atabilirsiniz.


Ayrıntılı cevap için teşekkür ederim, bu çok mantıklı ve bilmek iyidir.
ahodder

İllüstrasyon kullanımınız argümanınıza mükemmel bir şekilde uyuyor. PDP-11'leri sonsuza kadar okudum. Ama bu aslında gördüğüm ilk şey. Teşekkürler.
Mike Owens

2
Kodun içinde, bir hata kodunu işlemeyi tercih ederim ve o kadar yaşlı değilim.
JeffO

@Jeff: Hata kodlarıyla yapabileceğiniz her şey istisnalar ve sonra biraz daha fazlası ile yapılabilir. Hata kodlarını istisnalarla taklit etmek istiyorsanız, tek yapmanız gereken hata kodunu döndürmek yerine atmak ve dönüş değerini E_OK (veya OK yanıtı ne olursa olsun) ile karşılaştırmak yerine yakalamaktır. Adil olmak gerekirse, C'nin gerçek istisnaları yoktur ve uzun atlamalar o kadar uygun değildir, bu yüzden C yapıyorsanız, biraz mazeretsiniz.
tdammers

@Mike: Görüntü PDP-11 serisindeki wikipedia makalesinden; bu bulmak kolay değilse ne olduğunu bilmiyorum.
tdammers

6

HTTP gibi yaygın protokollerde hata / durum kodlarının nasıl düzenlendiğini kontrol etmelisiniz . Farklı durum / hata türleri için farklı aralıklar ayırırlar. Bu, kullanıcıların bilinmeyen bir durum kodu tanımlamasını ve geliştiricilerin daha önce ele alınmayan yeni bir hata türüne kod atamasını kolaylaştırır.


Taksonomiyi yanıtınıza ekleyin. Hataları yönetmeyi ve sürdürmeyi kolaylaştırır.
wleao

3

Üzgünüm, neden hata kodları kullanılıyor?
İstisnayı yakalayın, günlüğe kaydedin ve program kurtarılamazsa bir rapor göndermeyi teklif edin .

(Dilinizin istisnaları desteklediğini varsayarsak.)

Hatayı düzeltmenize yardımcı olabilecek ilgili tek bilgi, bir hata koduyla alamadığınız yığın izlemesidir . (Ayrıca hata raporları için hata kodlarını kullanmak ve bunları kullanıcının yüzüne atmak istemediğinizi de varsayıyorum.)


Bu çok doğru ve bunu yapıyorum, ama kullanıcılara ne söylerdim? Eminim onlar eğer seyyar satıcılık ve uygulama sadece ölür, hiçbir açıklama ya da duman bir şey olsaydı.
ahodder

6
Sanırım burada karışık olan en az üç farklı şey var. Birincisi, HTTP'de olduğu gibi, yazılımdan yazılıma kullanılan kodlardır. İkincisi, kullanıcıların bir hata raporunda (olay numaraları gibi) kullanabileceği kodlardır. Sonuncusu kullanıcıya gösterilebilecek mesajlardır. Onları ayrı şeyler olarak düşünmek yardımcı olabilir.
Darien

2
Hata kodlarını kullanmanın en büyük nedenlerinden biri, bir arka uç uygulaması oluşturduğunuzdadır. Bir istemci programının bir kodu yorumlaması ve yanıt vermesi, bir hata mesajından veya yığın izlemesinden çok daha kolay ve zariftir. Tüm hatalar hatalardan kaynaklanmaz.
Kaypro II

1
İstisnalar doğru olmak için çok zor! Bağlantılara bakın: programmers.stackexchange.com/questions/97874/…
Coder

@Coder: örneğiniz istisnaları kötüye kullanır. Atılmasını beklediğiniz şeyi yakalamanız gerekir . Çoğu yöntemin tek bir istisna bile atılmasını beklemesine gerek yoktur. Neyin üstesinden geleceğine karar vermek tamamen programcının sorumluluğundadır ve doğru yapmanın zor olabileceğini kabul ediyorum .
Dan

2

Prosedürel bir bağlam (C) alacağım. Nesneleriniz varsa, istisna olsun ya da olmasın, hata nesnesi genellikle daha iyidir.

Her modül için yerel hata kodlarını kullanmalısınız. Bir kütüphane için hata kodlarını listeleyen özel bir başlığa sahip olabilirsiniz (1, 2 vb.) (Veya isterseniz -1, -2). Her zaman bu kodlardan birini döndürdüğünüzden emin olun, örn errno. Kendi kodlarınıza çevirin. Birden fazla modül katmanınız varsa, her adımda çevirin (veya daha derin hata için bir aralık tanımlayın, örneğin 1001 - 1050 değerleri diğer modüllerden alınmıştır).

Kodu bir dizeye çevirmek için bir araç sağlamanız da önemlidir. Asla sadece hayal kırıklığına yol açan kodu bildirmemelisiniz. Aslında uygulamanızdaki herhangi bir kod bir dize çeviri işlevi ile gelmelidir. Örneğin libc tipik olarak vardır strerrorve strsignalne yazık ki yoktur strwaitstatus.


harika detay, teşekkür ederim. Bu gerçekten çok yardımcı oluyor.
ahodder
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.