Soru Bazen istisnalarımı batırmamın iyi olur mu?


En iyi uygulama sorularım var. Bunun subjektif olduğunun farkındayım ama eğer bu genel bir programlama uygulamasıysa, benden daha akıllıca sorular sormak istiyorum.

Uygulamanızın önemli işleyişini engellemek istemediğiniz bir NON-CRITICAL yöntemine sahipseniz, böyle bir hata havuzu kullanmak yaygın mıdır?

Try 
    'do stuff.  not important if it fails.

Catch ex as exception
    'sink.  do nothing.
End Try

Beni işe almayı düşünüyordun ve bazı kodlarımı okuyordun ve bunu gördün mü?

Seth

DÜZENLE Vaov! Cevaplarınız için teşekkürler. Konsensüsün asla yapılmaması gerektiğini veya çok nadir olması gerektiğini düşünüyorum.

Bu soru için sana bağlamı vereceğimi düşündüm. Birincisi, Karl Sequin makalesine güçlü bir aşinayım var ve bu modeli yıllardır takip ettim.

Ama bugün üzerinde çalıştığım projede, değişim listesinde çalışıyordum ve basit bir özellik ekleyerek karşı karşıya kaldım. (Bilmeyi düşünüyorsanız ... Zengin Metin Kutusuna bağlam menüsü desteği ekliyor.)

Ekteki notta "eğer 15 dakikadan uzun sürerse ... bırakın."

Bu yüzden, potansiyel olarak kullanışlı bir özellik eklemekle yüzleşmekteyim, ancak çalışma özelliklerini bozmayacağını test etme zamanı bile yok. Kayıt için, bu sistem için istisna işleyicimiz, bu hataları işlemek ve batırmak veya günlüğe kaydetmek için bir mekanizmaya sahiptir. Ancak, güçlü bir hata işleme sistemine sahip olmayan bir sistem üzerinde çalışıyor olsaydım. Bu özelliği eklemek iyi olur ve bir hata oluşursa ... hiçbir şey gerçekten kaybolur.

Benim düşüncem buydu. Ama mesajını kalbine aldım ... temelde bu kötü bir fikir.

Seth


36
2018-01-26 19:56


Menşei


Konuyla ilgili bazı okumalar: codebetter.com/blogs/karlseguin/archive/2010/01/25/... - bdukes
Ayrıca: blogs.msdn.com/ericlippert/archive/2008/09/10/... - bdukes
İnsanların bu adamın istisna işlemesini anlamadığını varsaydığını düşünüyorum, ama ne yaptığını tam olarak bildiği izlenimini elde ediyorum. Bu senaryo nadir de olsa tamamen geçerlidir. - Patrick Karcher
Kopyala (etiketli C #): stackoverflow.com/questions/204814/... - Jon Seigel
Yinelenen değil. Bu soru programcıların göz ardı etmemeleri gereken hataları defalarca görmezden gelmeleriydi. Bu durumda, Seth'in bunu yapması gerekip gerekmediği konusunda hiçbir fikrimiz yok. Yanlış olduğunu ya da onun sorusuyla ona yardım edebiliriz. Bazıları, Tüm hataların her zaman belirli eylemlere cevap vermesi gerektiği ve dolayısıyla Seth'in bunu yapmasının yanlış olduğu varsayımına giriyor. Bu varsayım yanlış. - Patrick Karcher


Cevaplar:


Evet, yaygındır, ancak genelde yapılmamalıdır.

Gibi istisnalar var OutOfMemoryException uygulamanızı son derece hassas bir şekilde sonlandırma girişiminde bulunmadıkça yakalanmayanlar daha iyidir.

Vakaların çoğunda yutma System.Exception veya System.SystemException kaçınılmaz olarak daha fazla çalışma zamanı problemini gizleyecektir.


13
2018-01-26 19:58



Kodun attığı herhangi bir hatayı dokümantasyona bakabilir ve sadece güvenli bir şekilde kurtarabileceğinizleri yutmalısınız. - Nick Larsen♦
En azından, sadece yutmak yerine oluşturulan istisnayı kaydedin. Bunu yapmamayı düşünebileceğim tek zaman, bir API’nin new Exception(). Bu durumda, API kötü kişidir. - Will Eddins


Malısın asla saklamak İstisna. Yine de seni işe alabilirim ama sen benim için çalışırken bunu yapmazsın :)

