C # 'da Ticari Proje İçin Hata Kodları Kalıbı Oluşturmak için En İyi Uygulamalar [kapalı]


43

Birçok KOBİ ve İşletmelerde uygulanacak olan bir işletme projesi üzerinde çalışıyorum.
Bu projeye destek zorlu olacak ve bu yüzden hatalar için bir kodlama kalıbı oluşturmak istiyorum ( HTTP durum kodları gibi ). Bu yardım masası çalışanlarının belgelere başvurmalarını ve problemleri en kısa sürede gidermelerini sağlayacaktır.

Bunu yapmak için en iyi uygulamalar ve öneriler nelerdir?
Bunu yapmak için herhangi bir yardım yararlı olacaktır.


1
Çok fazla olası cevap var ya da iyi cevaplar bu format için çok uzun olurdu. Lütfen cevap setini daraltmak veya birkaç paragrafta cevaplanabilecek bir sorunu izole etmek için detaylar ekleyin. Ve şimdiye kadar ne denedin?
Ben McDougall

İşletmenizin nasıl yapılandırıldığına bağlıdır. C # dilinde, kullanıcıya StackTrace'i bize postayla gönderme veya hata mesajı detaylarından kopyalayıp yapıştırma olanağı sağladık (sıkı güvenlik gereksinimlerimiz yoktu).
Şahin,

Yanıtlar:


69

Hata kodları ve hata dönüş değerleri arasında bir fark var. Bir hata kodu kullanıcı ve yardım masası içindir. Bir hata dönüş değeri, kodunuzun bir hatayla karşılaştığını gösteren bir kodlama tekniğidir.

Bir hata dönüş değerleri kullanarak hata kodları uygulayabilirsiniz, ancak buna karşı öneriyorum. İstisnalar, hataları bildirmenin modern bir yoludur ve içinde bir hata kodu taşımamaları için hiçbir neden yoktur.

Bunu nasıl düzenleyeceğim (2-6. Noktaların dilden agnostik olduğuna dikkat edin):

  1. Ek bir ErrorCodeözelliğe sahip bir özel istisna türü kullanın . Ana döngüdeki catch, bu alanı her zamanki gibi rapor edecektir (log dosyası / hata açılır / hata yanıtı). Tüm kodlarınızda aynı istisna türünü kullanın.
  2. 1'den başlamayın ve baştaki sıfırları kullanmayın. Tüm hata kodlarını aynı uzunlukta tutun, böylece yanlış bir hata kodunu bulmak kolaydır. 1000'den başlamak genellikle yeterlidir. Belki de kullanıcılar için net bir şekilde tanımlanabilir hale getirmek için öncü bir 'E' ekleyin (özellikle de destek masası kullanıcılara hata kodunu nasıl tespit edeceklerini bildirmek için kullanışlıdır).
  3. Tüm hata kodlarının bir listesini tutun, ancak bunu kodunuzda yapmayın . Geliştiriciler için yeni bir koda ihtiyaç duyduklarında kolayca düzenleyebilecekleri bir wiki sayfasında kısa bir liste tutun. Yardım masası kendi wikilerinde ayrı bir listeye sahip olmalıdır.
  4. Hata kodları üzerinde bir yapı zorlamaya çalışmayın. Her zaman sınıflandırılması zor hatalar olacaktır ve bir hatanın 45xx grubunda mı yoksa 54xx grubunda mı olduğunu saatlerce tartışmak istemezsiniz. Pragmatik olun .
  5. Kodunuzdaki her atımı ayrı bir kod atayın. Aynı nedenin sizce de olsa, yardım masasının farklı durumlarda farklı şeyler yapması gerekebilir. Kullanıcıların yanlış yaptıklarını itiraf etmelerini sağlamak yerine, wikilerinde "E1234: E1235'i Gör" ifadesini kullanmak daha kolaydır.
  6. Yardım masası isterse hata kodlarını ayırın. if (...) throw new FooException(1234, ".."); else throw new FooException(1235, "..");Kodunuzdaki basit bir çizgi yardım masası için yarım saat tasarruf sağlayabilir.

Ve hata kodlarının amacının yardım masası için hayatı kolaylaştırmak olduğunu asla unutmayın .


Bunu kişisel olarak hiç yapmadım, ancak genellikle "korelasyon kimliklerini" de görüyorsunuz, kullanıcıya gösterilen ve aynı zamanda günlüğe kaydedilen hata örneğine özel kılavuzlar da görüyorsunuz. Bu şekilde, günlüklerdeki kesin hata oluşumunu yaklaşık bir zaman ve bir hata kodundan daha kolay bulabilirsiniz.
xdhmoore

