"Baş İlk Python" kitabını inceliyorum (bu sene öğrenmek benim dilim) ve iki kod tekniği hakkında tartıştıkları bir bölüme geçtim:
İlkine Karşı İstisna işleme konusunu kontrol ediyorum .

İşte Python kodunun bir örneği:

# Checking First
for eachLine in open("../../data/sketch.txt"):
    if eachLine.find(":") != -1:
        (role, lineSpoken) = eachLine.split(":",1)
        print("role=%(role)s lineSpoken=%(lineSpoken)s" % locals())

# Exception handling        
for eachLine in open("../../data/sketch.txt"):
    try:
        (role, lineSpoken) = eachLine.split(":",1)
        print("role=%(role)s lineSpoken=%(lineSpoken)s" % locals())
    except:
        pass

İlk örnek doğrudan .splitişlevdeki bir problemle ilgilidir . İkincisi, istisna eylemcisinin onunla ilgilenmesine izin verir (ve sorunu yok sayar).

Kitapta, ilk önce kontrol etmek yerine istisna işlemeyi kullanmayı savunuyorlar. Argüman, istisna kodunun tüm hataları yakalayacağı ve ilk önce kontrol etmenin sadece düşündüğünüz şeyleri yakalayacağı (ve köşe davalarını özleyeceğiniz). Önce kontrol etmem öğretildi, bu yüzden içgüdülerim bunu yapmaktı, ama fikirleri ilginçti. Davalarla uğraşmak için istisna işlemeyi kullanmayı hiç düşünmedim.

Bu ikisinden hangisinin genel olarak daha iyi uygulama olduğu düşünülmektedir?

.NET'te, Özel Durumların aşırı kullanılmasından kaçınmak yaygın bir uygulamadır. Bir argüman performanstır: .NET'te bir istisna atmak hesap açısından pahalıdır.

Aşırı kullanımlarından kaçınmanın bir başka nedeni de, bunlara çok güvenen kodları okumanın çok zor olabileceğidir. Joel Spolsky'nin blog girişi , konuyu tanımlamak için iyi bir iş çıkarıyor.

Argümanın merkezinde şu alıntı var:

Sebep, istisnaların 1960'lardan bu yana zararlı olarak kabul edilen "birinciden" daha iyi olmadığını düşündüğüm için, kodun bir noktasından diğerine ani bir sıçrama oluşturmalarıdır. Aslında goto'nunkinden çok daha kötü:

1. Kaynak kodda görünmezler . İstisnalar atıp durmayacak fonksiyonlar dahil olmak üzere bir kod bloğuna baktığımızda, hangi istisnaların atılabileceğini ve hiçbir yerden atılabileceğini görmenin bir yolu yoktur. Bu, dikkatli bir kod incelemesinin bile olası hataları ortaya çıkarmaması anlamına gelir.

2. Bir fonksiyon için çok fazla olası çıkış noktası yaratırlar . Doğru kodu yazmak için, fonksiyonunuzdaki olası her kod yolunu düşünmeniz gerekir. Ne zaman bir istisna yaratabilecek ve onu anında yakalayamayacak bir işlev çağırırsanız, aniden sonlanan işlevlerin neden olduğu sürpriz hataları, verileri tutarsız bir durumda ya da yapmadığınız diğer kod yollarında bırakabilirsiniz. hakkında düşün.

Şahsen, kodumun yapmayı taahhüt ettiği şeyi yapamadığı durumlarda istisnalar atarım. Bir SOAP çağrısı, bir veritabanı çağrısı, dosya IO veya bir sistem çağrısı gibi işlem sınırımın dışındaki bir şeyle uğraşmak üzereyken try / catch kullanmaya meyilliyim. Aksi takdirde, savunmaya kod koymaya çalışıyorum. Zor ve hızlı bir kural değil, fakat genel bir uygulamadır.

Scott Hanselman ayrıca burada .NET'teki istisnalar hakkında da yazıyor . Bu makalede, istisnalar hakkında birkaç temel kural tanımlamaktadır. Benim favorim?

Her zaman olan şeyler için istisnalar atmamalısın. O zaman "sıradan" olacaklardı.

Özellikle Python'da, istisnayı yakalamak için genellikle daha iyi bir uygulama olarak kabul edilir. Bu denilen olsun eğilimindedir mağfiret daha izin isteyin daha kolay , (EAFP) You Leap (LBYL) Önce Bakın kıyasla. LBYL'in bazı durumlarda ince böceklere neden olacağı durumlar vardır.