Ciddi olsa da, Java'da (örneğin) Göz ardı edilmeyi tercih edebileceğiniz bazı durumlar için istisnalar kullanılır. FileNotFoundException (yaptığınız gibi, bir yorum ile). Ama eğer bir tür İstisna yakalarsan - IOException - sadece onu saklayamazsın. İstisna, özellikle size bir şey ifade etmiyorsa, RuntimeException ve müşteriye atmak.

Yol boyunca bir yerlerde, Exception ele alınmalı, ama asla saklanmamalıdır.


8
2018-01-26 20:06



Ve bil bakalım, mikro yönetmenlik için çalışmak istemiyorum. Onun yerine, bütün doğru cevaplara sahip olamayacaklarını ve mutlak kuralların aptalca olduğunu anlayan birini tercih ederim. Bu sorunun anlaşmazlıklarına bakın. Mühendislerin işlerini yapsınlar. - Bjorn Tipling
@apphacker, bana "asshat" kelimesini öğrettiği için +1. urbandictionary.com/define.php?term=asshat - Dan Rosenstark


Yaygındır, ama bundan kaçınmak en iyisidir. En azından istisnai bir yere giriş yapmalısın.

Ayrıca akış kontrolü için istisnalar kullanmaktan kaçının. Kurallarınız, istisnalara başvurmadan olası tüm durumları ele almak için yazılmalıdır. Performans artışlarının yanı sıra, bu yöntem ayrıca bir istisna olduğunda, dikkatinizi çeker.


7
2018-01-26 20:01



Ancak, o zamanlar program durumuyla ilgili bir şey içermediğinde, bir istisna günlüğüne sahip olmanın pek bir yararı olmadığını unutmayın. - Dana the Sane
Tabii ki. ELMAH (asp.net) gibi kaydediciler harika çünkü onlar her şeyi (tüm istisna detayları, çağrı yığını, vb.) Günlüğe kaydederler. - 3Dave
Python yazıyorsanız, akış kontrolü için istisnaları kullanmak kesinlikle kabul edilebilir (ve aslında çoğu zaman gereklidir). Ancak Python istisnaları çok ucuzdur ve genellikle denemeyi denemek ve ilk önce test etmek yerine istisnayı yakalamak daha ucuzdur. Bu o dile özgü olsa da; Başka örnekler olabilir, ancak örneğin Java ve C ++ tersidir. - Andrew McGregor
Bir yakalama bloğunda bir istisnayı günlüğe kaydetme ile ilgili sorun, tüm sonuncu cümlelerin istisnanın atıldığı ve yakalama bloğu arasında yürütülmesidir. Böylece program durumu günlüğe kaydedilmeden önce değiştirildi. Bir alternatif, üst düzey bir istisna olay işleyicisinde oturum açmaktır. - RoadWarrior


Burada tüm istisnaları yakalamamalısınız. Nadir bir durumda, belirli bir beklenen istisnayı görmezden gelmek iyi olabilir. Ancak, yakalamak herşey istisnalar ve onları yutmak, bir OutOfMemoryException ve diğer düzeltilemez istisnalar


5
2018-01-26 20:01





Buradaki çoğu kişi aslında geliştiriciden bahsediyor olsa da, şunu belirtmek isterim hikayenin başka bir bakış açısı.

İtiraf ediyorum: istisnaları yuttum ve her halükârda IMHO'nun tasarımcı olmasıydı işlev berbat.

