Elm'in iddia ettiği gibi “çalışma zamanı istisnası yok” unun avantajı nedir?

Bazı diller "diğer çalışma zamanı istisnaları" bulunmadığını ve bu dillere sahip diğer diller için açık bir avantaj olduğunu iddia etmektedir.

Bu konuda kafam karıştı.

Çalışma zamanı istisnası bildiğim kadarıyla ve iyi kullanıldığında sadece bir araçtır:

• "kirli" durumları iletebilirsiniz (beklenmedik verilere atarak)
• yığın ekleyerek hata zincirine işaret edebilirsiniz
• karmaşa (ör. geçersiz girişte boş bir değer döndürme) ve geliştiricinin dikkatini gerektiren güvenli olmayan kullanım (örneğin geçersiz girdide istisna atma) arasında ayrım yapabilirsiniz
• hata ayıklama çabalarına yardımcı olacak daha fazla yararlı ayrıntı sağlayan özel durum mesajı ile hatanıza ayrıntı ekleyebilirsiniz (teorik olarak)

Diğer yandan, istisnaları "yutan" bir yazılımda hata ayıklamak gerçekten zor. Örneğin

try { 
  myFailingCode(); 
} catch {
  // no logs, no crashes, just a dirty state
}

Yani soru şu: "çalışma zamanı istisnası yok" un güçlü ve teorik avantajı nedir?

Misal

https://guide.elm-lang.org/

Uygulamada çalışma zamanı hatası yok. Boş değil. Tanımlanmamış hiçbir işlev değildir.

İstisnalar çok sınırlayıcı anlambilime sahiptir. Tam olarak atıldıkları yere veya doğrudan çağrı yığınına yukarı doğru işlenmelidirler ve derleme zamanında programcıya herhangi bir gösterge yoktur.

Bunu, hataların her ikisi de değer olan Sonuçlar veya Maybes olarak kodlandığı Elm ile karşılaştırın . Bu, hatayı işlemezseniz bir derleyici hatası aldığınız anlamına gelir. Kullanımlarını uygun bir zamana ertelemek için bunları bir değişkente veya hatta bir koleksiyonda saklayabilirsiniz. Hataları, her yerde çok benzer try-catch bloklarını tekrarlamak yerine uygulamaya özgü bir şekilde işlemek için bir işlev oluşturabilirsiniz. Onları sadece tüm parçaları başarılı olduğunda başarılı olan bir hesaplamaya zincirleyebilirsiniz ve bunların tek bir deneme bloğuna sıkıştırılması gerekmez. Yerleşik sözdizimi ile sınırlı değilsiniz.

Bu "istisnaları yutma" gibi bir şey değildir. Tür sisteminde hata koşullarını açıkça ortaya koyuyor ve bunları ele almak için çok daha esnek alternatif anlambilim sağlıyor.

Aşağıdaki örneği ele alalım. Eğer eylemde görmek istiyorsanız bunu http://elm-lang.org/try içine yapıştırabilirsiniz .

import Html exposing (Html, Attribute, beginnerProgram, text, div, input)
import Html.Attributes exposing (..)
import Html.Events exposing (onInput)
import String

main =
  beginnerProgram { model = "", view = view, update = update }

-- UPDATE

type Msg = NewContent String

update (NewContent content) oldContent =
  content

getDefault = Result.withDefault "Please enter an integer" 

double = Result.map (\x -> x*2)

calculate = String.toInt >> double >> Result.map toString >> getDefault

-- VIEW

view content =
  div []
    [ input [ placeholder "Number to double", onInput NewContent, myStyle ] []
    , div [ myStyle ] [ text (calculate content) ]
    ]

myStyle =
  style
    [ ("width", "100%")
    , ("height", "40px")
    , ("padding", "10px 0")
    , ("font-size", "2em")
    , ("text-align", "center")
    ]

Not String.toIntiçinde calculateişlevin başarısız imkanına sahiptir. Java'da bunun bir çalışma zamanı istisnası atma potansiyeli vardır. Kullanıcı girdisini okurken, oldukça iyi bir şansı vardır. Elm bunun yerine beni geri dönerek onunla başa çıkmaya zorluyor Result, ama hemen onunla uğraşmak zorunda olmadığımı fark et. Girişi iki katına çıkarabilir ve bir dizeye dönüştürebilirim, sonragetDefault işlevde kötü giriş olup olmadığını kontrol edebilirim . Burası, kontrol için hatanın oluştuğu noktadan veya çağrı yığınında yukarı doğru çok daha uygundur.