Bununla birlikte, her ikisi de hataları maskeleyebileceği için, ifadeler hariç aşırı beyanların yanı sıra çıplak except:ifadelere de dikkat edin - bunun gibi bir şey daha iyi olurdu:

for eachLine in open("../../data/sketch.txt"):
    try:
        role, lineSpoken = eachLine.split(":",1)
    except ValueError:
        pass
    else:
        print("role=%(role)s lineSpoken=%(lineSpoken)s" % locals())

Pragmatik Bir Yaklaşım

Savunmalı olmalısın ama bir noktaya. İstisna işlemeyi bir noktaya yazmalısınız. Web programlamayı örnek olarak kullanacağım çünkü yaşadığım yer burası.

1. Tüm kullanıcı girişlerinin kötü olduğunu ve sadece veri tipi doğrulama, kalıp kontrolleri ve kötü amaçlı enjeksiyon noktalarına savunma yazdığını varsayınız. Savunma programlaması, kontrol edemeyeceğiniz, çok sık meydana gelebilecek şeyler olmalıdır.
2. Zaman zaman başarısız olabilecek ve kullanıcı geri bildirimleri için incelikle ele alınabilecek ağ hizmetleri için istisna işleme yazın. İstisna programlama, zaman zaman başarısız olabilecek fakat genellikle sağlam olan ağ bağlantılı şeyler için kullanılmalıdır VE programınızın çalışmaya devam etmesi gerekir.
3. Giriş verileri doğrulandıktan sonra uygulamanızın içine savunma yazmak için canınızı sıkmayın. Onun zaman kaybı ve uygulamanızı şişiriyor. Havaya uçmasına izin verin, çünkü ya taşınmaya değmeyecek çok nadir bir şey ya da adım 1 ve 2'ye daha dikkatli bakmanız gerektiği anlamına gelir.
4. Asla kodunuzda ağa bağlı bir cihaza bağlı olmayan bir istisna işleme asla yazmayın. Bunu yapmak kötü programlama ve performans açısından maliyetlidir. Örneğin, bir döngüde sınırların dışında bir dizi durumunda bir try-catch yazmak, bu döngüyü ilk etapta doğru şekilde programlayamadığınız anlamına gelir.
5. Yukarıdaki prosedürleri takip ettikten sonra bir yerde istisnaları yakalayan merkezi hata kaydıyla her şeyin ele alınmasına izin verin. Sınırsız olabileceğinden her kenar durumunu yakalayamazsınız, yalnızca beklenen işlemi yapan bir kod yazmanız yeterlidir. Bu nedenle, merkezi hata işlemeyi son çare olarak kullanıyorsunuz.
6. TDD güzel çünkü bir bakıma sizi rahatsız hissetmeyi deniyor, bu da size normal çalışmanın güvencesini veriyor.
7. Bonus puanları bir kod kapsamı aracı kullanmaktır ; örneğin İstanbul, test etmediğiniz yeri gösterirken, düğüm için iyi bir seçimdir.
8. İkaz tüm bu etmektir geliştirici dostu istisnalar . Örneğin, sözdizimini yanlış kullanırsanız bir dil fırlatır ve bunun nedenini açıklarsınız. Yardımcı programınız , kodunuzun büyük kısmının dayandığı kitaplıkları da içermelidir .

Bu, büyük takım senaryolarında çalışma deneyiminden kaynaklanıyor.

Bir Analoji

ISS ALL içinde zaman içinde bir takım elbise giyip giymediğinizi düşünün. Tuvalete gitmek ya da yemek yemek zor olurdu. Hareket etmek, uzay modülünün içinde çok hantal olurdu. Berbat olurdu. Kodunuzun içine bir sürü deneme yazma yazmak böyle bir şey. Söyleyeceğiniz bir noktaya sahip olmalısınız, hey, ISS'yi güvence altına aldım ve içerideki astronotlarım tamam, bu yüzden olabilecek her senaryo için bir uzay giysisi giymek pratik değil.

Kitabın ana argümanı, kodun istisna sürümünün daha iyi olduğudur; çünkü kendi hata kontrolünüzü yazmaya çalıştıysanız, göz ardı edebileceğiniz herhangi bir şeyi yakalayacaktır.

Bence bu ifade sadece çok özel durumlarda doğrudur - çıktıların doğru olup olmadığına aldırmıyorsanız.

Hiç şüphesiz istisnaları yükseltmenin sağlıklı ve güvenli bir uygulamadır. Bunu, programın şu anki durumunda (geliştirici olarak) başa çıkamayacağınız veya uğraşmak istemediğiniz bir şey olduğunu hissettiğinizde yapmanız gerekir.