"İstisnalar", "istisnalar" anlamına gelir, hata veya hata değildir. Demek istediğim: Eğer fonksiyon girişin doğru olmayabileceğini kabul etmeli, fonksiyonun beklemesini bekliyorum İstisnalar kullanmayın. Gazapım özellikle "ParseException" ı hedefliyor.

Girişi ayrıştırırsanız, büyük olasılıkla bilinmeyen / bozuk / hatalı girdi bulacaksınız. o "normal", bir istisna değil. Ve bu durumda geliştiricinin rahatsız edici olduğunu düşünüyorum İşlev düzgün bir şekilde ayrıştırılamadıysa ParseException öğesini atar.

Niye ya ?

  • İstisna kontrol akışını bozar
  • İstisna yavaş
  • Çoğunlukla fark etmez, çünkü varsayılan değerlerle başlatıyorsunuz.

Eğer parseFunction işlevini çağırırsanız, binlerce veya milyonlarca kez günlük dosyanızın tıkanmasını engellersiniz. kesinlikle hiçbir şey değil.

Aksine ideal işlevim, durum koduyla birlikte bir sınıf nesnesi verir ve mesaj gibi

StatCode stat = parseXYZ(Reader r);

Daha sonra test edilebilir.

if (stat.code != OK)  
  //whatever

Öte yandan, tahmin edemeyeceğiniz problemler yaşıyorsanız (dosya kilitlenmemişse, anlamsız argüman, yasadışı iş parçacığı) istisnalar mükemmel.


5
2018-01-26 20:59



Bunlar Eric Lippert'in "velayet istisnaları" olarak adlandırdığı şey. Sadece belirli istisna durumlarını yakalamak ve bunları göz ardı etmek ve orijinal posterin yaptığı gibi olası tüm istisnaları yakalamamak daha iyidir. - Mark Byers
Bu ipucu için teşekkürler, bunu fark eden tek kişi olmadığımı görmek beni rahatlatıyor. - Thorsten S.
Müşterinin uğraşmaya hazır olduğu durumlarda herhangi bir istisna atmadan iyi bir API kullanmak mümkün olmalıdır; Ayrıca, istemcinin hatalarla başa çıkmaya hazır olmadığı durumlarda çok fazla hata kontrol kodu olmaksızın iyi bir API kullanmak mümkün olmalıdır. "TryXXX" yöntemlerine sahip olmak önemli olsa da, çoğu durumda, XXX yapacak ve başarısız olurlarsa bir istisna atacak yöntemlere sahip olmaları da önemlidir. Her ikisi de gereklidir. Bazen yararlı olabilecek üçüncü bir yaklaşım, sorunlu durumlarda çağrılacak bir delegeyi geçmek, istisnaların yalnızca seçkin durumlarda atılmasına izin vermektir. - supercat


Şahsen bunu inanılmaz derecede kötü bir uygulama olarak görüyorum.

(Ne yazık ki), kod gözden geçirirken her zaman aradığım şeylerden biri ve boş yakalama blokları bulduğumda ya da esas olarak yutmak istisnaları olan blokları yakaladığımda sorduğum sorular:

  1. Şu anda bu istisnanın hiçbir zaman önemli olmayacağından% 100 emin misiniz?
  2. Kod tabanının nasıl geliştiğine bakılmaksızın, gelecekte burada yakalanan istisnaların hiçbir zaman önemli olmayacağından% 100 emin misiniz?
  3. 1 ve ikisi de ikisi de doğru olsa bile, buraya giriş yapmak gerçekten çok mu zor?

Benim için en önemli şey, günlüğe kaydetme - istisnaların iyi bir şekilde kaydedilmesi ve program yürütmesinin iyi bir şekilde izlenmesi zaman içinde güvenli bir şekilde modifiye edilebilen ve kullanıcıların güvendiği istikrarlı bir sisteme dönüşen kodun tasarımı için temeldir.