Muhtemelen korelasyon kimliğine hata kodunu dahil etmenin bir yolu vardır, böylece yardım masası için insan tarafından okunabilen bir hata kodu ve geliştiriciler için bir hata örneği kimliği olarak hizmet verebilir.
xdhmoore

Benim tarzım oldukça benzer. Ancak "E" yerine, uygulama kısmının kısa bir bölümünü ekledim. Belgelendirme çerçevemiz, örneğin Doc1234Main-App'ın sahip olabileceği bir zamana sahiptir IrS1234. Bu yüzden yardım masası çalışma arkadaşlarım, kullanıcılarım için yardım konusunda oldukça hızlılar.
Matthias Burger

6

İlk önce hataların olabileceği alanları yalıtmanız ve kullanıcı tarafından görülebilir durumda olmanız gerekir. O zaman onları belgeleyebilirsiniz. Bu kadar basit.

Eh, teoride basit .. uygulamada tüm kahrolasıca yerlerde hatalar meydana gelebilir ve bunları rapor etmek, güzel kodları günlüğe kaydetme, istisna atma ve kullanma ve geri dönüş değerlerini geçirme canavarına dönüştürebilir.

O zaman 2 adımlı bir yaklaşım öneririm. Birincisi, günlüğe kaydetme, lotları ve lotları kaydetmektir.

İkincisi, ana bileşenleri ve arayüzlerini belirlemek ve bu bileşenlerin kendilerini bulabilecekleri ana hata durumlarını tanımlamaktır. Bu hatalardan biri (hatayı dahili olarak nasıl idare edeceğinize bağlı olduğunda) daha görünür bir şekilde oturum açabilirsiniz. - istisnalar veya hata kodları burada bir fark yaratmaz). Bir kullanıcı genellikle hatayı görecek ve daha ayrıntılı bilgi için günlüklere gidecektir.

Aynı yaklaşım web sunucuları ve http hata kodu örneğiniz için de kullanılır. Kullanıcı bir 404'ü görür ve desteklediğini bildirirse, neler olup bittiğini, hangi sayfanın ziyaret edildiğini, ne zaman ve ne zaman başka bir anlam ifade edebileceğini öğrenebilecekleri herhangi bir bilgiyi toplayacaktır. , DB, ağ veya uygulamada olmak.


3

Açıklayıcı isimlerle özel istisnalar arardım ve mesajları temizler ve onları atardım. Bir dilin mevcut istisna altyapısını kullanmak, hata kodlarını dolaşıp yorumlamak için destek oluşturmaktan çok daha kolaydır.


1
Bu cevabı 1'den 0'a düşüren kişiye en azından bir sebep vermek için
minnettar olurum

1
Ben aşağı değildim (önemli değil, üstesinden gelebilir), ama bence dilin geri dönüş değerleri için mevcut bir destek var.
gbjbaanb

2
Benim için önemli; eğer hatalıysam bilmek istiyorum ki öğrenebilirim :-p Dönen değerler için var olan desteği ne demek istiyorsun? Normal bir dönüş değerini bir hata kodundan ayırt etmek için tesisat yazmak gerekmez mi? İstisnaların bir sistemin sınırındaki bir hata koduna çevrilmesi, bir şeydir, ancak bunları sisteminizin içinde hokkabazlık etmek, genellikle tavsiye edilmeyen bir şeydir. Pragmatik Programcı'nın bu tür şeylerden bahsettiğine inanıyorum.
Stefan Billiet 28:13

1
istisnalar her durumda iyi bir mekanizma değildir, ancak hataları kullanmaya karar verirseniz, her çağrıya bir param ekleyebilir veya önemli çağrıların hepsinin bir kod döndürmesini sağlayabilirsiniz. Sadece bunu yapmaya karar ver ve altınsın. Pragmatik olarak, sınırlardaki iki dönen hata kodunun bir karışımıyla (yani tek bir dile kilitlenmediniz) ve istisnaları dahili olarak kullanmanız gerekir.
gbjbaanb 28:13

6
Sana oy vermedim (kolay olsun, yoksa herkes bunu tekrarlamak zorunda kalacak :). Servis masasında çalıştınız veya aradıysanız, kısa bir mesaj iletmek bir hata mesajından çok daha kolaydır. Sözlü olarak iletildiğinde bir hata mesajı değişmesi garanti edilir.
Codism,
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.