Derleyicinin elimizi zorlama şekli de Java'nın denetlenen istisnalarından çok daha incedir. İstediğiniz Result.withDefaultdeğeri ayıklamak gibi çok özel bir işlev kullanmanız gerekir . Teknik olarak bu tür bir mekanizmayı kötüye kullanabilmenize rağmen, pek bir anlamı yoktur. Yapacağınız iyi bir varsayılan / hata mesajını öğreninceye kadar kararı erteleyebileceğiniz için, kullanmamanız için hiçbir neden yoktur.

Bu ifadeyi anlamak için öncelikle statik tip bir sistemin bize ne satın aldığını anlamalıyız. Esasen, statik tip bir sistemin bize verdiği şey bir garantidir: program tipi kontrol edilirse , belirli bir çalışma zamanı davranışı sınıfı meydana gelemez.

Kulağa iğrenç geliyor. Tip denetleyicisi teorem denetleyicisine benzer. (Aslında, Curry-Howard-İzomorfizme göre onlar aynı şeydir.) Teoremler hakkında çok tuhaf olan bir şey, bir teoremi kanıtladığınızda, teoremin ne söylediğini, artık daha fazla kanıtlamadığınızdır. (Örneğin, neden biri "Bu programı doğruladım kanıtladı" derse, her zaman "lütfen 'doğru' tanımlayın" diye sormalısınız.) Aynı şey tip sistemler için de geçerlidir. Biz dediğimizde ise ne anlama geldiğini, "Bir program tipi-güvenlidir" değil hiçbir olası hata oluşabilir. Sadece tip sisteminin bize önlemeyi vaat ettiği hataların meydana gelemeyeceğini söyleyebiliriz.

Böylece, programların sonsuz sayıda farklı çalışma zamanı davranışı olabilir. Bunlardan, sonsuz sayıda yararlıdır, ancak sonsuz sayıda birçok "yanlıştır" (çeşitli "doğruluk" tanımları için). Statik tip bir sistem, sonsuz sayıda yanlış çalışma zamanı davranışının belirli bir sonlu, sabit setinin meydana gelemeyeceğini kanıtlamamıza izin verir.

Farklı tip sistemler arasındaki fark, temel olarak hangi, kaç tane ve ne kadar karmaşık çalışma zamanı davranışlarının gerçekleşmediğini kanıtlayabilmesidir. Java gibi zayıf tip sistemler yalnızca çok temel şeyleri kanıtlayabilir. Örneğin, Java, döndüren olarak yazılan bir yöntemin a Stringdöndüremeyeceğini kanıtlayabilir List. Ama, örneğin, bu olabilir değil yöntem döndürmez olmayacağını kanıtlıyor. Yöntemin bir istisna atmayacağını da kanıtlayamaz. Ve yanlış döndürmeyeceğini kanıtlayamaz String - herhangi Stringbiri tip denetleyicisini tatmin edecektir. (Ve tabii ki, hatta nullaynı zamanda onu tatmin edecektir.) Java ispat edemez bile çok basit şeyler vardır, biz gibi istisnalar neden olan ArrayStoreException, ClassCastExceptionya da herkesin en sevdiği, NullPointerException.

Agda gibi daha güçlü yazım sistemleri de "iki argümanın toplamını döndürür" veya "argüman olarak aktarılan listenin sıralı halini döndürür" gibi şeyleri kanıtlayabilir.

Şimdi, Elm tasarımcılarının çalışma zamanı istisnaları olmadığı ifadesiyle ne anlama geldiği, Elm'in tip sisteminin, diğer dillerde gerçekleşmediği kanıtlanamayan ve dolayısıyla yol gösterebileceği çalışma zamanı davranışlarının (önemli bir kısmı) olmadığını kanıtlayabileceğidir. çalışma zamanında hatalı davranışa (en iyi durumda bir istisna anlamına gelir, en kötü durumda bir çarpışma anlamına gelir ve en kötü durumda çarpışma, istisna ve sadece sessizce yanlış bir sonuç anlamına gelir).

Yani, onlar vardır değil "biz istisnalar uygulamak değil" diyerek. "Elm'e gelen tipik programcıların deneyimleyeceği tipik dillerde çalışma zamanı istisnaları olacak şeyler, tür sistemi tarafından yakalanıyor" diyorlar. Tabii ki, Idris, Agda, Guru, Epigram, Isabelle / HOL, Coq veya benzer dillerden gelen biri, Elm'i karşılaştırıldığında oldukça zayıf görecektir. İfade daha çok tipik Java, C♯, C ++, Objective-C, PHP, ECMAScript, Python, Ruby, Perl,… programcılarına yöneliktir.

Elm aynı nedenden dolayı çalışma zamanı istisnasını garanti edemez C aynı zamanda çalışma zamanı istisnasını garanti edemez: Dil istisnalar kavramını desteklemez.