Bununla birlikte, örneğin, istisnalar yakalamakla ilgilidir . Bir istisna yakalamak, konum değil gözden kaçırdığınız bir senaryoları kendinizi korumak. Tam tersini yapıyorsunuz: bu tür istisnalara neden olabilecek herhangi bir senaryoyu gözden kaçırmadığınızı varsayıyorsunuz ve bu nedenle onu yakalamanın doğru olduğundan emin olduğunuzdan (ve böylece programın çıkmasına neden olmasını engellediğinizden, yakalanmayan istisnalar gibi).

İstisna yaklaşımını kullanarak, istisna görürseniz ValueError, bir satırı atlarsınız. Geleneksel istisna dışı yaklaşımını kullanarak, döndürülen değerlerin sayısını sayarsınız splitve 2'den küçükse bir satır atlarsınız. İstisna yaklaşımı konusunda kendinizi daha güvende hissetmelisiniz, çünkü geleneksel hata kontrolünüzdeki bazı diğer "hata" durumlarını unutmuş olabilirsiniz ve except ValueErroronları sizin için yakalar mı?

Bu, programınızın doğasına bağlıdır.

Örneğin, bir web tarayıcısı veya video oynatıcısı yazıyorsanız, girişlerle ilgili bir sorun, yakalanmamış bir istisna ile kilitlenmesine neden olmamalıdır. Uzaktan mantıklı bir şey çıkarıp bırakmaktan çok daha iyidir (kesinlikle, kesinlikle yanlış konuşsa bile).

Doğruluğun önemli olduğu bir uygulama yazıyorsanız (iş veya mühendislik yazılımı gibi), bu korkunç bir yaklaşım olacaktır. Yükselen bazı senaryoları unutursanız ValueError, yapabileceğiniz en kötü şey, bu bilinmeyen senaryoyu sessizce görmezden gelmek ve sadece çizgiyi atlamaktır. Bu, yazılımda çok ince ve pahalı böceklerin ortaya çıkmasıdır.

ValueErrorBu kodda görmenin tek yolunun splitsadece bir değer (iki yerine) döndürülmesi olduğunu düşünebilirsiniz . Ancak print, ifadeniz daha sonra ValueErrorbazı koşullar altında yükselten bir ifade kullanmaya başlarsa ne olur ? Bu, bazı satırları atlamanıza neden olur, :çünkü özledikleri için değil , printbaşarısız oldukları için. Bu daha önce bahsettiğim ince bir hata örneği - hiçbir şey farketmezsiniz, sadece bazı satırları kaybedersiniz.

Benim tavsiyem, hatalı çıktı üretmenin çıkıştan daha kötü olduğu koddaki istisnaları yakalamaktan (ancak yükseltme yapmamaktan) kaçınmaktır. Böyle bir kodda bir istisna yakalayabildiğim tek zaman, gerçekten önemsiz bir ifadeye sahip olduğum zamandır, bu nedenle olası istisna türlerinin her birine neyin sebep olabileceğine kolayca sebep olabilirim.