Bunun ötesinde, iyi bir uygulama sadece belirli istisnaları yakalamak ve diğer istisnaların yığının yığılmasına izin vermektir. Kör olmayan istisnaları hataların işlenmesi için bir yol olarak asla doğru değildir.


4
2018-01-26 20:04



Eşzamansız olarak değişebilen nesnelerin durumlarını gösteren bazı Control türevli sınıflarım var. İzlenen bir nesne değişirse ve güncelleme isteği beklemediyse, BeginInvoke (Güncelleyici) kullanıyorum. Kontrol, BeginInvoke'den hemen önce bertaraf edilirse, BeginInvoke boğduğum bir istisna atar. İstisnai imzaladıysam, böyle bir bilginin uygulamaya konabileceği pratik kullanımları hayal edebiliyor musunuz? Değilse, neden toplama yapmaktan çekiniyorsunuz? - supercat


En iyi uygulamalar bunu yapmamanızı söylüyor. Bir hata oluştuğunu bilmek istemeyeceğiniz kadar önemsiz olan nedir? Ben bununla hiç karşılaştığımı sanmıyorum.

Ya yakalama yapısını kullanmam veya kodun bir boolean döndüren bir yönteme yeniden girmesini sağlarım, böylece en azından başarılı olup olmadığını belirleyebilirim ...

Bu benim düşüncem ...

Güncelleştirme: Bir istisna batırabileceğiniz zamanlar olabilir. Bu durumlarda, hangi istisnaların bunun için aday olabileceğini ve ardından bu özel durumun yakalanacağını tespit ederim. Ama bu yakalamaktan uzak ExceptionYukarıda belirtilenler gibi herhangi bir şey olabilir OutOfMemoryException. Kısacası, sadece görmezden gelmek niyetiyle belirli istisnaları yakalarım.


4
2018-01-26 20:02



object.close () yöntemlerinin birçoğu, özellikle jdbc api'nin% 99'unun yalnızca kırmızı tane ringaları olduğu bir tür istisna atar. Ben genellikle onları sadece RuntimeException içinde sardığımı söyledi - feeling unwelcome
RuntimeException'da bunları paketleme avantajı nedir? - DMKing
@DMKing: Muhtemelen bunu yapıyor çünkü RuntimeException'ın throw cümlesiyle bildirilmesi gerekmiyor. Görmek: java.sun.com/j2se/1.4.2/docs/api/java/lang/... - Mark Byers
Object.close () 'daki istisnaları, özellikle de veritabanı bağlantılarıyla, bununla ilgili yapabileceğiniz hiçbir şey olmadığına dair fikri görmezden gelmenin tamam olduğunu düşünürdüm. Şimdi o kadar emin değilim. Belki de girerim ve bir db bağlantısını kapatacak koşullar altında bir istisna atarım. - DMKing
Bir db bağlantısının kapatılmasıyla ilgili koşullar istisnalar atar, uygulamaya bağlıdır. - Frank V


Hayır, bu benim görüşüme göre sorun değil.

Sisteminiz kritik olmayabilir, ancak muhtemelen bunu çalıştırmak istediğinizi varsayalım, aksi halde ilk etapta yazmamış olursunuz. Şimdi eğer bir gün koşmayı bırakırsa, bunu sürdürmek zorunda olan insanlar, hatayı tamamen sakladığınız için neden birdenbire işe yaramadığını bilmiyorlar. Hatta, hataların nereden geldiğini ve hatta ilk etapta bir hata olduğunu fark etmeleri bile uzun zaman alabilir. Bir çok geliştirici zamanını boşa harcayabilirdi, oysa atmak yerine hatayı kaydetmek için fazla zaman harcamazdı.