Elm'in çalışma zamanında hata durumlarını bildirmenin bir yolu vardır, ancak bu sistem istisna değildir, "Sonuçlar" dır. Başarısız olabilecek bir işlev, normal bir değer veya hata içeren bir "Sonuç" döndürür. Elms güçlü bir şekilde yazılmıştır, bu nedenle bu tür sistemde açıktır. Bir işlev her zaman bir tamsayı döndürürse, türüne sahiptir Int. Ancak, bir tamsayı döndürürse veya başarısız olursa, dönüş türü olur Result Error Int. (Dize hata iletisidir.) Bu, sizi çağrı sitesinde her iki durumu da açıkça işlemeye zorlar.

Girişten bir örnek (biraz basitleştirilmiş):

view : String -> String 
view userInputAge =
  case String.toInt userInputAge of
    Err msg ->
        text "Not a valid number!"

    Ok age ->
        text "OK!"

toIntGiriş ayrıştırılamazsa işlev başarısız olabilir, bu nedenle dönüş türü olur Result String int. Gerçek tamsayı değerini elde etmek için, desen eşleştirme yoluyla "paketini açmanız" gerekir; bu da sizi her iki durumu da ele almaya zorlar.

Sonuçlar ve istisnalar temelde aynı şeyi yapar, önemli fark "temerrütler" dir. İstisnalar programı varsayılan olarak patlatacak ve sonlandıracaktır ve bunları işlemek istiyorsanız bunları açıkça yakalamanız gerekir. Sonuç başka bir yol - varsayılan olarak bunları işlemek zorundasınız, bu yüzden programı sonlandırmalarını istiyorsanız, bunları en üste kadar açık bir şekilde geçirmeniz gerekir. Bu davranışın nasıl daha sağlam koda yol açabileceğini görmek kolaydır.

İlk olarak, "yutma" istisna örneğinizin genel olarak korkunç bir uygulama olduğunu ve çalışma süresi istisnası olmadan tamamen ilgisiz olduğunu lütfen unutmayın; Bunu düşündüğünüzde, bir çalışma zamanı hatası yaptınız, ancak gizlemeyi ve bu konuda hiçbir şey yapmamayı seçtiniz. Bu genellikle anlaşılması zor hatalara yol açar.

Bu soru herhangi bir şekilde yorumlanabilir, ancak yorumlarda Elm'den bahsettiğinizden, bağlam daha açıktır.

Karaağaç, diğer şeylerin yanı sıra, statik olarak yazılmış bir programlama dilidir. Bu tür tip sistemlerin avantajlarından biri, program kullanılmadan önce birçok hata sınıfının (hepsi olmasa da) derleyici tarafından yakalanmasıdır. Bazı hata türleri , istisna olarak atılmak yerine, türlerde (Elm Resultve gibi) kodlanabilir Task. Elm tasarımcıları bu anlama gelir: birçok hata "çalışma zamanı" yerine derleme zamanında yakalanır ve derleyici sizi görmezden gelmek ve en iyisini ummak yerine onlarla başa çıkmaya zorlar. Bunun neden bir avantaj olduğu açıktır: programcı kullanıcı yapmadan önce bir sorunun farkına varırsa.

İstisnalar kullanmadığınızda, hataların diğer daha az şaşırtıcı yollarla kodlandığını unutmayın. Gönderen Elm belgelerine :

Elm'in garantilerinden biri, çalışma zamanı hatalarını pratikte görmeyeceğinizdir. NoRedInk Elm'i yaklaşık bir yıldır üretimde kullanıyor ve hala bir tane yok! Elm'deki tüm garantiler gibi bu da temel dil tasarım seçeneklerine inmektedir. Bu durumda, Elm'in hataları veri olarak ele alması bize yardımcı olur. (Burada çok fazla veri yaptığımızı fark ettiniz mi?)

Karaağaç tasarımcıları "çalışma zamanı istisnası yok" iddiasında bulunmak konusunda biraz cesurlar , ancak "pratikte" nitelendiriyorlar. Muhtemelen ne anlama geldiğini "JavaScript kodlama daha az beklenmedik hatalar" dir.

Elm iddia ediyor:

Uygulamada çalışma zamanı hatası yok . Boş değil. Tanımlanmamış hiçbir işlev değildir.

Ancak çalışma zamanı istisnalarını soruyorsunuz . Bir fark var.

Elm'de hiçbir şey beklenmedik bir sonuç döndürmez. Elm'de çalışma zamanı hataları üreten geçerli bir program yazamazsınız. Bu nedenle, istisnalara ihtiyacınız yoktur.

Yani soru şu olmalıdır:

"Çalışma zamanı hatası yok" un faydası nedir?

Asla çalışma zamanı hataları olmayan bir kod yazabilirseniz, programlarınız asla çökmez.