90'lı yılların sonunda, istisnaları akış kontrolü olarak kullanan bir kod tabanı ile biraz çalıştım. Telefon uygulamalarını sürmek için sonlu durumlu bir makine kullandı. Son zamanlarda o günleri hatırlatıyorum çünkü MVC web uygulamaları yapıyorum.

Her ikisinde de Controllernereye gidileceğine karar veren ve verileri hedef mantığa sağlayan karar var . DTMF tonları gibi eski bir telefonun etki alanından gelen kullanıcı eylemleri, eylem yöntemlerine parametre haline geldi, ancak a gibi bir şeyleri geri döndürmek yerine, a ViewResultattılar StateTransitionException.

Bence asıl fark, eylem yöntemlerinin voidfonksiyonlar olduğuydu. Bu gerçekle yaptığım her şeyi hatırlamıyorum ama hatırlama yolunda bile tereddüt ettim, çünkü 15 yıl önce olduğu gibi, bu işin yapım kodunda başka bir işte hiç görmedim . Bunun, sözde bir anti-patern olduğunu gösteren bir işaret olduğunu varsaymıştım.

Durum bu mu ve öyleyse neden?

Güncelleme: soruyu sorduğumda, zaten @ MasonWheeler'in cevabı aklımdaydı, bu yüzden bilgime en çok eklenen cevaba ulaştım. Bence onun da sağlam bir cevabı.