Ve sen istisnaları yakalıyorsun OutOfMemoryException Gerçekten yakalamak ve atmak istemiyorsun. Bu kod kritik değilse ancak çok fazla bellek tüketiyor ve tüm sisteminizi yavaşlatıyorsa, bunu düzeltmeniz için size söylemek istersiniz.


1
2018-01-26 20:06





Bazen, geliştiricilerin doğru hata işleme kodunu yazmak yerine bir özel durumu yakalamayı ve yutmayı tercih ettiğini buluyorum.

Bazı kodlar var, bir istisna atarsa, istisnayı yakalarlar, başka bir şey denerler ve eğer bu bir istisna atarsa, başka bir şey yaparsa, vs. İstisnalar nesnelerdir ve atıldığında oluşturulurlar. Yapabilirseniz, bir hatayla başa çıkmak için doğru işleme kodunu yazın ve yalnızca can't continue Sebebi ne olursa olsun.

Yutma istisnalarına gelince, yalan söylemediğimi söylediğimde yalan söylerdim. Programınız kötü davrandığında hata ayıklamaktan çok bahsetmek değil, en iyi uygulama değildir. Ben de onlar tarafından ısırıldım.


1
2018-01-26 20:40





Neredeyse hiçbir zaman iyi bir fikir değildir, ancak istisnaları nasıl yaptığınıza bağlı olarak uygulanabilir olduğunda durumlar vardır. Örneğin:

try {
   Cache.refresh(myObject)
}
catch (NotInCacheException) {
   // If the object isn't already in the cache, then we don't have to worry 
   // about refreshing it. It's assumed that this is a common occurrence,
   // so we don't need to log it either; that ends up just spamming
   // the logs. So, just swallow it, silently.
}

(Not: Cache.refresh () 'ın bir NotInCacheException atıp atmaması gerekip gerekmediğini burada bulabilirsiniz; sadece bunu hızlı bir örnek olarak kullanıyorum).

Ancak Caveat: Eğer aradığınız çok özel bir istisna varsa sadece bununla kurtulabilirsiniz. Örneğinizde, yakalamaktasınız Exception, hangisi yol Çok yüksek seviyede (diğerlerinin de belirttiği gibi kritik hataları yutuyor olacaksınız).

Ayrıca: Esnek bir günlük kaydı çerçeveniz varsa, bu istisnayı bilgi amaçlı olarak yine de kaydetmek isteyebilirsiniz. Log4Net / Log4J'yi burada özellikle düşünüyorum: sınıfınızı ve önem derecesini temel alan istisnaları seçmek / yoksaymak için günlüğünüzü (çalışma zamanı sırasında bile) yapılandırabilirsiniz. Bu nedenle, bu tür istisnaları normal şartlar altında susturabilir, ancak uygulamanızın etrafına dolanmak isteyip istemediğinizi söyleyerek oturum açın.

İstisnai yutmaya karar verirseniz, politikam her zaman neden yaptığını açıklayan bir kod yorumu var; Bu sadece bir başka kötü uygulama değildir.


1
2018-01-26 20:28





Hata düzeltmeleri yapmaya atanan bir çaylak olarak, atandığım belirli hatanın yazdırıldığını (hata ayıklamak için) "Bu asla olmamalıydı" diye keşfettim. Görünüşe göre imkansız olan bir hata durumunda çalışmaktan korktuğumdan sonra, nihayet ince bir yarış koşulunun neden olduğunu keşfetmeyi başardım. Bu kodun yazarı, en azından bu yetersiz hata ayıklama ifadesi olmadan istisnayı basitçe batırmış olsaydı, yarış koşulunu izlemek çok daha zor olurdu.

O zamandan beri istisnalarla uğraşmak ya da hata durumu son kullanıcı için kullanıcı dostu bir şekilde gösterilinceye kadar onları provasyona sokmak için büyük bir taraftar oldum, bir hata ayıklama bildirisinin günlüğe kaydedilmesinden başka bir adım.


1
2018-01-26 23:01