İstisnalar kullanılmasının performansa etkisi ile ilgili olarak, istisnalar sıkça karşılaşılmadıkça önemsizdir (Python'da).

Rutin olarak ortaya çıkan koşulları işlemek için istisnalar kullanırsanız, bazı durumlarda çok büyük bir performans maliyeti ödeyebilirsiniz. Örneğin, uzaktan bir komut çalıştırdığınızı varsayalım. Komut metninizin en azından minimum doğrulamayı geçtiğini kontrol edebilirsiniz (örneğin, sözdizimi). Veya bir istisnanın ortaya çıkmasını bekleyebilirsiniz (yalnızca uzaktaki sunucu komutunuzu ayrıştırdıktan ve bununla ilgili bir sorun bulduktan sonra gerçekleşir). Açıkçası, eski büyüklük emirleri daha hızlıdır. Başka bir basit örnek: Bir sayıyı bölmeyi çalıştırmaya çalışmaktan ve ZeroDivisionError istisnasını yakalamaktan sıfır ~ 10 kat daha hızlı olup olmadığını kontrol edebilirsiniz.

Bu hususlar yalnızca uzak sunuculara sıklıkla hatalı biçimlendirilmiş komut dizeleri gönderirseniz veya bölme için kullandığınız sıfır değerli değişkenleri alırsanız önemlidir.

Not: Sadece except ValueErrorbunun yerine kullanacağınızı varsayıyorum except; Diğerlerinin dediği gibi, kitabın da birkaç sayfada söylediği gibi, asla çıplak kullanmamanız gerekir except.

Başka bir not: Özel istisna dışı yaklaşım, splitaramak yerine geri döndürülen değerlerin sayılmasıdır :. İkincisi çok yavaş, çünkü yaptığı işi tekrarlıyor splitve uygulama süresini neredeyse iki katına çıkarabiliyor.

Genel bir kural olarak, bir ifadenin geçersiz bir sonuç üretebileceğini biliyorsanız, bunun için test edin ve onunla ilgilenin. Beklemediğiniz şeyler için istisnalar kullanın; "istisnai" olan şeyler. Sözleşmeyi sözleşmeye göre daha açık hale getirir (örnek olarak "boş olmamalıdır").

Şimdiye kadar neyin iyi çalıştığını kullanın.

• seçtiğiniz programlama dilini kod okunabilirliği ve verimliliği açısından
• ekibiniz ve kabul edilen kod sözleşmeleri

İstisna işleme ve savunma programlarının her ikisi de aynı amacı ifade etmenin farklı yollarıdır.

TBH, try/excepttamirci ya da ififade kontrolü kullanmanız önemli değil . Genellikle çoğu Python taban çizgisinde EAFP ve LBYL'yi görürsünüz, EAFP biraz daha yaygındır. Bazen EAFP olduğunu çok daha okunabilir / deyimsel, ancak bu özel durumda ben her iki durumda da ince olduğunu düşünüyorum.

Ancak...

Mevcut referansınızı kullanırken dikkatli olurdum. Birkaç göz kamaştırıcı kod kendi kuralları ile:

1. Dosya tanımlayıcısı sızdırılmış. Modern CPython sürümleri ( belirli bir Python yorumlayıcısı) aslında onu kapatacak, çünkü yalnızca döngü sırasında kapsamı olan anonim bir nesne (gc onu döngüden sonra çeker). Ancak, diğer tercümanlar bu garantiye sahip değildir . Tanımlayıcıyı tamamen sızdırabilirler. withPython'da dosyaları okurken deyimi kullanmak her zaman ister : çok az istisna vardır. Bu onlardan biri değil.
2. Pokemon istisna işleme, hataları maskelerken kaşlarını çatır ( exceptbelirli bir istisnayı yakalamayan çıplak bir ifade)
3. Nit: Paket açma işlemi için parens gerekmez. Sadece yapabilirrole, lineSpoken = eachLine.split(":",1)

Ivc, bu ve EAFP hakkında iyi bir cevaba sahip, ancak tanımlayıcıyı da sızdırıyor.

LBYL versiyonu mutlaka EAFP versiyonunun performansı kadar değildir, bu yüzden istisnaları atmanın "performans açısından pahalı" olduğunu söylemek kategorik olarak yanlıştır. Bu gerçekten işlediğiniz dizelerin türüne bağlıdır:

In [33]: def lbyl(lines):
    ...:     for line in lines:
    ...:         if line.find(":") != -1:
    ...:             # Nuke the parens, do tuple unpacking like an idiomatic Python dev.
    ...:             role, lineSpoken = line.split(":",1)
    ...:             # no print, since output is obnoxiously long with %timeit
    ...:

In [34]: def eafp(lines):
    ...:     for line in lines:
    ...:         try:
    ...:             # Nuke the parens, do tuple unpacking like an idiomatic Python dev.
    ...:             role, lineSpoken = eachLine.split(":",1)
    ...:             # no print, since output is obnoxiously long with %timeit
    ...:         except:
    ...:             pass
    ...:

In [35]: lines = ["abc:def", "onetwothree", "xyz:hij"]

In [36]: %timeit lbyl(lines)
100000 loops, best of 3: 1.96 µs per loop

In [37]: %timeit eafp(lines)
100000 loops, best of 3: 4.02 µs per loop

In [38]: lines = ["a"*100000 + ":" + "b", "onetwothree", "abconetwothree"*100]

In [39]: %timeit lbyl(lines)
10000 loops, best of 3: 119 µs per loop

In [40]: %timeit eafp(lines)
100000 loops, best of 3: 4.2 µs per loop

Temelde İstisna işlemenin OOP dilleri için daha uygun olması gerekiyordu.

İkincisi, performans, çünkü eachLine.findher satır için çalıştırmanız gerekmez .

Bence savunma programlaması performansı incitiyor. Ayrıca yalnızca işleyeceğiniz istisnaları da yakalamalısınız, çalışma zamanının nasıl idare edeceğinizi bilmediğiniz istisna ile ilgilenmesine izin verin.