Ward's Wiki'de bununla ilgili ayrıntılı bir tartışma var . Genel olarak, kontrol akışı için istisnaların kullanımı, kayda değer bir durum olan - ve dile özgü ( örneğin Python'a bakınız ) öksürük istisnaları öksürük gibi bir anti- paterndir .

Genel bir neden olarak, bunun bir anti-kalıp olduğu için kısa bir özet:

• İstisnalar, özünde, sofistike GOTO ifadeleridir.
• Bu nedenle, istisnalar dışında programlama kodu okumak ve anlamakta zorlanır
• Çoğu dil istisnalar dışında problemlerinizi çözmek için tasarlanmış kontrol yapılarına sahiptir.
• Verimlilik argümanları, istisnaların kontrol akışı için kullanılmadığı varsayımıyla optimizasyon yapma eğiliminde olan modern derleyiciler için tartışılmaz.

Daha ayrıntılı bilgi için Ward'ın wiki sayfasındaki tartışmayı okuyun.

Ayrıca bu sorunun bir kopyasını da burada görebilirsiniz.

İstisnalar için tasarlanan kullanım durumu, "Bu noktada tam olarak çözemediğim bir durumla karşılaştım, çünkü bununla başa çıkmak için yeterli bağlamım yok, ama beni çağıran rutin (veya çağrıyı devam ettiren bir şey) "nasıl işleneceğini bilmeli."

İkincil kullanım durumu ise “Sadece ciddi bir hatayla karşılaştım ve şu anda veri bozulmalarını veya diğer hasarları önlemek için bu kontrol akışından çıkmak, devam etmeye devam etmekten daha önemli.”

Bu iki nedenden biri için istisnalar kullanmıyorsanız, bunu yapmanın daha iyi bir yolu olabilir.

İstisnalar Devamlılıklar ve kadar güçlüdür GOTO. Onlar evrensel bir kontrol akış yapısıdır.

Bazı dillerde, tek evrensel kontrol akışı yapısıdır. Örneğin, JavaScript'in Devamları yoktur GOTO, Uygun Kuyruk Çağrıları bile yoktur. Dolayısıyla, karmaşık denetim akışını JavaScript'te uygulamak istiyorsanız , İstisnalar'ı kullanmanız gerekir .

Microsoft Volta projesi, keyfi .NET kodunu JavaScript'e derlemek için hazırlanmış bir araştırma projesiydi. .NET, semantikleri JavaScript’le tam olarak eşleşmeyen İstisnalar içeriyor, ancak daha da önemlisi, Konuları var ve bunları bir şekilde JavaScript’le eşlemeniz gerekiyor. Volta bunu JavaScript İstisnalarını kullanarak Volta Devamlarını uygulayarak ve ardından tüm .NET kontrol akışı yapılarını Volta Devam Ediyor olarak uygulayarak yaptı. Onlar vardı çünkü, kontrol akış olarak İstisnalar kullanmak başka hiçbir kontrol akış oluşturmak olduğunu yeterince güçlü.

Devlet Makinelerinden bahsettiniz. SM'ler Doğru Kuyruk Çağrıları ile uygulama için önemsizdir: her durum bir alt yordamdır, her durum bir alt yordamdır. SM'ler ayrıca GOTOveya Coroutines veya Continuations ile kolayca uygulanabilir . Ancak, Java bu dört herhangi yoktur, ancak does İstisnalar var. Bu nedenle kontrol akışı olarak kullanmak tamamen kabul edilebilir. (Aslında, doğru seçim muhtemelen uygun kontrol akışı yapısına sahip bir dili kullanmak olacaktır, ancak bazen Java ile sıkışmış olabilirsiniz.)

Diğerlerinin sayısız şekilde belirttiği gibi ( örneğin, bu Yığın Taşması sorusunda ), en az şaşkınlık ilkesi, yalnızca kontrol akışı amacıyla aşırı istisnalar kullanmanıza izin vermeyecektir. Öte yandan, hiçbir kural% 100 doğru değildir ve her zaman bir istisnanın "sadece doğru araç" olduğu durumlar da vardır - gotobu arada, kendisi gibi, Java biçiminde breakve continueJava gibi dillerde gönderilenler genellikle kaçınılması mümkün olmayan, ağır şekilde yuvalanmış ilmeklerden atlamak için mükemmel bir yoldur.

Aşağıdaki blog yazısı, yerel olmayanlar için oldukça karmaşık ama aynı zamanda oldukça ilginç bir kullanım durumunu açıklıyor ControlFlowException:

• http://blog.jooq.org/2013/04/28/rare-uses-of-a-controlflowexception

Bu nasıl iç açıklar jOOQ (Java için SQL soyutlama kitaplığı) (uyarı: Ben satıcı için çalışmak), bu tür istisnalar bazen bazı "nadir" koşul karşılandığında erken SQL render işlemini iptal etmek için kullanılır.

Bu gibi koşullara örnekler:

• Çok fazla bağlama değeriyle karşılaşıldı. Bazı veritabanları, SQL deyimlerinde rastgele sayıda bağlama değerini desteklemez (SQLite: 999, Ingres 10.1.0: 1024, Sybase ASE 15.5: 2000, SQL Server 2008: 2100). Bu durumlarda, jOOQ, SQL oluşturma aşamasını iptal eder ve SQL ifadesini satır içi bağlama değerleriyle yeniden işler. Örnek:

  // Pseudo-code attaching a "handler" that will
  // abort query rendering once the maximum number
  // of bind values was exceeded:
  context.attachBindValueCounter();
  String sql;
  try {
  
    // In most cases, this will succeed:
    sql = query.render();
  }
  catch (ReRenderWithInlinedVariables e) {
    sql = query.renderWithInlinedBindValues();
  }

  Her seferinde saymak için AST sorgusunun bağlanma değerlerini açıkça çıkarırsak, bu sorundan muzdarip sorguların% 99.9'u için değerli CPU çevrimlerini boşa harcarız.

• Bazı mantık, yalnızca "kısmen" yürütmek istediğimiz bir API üzerinden dolaylı olarak kullanılabilir. Bu UpdatableRecord.store()yöntem , 'iç bayraklarına bağlı olarak bir INSERTveya UPDATEifadesi üretir Record. "Dışardan" ne tür bir mantık içerdiğini bilmiyoruz store()(örneğin, iyimser kilitleme, olay dinleyicisi kullanımı, vb.), Bu nedenle bir toplu iş ifadesinde birkaç kayıt sakladığımızda bu mantığı tekrarlamak istemiyoruz, Burada store()sadece SQL deyimini oluşturmak istedik , aslında onu değil. Örnek:

  // Pseudo-code attaching a "handler" that will
  // prevent query execution and throw exceptions
  // instead:
  context.attachQueryCollector();
  
  // Collect the SQL for every store operation
  for (int i = 0; i < records.length; i++) {
    try {
      records[i].store();
    }
  
    // The attached handler will result in this
    // exception being thrown rather than actually
    // storing records to the database
    catch (QueryCollectorException e) {
  
      // The exception is thrown after the rendered
      // SQL statement is available
      queries.add(e.query());                
    }
  }

  Biz dışlanmışken olsaydı store()isteğe şekilde özelleştirilebilir "Çok kullanımlık" API içine mantığı değil SQL çalıştırmak, neredeyse yeniden kullanılabilir, bakımı oldukça zor API oluşturma içine bakıyor olurduk.

Sonuç

Temelde, bu yerel olmayanları kullanmamız goto, sadece Wheeler’nın cevabında söylediklerinin sınırlarında:

“Bu noktada tam olarak üstesinden gelemediğim bir durumla karşılaştım, çünkü başa çıkacak yeterli bağlamım yok, ama beni (ya da çağrı yığınının yukarısındaki bir şey) olarak adlandıran rutin bunun nasıl başa çıkacağını bilmeli ."

Her iki kullanımının ControlFlowExceptionsda alternatiflerine göre uygulanması oldukça kolaydı, bu da geniş bir mantığın tekrar kullanılmasına gerek kalmadan ilgili içsellerin dışına çıkarılmamızı sağladı.

Ancak bunun gelecekteki bakımcılar için biraz sürpriz olduğu hissi devam ediyor. Kod oldukça hassas hissediyor ve bu durumda doğru seçim olsa da, sıradan dallanma kullanmaktan kaçınmanın kolay olduğu yerel kontrol akışı için istisnalar kullanmamayı her zaman tercih ederiz if - else.

Kontrol akışı için istisnaların kullanılması genellikle bir anti-desen olarak kabul edilir, ancak istisnalar da vardır (punto amaçlanmamıştır).

İstisnaların istisnai durumlar için kullanıldığı binlerce kez söylenmiştir. Kırık bir veritabanı bağlantısı olan olağanüstü bir durumdur. Bir giriş alanına yalnızca rakamlara izin vermesi gereken harfleri giren bir kullanıcı değildir .

Bir işlevi neden senin yazılımındaki bir hata, örneğin yasadışı argümanlarla çağrılacak nulldeğil, izin verir nerede olduğunu istisnai bir durumdur.

İstisnai olmayan bir şey için istisnalar kullanarak, çözmeye çalıştığınız sorun için uygun olmayan soyutlamaları kullanıyorsunuzdur.

Ancak performans cezası da olabilir. Bazı dillerde az ya da çok etkili istisna işleme uygulaması vardır, bu nedenle tercih ettiğiniz dil etkin istisna işleme sahip değilse, performans açısından çok maliyetli olabilir *.

Ancak diğer dillerde, örneğin Ruby, kontrol akışı için istisna benzeri bir sözdizimine sahiptir. İstisnai durumlar raise/ rescueoperatörler tarafından ele alınmaktadır . Ancak istisna benzeri kontrol akış yapıları için throw/ kullanabilirsiniz catch.

Bu nedenle, istisnalar genel olarak kontrol akışı için kullanılmamasına rağmen , tercih ettiğiniz dilin başka deyimleri olabilir.

* İstisnai olarak pahalı bir performans kullanımı örneği: Kötü performans gösteren bir ASP.NET Web Form uygulamasını optimize etmek üzere ayarlanmış bir kez. Büyük bir masanın renderlenmesinin int.Parse()yakl. ortalama bir sayfada bin boş dizge, sonuçta yaklaşık. Bin istisnalar ele alınıyor. Kodu değiştirerek int.TryParse()bir saniye tıraş oldum! Her sayfa talebi için!

** Bu, her iki gibi diğer dillerden Ruby gelen bir programcı için çok kafa karıştırıcı olabilir throwve catchdiğer birçok dilde istisnalar ile ilişkili anahtar kelimelerdir.

İstisnalar kullanılmadan hata koşullarının üstesinden gelmek tamamen mümkündür. En önemlisi C olan bazı dillerin bile istisnaları yoktur ve insanlar hala onunla oldukça karmaşık uygulamalar oluşturmayı başarırlar. İstisnaların faydalı olmasının nedeni, aynı kodda temelde bağımsız iki kontrol akışını kesin olarak belirlemenizi sağlar: biri bir hata oluşursa ve diğeri olmazsa. Onlar olmadan, şuna benzeyen her yere kod girersiniz:

status = getValue(&inout);
if (status < 0)
{
    logError("message");
    return status;
}

doSomething(*inout);

Veya kendi dilinizde eş değer, örneğin bir hata durumu olarak bir değere sahip bir tuple döndürmek ifgibi İstisnaları kullanmayın.

Bu desen en çok hataları veya diğer "istisnai koşulları" ele alırken ortaya çıksa da, bence başka durumlarda bu gibi bir boyler kodunu görmeye başlarsanız, istisnaları kullanmak için oldukça iyi bir tartışmanız var. Duruma ve uygulamaya bağlı olarak, bir durum makinesinde geçerli olan istisnaları görebiliyorum, çünkü iki ortogonal kontrol akışınız var: biri durumu değiştiren ve biri eyalet içinde meydana gelen olaylar için.

Bununla birlikte, bu durumlar nadirdir ve kuralın istisnasını (amaçlanan şekilde) yapacaksanız, üstünlüğünü diğer çözümlere göstermek için daha iyi hazır olmalısınız. Bu gerekçesiz bir sapmaya haklı olarak anti-patern denir.

Python'da, özel durumlar üreteç ve yineleme sonlandırma için kullanılır. Python'un blokları hariç / denemek için çok verimli denemesi var, fakat aslında bir istisna yaratmanın bazı ek yükü var.

Python'da çok seviyeli kırılmalar ya da çoktan açık bir ifade olmamasından dolayı bazen istisnalar kullandım:

class GOTO(Exception):
  pass

try:
  # Do lots of stuff
  # in here with multiple exit points
  # each exit point does a "raise GOTO()"
except GOTO:
  pass
except Exception as e:
  #display error

Böyle bir İstisna kullanımı taslağını çizelim:

Algoritma bir şey bulunana kadar tekrarlı olarak arama yapar. Bu nedenle, özyinelemeden geri dönmenin sonucun bulunup bulunmadığını kontrol etmesi ve geri dönmesi gerekir, aksi takdirde devam edin. Ve bu tekrar tekrar bazı özyineleme derinliklerinden geri geliyor.

Fazladan bir boole ihtiyaç duymanın yanı sıra found(aksi takdirde sadece int'nin geri verilebileceği bir sınıfta paketlenecek) ve özyineleme derinliği için aynı postlude olur.

Bir çağrı yığınının böyle bir gevşetilmesi, bunun istisnasının tam olarak nedenidir. Bu yüzden bana benzeyen, daha acil ve uygun bir kodlama aracı gibi görünüyor. Gerek yok, nadir kullanım, belki kötü stil, ama noktaya. Prolog kesim işlemi ile karşılaştırılabilir.

Programlama işle ilgili

Buna cevap vermenin en kolay yolunun, OOP'un yıllar içindeki ilerlemesini anlamak olduğunu düşünüyorum. OOP'de yapılan her şey (ve bu konuda çoğu programlama paradigması) yapılan işe ihtiyaç duyulması üzerine modellenmiştir .

Her ne zaman bir yöntem çağrılırsa, arayan kişi “Bu işi nasıl yapacağımı bilmiyorum ama nasıl yapacağını biliyorsun, bu yüzden benim için yapıyorsun” diyor.

Bu bir zorluk sundu: çağrılan yöntem genellikle işin nasıl yapıldığını bildiğinde ne olur? Biz iletişim kurmak için bir yol gerekli "Sana yardım etmek istedim, gerçekten yaptım, ama sadece bunu yapamam."

Bunu iletmenin erken bir metodolojisi basitçe bir "çöp" değeri vermekti. Belki olumlu bir tamsayı bekliyorsunuz, bu nedenle çağrılan yöntem negatif bir sayı döndürüyor. Bunu başarmanın başka bir yolu, bir yerde bir hata değeri ayarlamaktı. Ne yazık ki, her iki yol da kazan plakasında, her şeyin şifresiz kodunu kontrol etmeme izin verdi . İşler daha karmaşık hale geldikçe, bu sistem dağılıyor.

Olağanüstü Bir Analoji

Diyelim ki bir marangoz, tesisatçı ve elektrikçiniz var. Lavabonuzu tamir etmek için tesisatçı olmak istiyorsunuz, o da ona bir göz attı. Yalnızca size, "Üzgünüm, düzeltemem. Bozuldu." Demesi yararlı olmaz. Cehennem, bakması, ayrılması ve düzeltemeyeceğini söyleyen bir mektup göndermesi daha da kötü. Şimdi istediğini yapmadığını bile bilmeden önce postanı kontrol etmelisin.

Tercih edeceğiniz şey, “Bak, tamir edemedim çünkü pompanız çalışmıyor gibi görünüyor” demesini sağlamak.

Bu bilgilerle, elektrik teknisyeninin soruna bakmasını istediğiniz sonucuna varabilirsiniz. Belki elektrikçi marangoz ile ilgili bir şeyler bulacaktır ve marangozun tamir etmesini sağlamalısınız.

Heck, bir elektrikçiye ihtiyacınız olduğunu bile bilmiyor olabilirsiniz, kime ihtiyacınız olduğunu bilmiyor olabilirsiniz . Bir ev tamir işinde sadece orta düzey bir yöneticisiniz ve odak noktalarınız sıhhi tesisat. Yani size sorun hakkında ediyoruz patronuna söyle, sonra o bunu düzeltmek için elektrikçi söyler.

İstisnaların modellendiği şey budur: ayrık bir tarzda karmaşık arıza modları. Tesisatçının elektrik teknisyeni hakkında bir bilgisi olması gerekmez - zincirdeki birisinin sorunu çözebileceğini bile bilmesi gerekmez. Sadece karşılaştığı sorunu bildirir.

Yani ... bir anti-pattern?

Ok, bu nedenle anlayış noktası istisnalar ilk adımdır. Bir sonraki anti-paternin ne olduğunu anlamaktır.

Bir anti-kalıp olarak nitelenmek için,

• problemi çöz
• kesin olumsuz sonuçları var

İlk nokta kolayca karşılanır - sistem çalıştı, değil mi?

İkinci nokta stickier. İstisnaları normal kontrol akışı olarak kullanmanın birincil nedeni kötü, çünkü amaçları değil. Bir programdaki herhangi bir işlevsellik parçasının göreceli olarak net bir amacı olmalı ve bu amaç için işbirliği yapılması gereksiz kafa karışıklığına yol açmalıdır.

Ama bu kesin bir zarar değil . İşleri yapmak için kötü bir yol ve garip, ama bir anti-patern? Hayır. Sadece ... garip.