Quel est l'avantage de n'avoir «aucune exception d'exécution», comme le prétend Elm?

Certaines langues prétendent n'avoir «aucune exception d'exécution» comme un net avantage sur les autres langues qui en disposent.

Je suis confus à ce sujet.

L'exception d'exécution n'est qu'un outil, pour autant que je sache, et lorsqu'il est bien utilisé:

• vous pouvez communiquer des états "sales" (lancer des données inattendues)
• en ajoutant une pile, vous pouvez pointer vers la chaîne d'erreur
• vous pouvez faire la distinction entre l'encombrement (par exemple, renvoyer une valeur vide sur une entrée non valide) et une utilisation non sécurisée qui nécessite l'attention d'un développeur (par exemple, lever une exception sur une entrée non valide)
• vous pouvez ajouter des détails à votre erreur avec le message d'exception fournissant d'autres détails utiles aidant aux efforts de débogage (théoriquement)

Par contre je trouve vraiment difficile de déboguer un logiciel qui "avale" les exceptions. Par exemple

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

La question est donc: quel est l'avantage théorique fort d'avoir "aucune exception d'exécution"?

Exemple

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

Aucune erreur d'exécution dans la pratique. Pas de null. Aucun indéfini n'est pas une fonction.

Les exceptions ont une sémantique extrêmement limitative. Ils doivent être manipulés exactement là où ils sont lancés, ou dans la pile d'appels directs vers le haut, et il n'y a aucune indication au programmeur au moment de la compilation si vous oubliez de le faire.

Comparez cela à Elm où les erreurs sont codées en tant que résultats ou Maybes , qui sont les deux valeurs . Cela signifie que vous obtenez une erreur de compilation si vous ne gérez pas l'erreur. Vous pouvez les stocker dans une variable ou même une collection pour différer leur manipulation à un moment opportun. Vous pouvez créer une fonction pour gérer les erreurs d'une manière spécifique à l'application au lieu de répéter des blocs try-catch très similaires partout. Vous pouvez les enchaîner dans un calcul qui ne réussit que si toutes ses parties réussissent, et elles ne doivent pas être entassées dans un bloc d'essai. Vous n'êtes pas limité par la syntaxe intégrée.

Cela ne ressemble en rien à «avaler des exceptions». Cela rend les conditions d'erreur explicites dans le système de types et fournit une sémantique alternative beaucoup plus flexible pour les gérer.

Prenons l'exemple suivant. Vous pouvez coller ceci dans http://elm-lang.org/try si vous souhaitez le voir en action.

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")
    ]

Notez que String.toIntdans la calculatefonction a la possibilité d'échouer. En Java, cela a le potentiel de lever une exception d'exécution. Lorsqu'il lit les entrées utilisateur, il a assez de chances de le faire. Au lieu de cela, Elm m'oblige à y faire face en retournant un Result, mais remarquez que je n'ai pas à m'en occuper tout de suite. Je peux doubler l'entrée et la convertir en chaîne, puis rechercher une mauvaise entrée dans la getDefaultfonction. Cet endroit est beaucoup mieux adapté au contrôle que le point où l'erreur s'est produite ou vers le haut dans la pile des appels.

La façon dont le compilateur force notre main est également beaucoup plus fine que les exceptions vérifiées de Java. Vous devez utiliser une fonction très spécifique comme Result.withDefaultextraire la valeur souhaitée. Bien que, techniquement, vous puissiez abuser de ce type de mécanisme, cela ne sert à rien. Puisque vous pouvez reporter la décision jusqu'à ce que vous connaissiez un bon message par défaut / d'erreur à mettre, il n'y a aucune raison de ne pas l'utiliser.

Pour comprendre cette affirmation, nous devons d'abord comprendre ce qu'un système de type statique nous achète. En substance, ce qu'un système de type statique nous donne est une garantie: si les vérifications de type de programme, une certaine classe de comportements d'exécution ne peut pas se produire.

Cela semble inquiétant. Eh bien, un vérificateur de type est similaire à un vérificateur de théorème. (En fait, selon l'isomorphisme de Curry-Howard, c'est la même chose.) Une chose qui est très particulière à propos des théorèmes est que lorsque vous prouvez un théorème, vous prouvez exactement ce que dit le théorème, pas plus. (C'est par exemple pourquoi, lorsque quelqu'un dit "J'ai prouvé que ce programme est correct", vous devez toujours demander "veuillez définir" correct "".) La même chose est vraie pour les systèmes de type. Lorsque nous disons "un programme est sûr pour le type", nous ne voulons pas dire qu'aucune erreur possible ne peut se produire. Nous pouvons seulement dire que les erreurs que le système de type nous promet d'éviter ne peuvent pas se produire.

Ainsi, les programmes peuvent avoir une infinité de comportements d'exécution différents. Parmi ceux-ci, un nombre infini de ceux-ci sont utiles, mais aussi un nombre infini de ceux-ci sont "incorrects" (pour diverses définitions de "l'exactitude"). Un système de type statique nous permet de prouver qu'un certain ensemble fini et fixe de ces infiniment de comportements d'exécution incorrects ne peut pas se produire.

La différence entre les différents types de systèmes réside essentiellement dans le fait de savoir combien, et combien de comportements d'exécution complexes ils peuvent ne pas se produire. Les systèmes de type faible tels que Java ne peuvent prouver que des choses très basiques. Par exemple, Java peut prouver qu'une méthode qui est typée comme retournant un Stringne peut pas retourner un List. Mais, par exemple, il ne peut pas prouver que la méthode ne reviendra pas. Il ne peut pas non plus prouver que la méthode ne lèvera pas d'exception. Et il ne peut pas prouver qu'il ne renverra pas le mauvais String  - tout Stringsatisfera le vérificateur de type. (Et, bien sûr, même nullsatisfera aussi bien.) Il y a même des choses que Java ne peut pas prouver très simple, ce qui est la raison pour laquelle nous avons des exceptions comme ArrayStoreException, ClassCastExceptionou tout le monde le favori, le NullPointerException.

Des systèmes de types plus puissants comme Agda peuvent également prouver des choses comme «renverra la somme des deux arguments» ou «renvoie la version triée de la liste passée en argument».

Maintenant, ce que les concepteurs d'Elm entendent par la déclaration selon laquelle ils n'ont pas d'exceptions d'exécution, c'est que le système de type d'Elm peut prouver l'absence de (une partie importante) des comportements d'exécution qui, dans d'autres langues, ne peuvent pas être prouvés comme ne se produisant pas et pourraient donc conduire à un comportement erroné lors de l'exécution (ce qui dans le meilleur des cas signifie une exception, dans le pire des cas, un crash, et dans le pire des cas, aucun crash, aucune exception, et juste un résultat silencieusement erroné).

Donc, ils ne disent pas "nous n'implémentons pas d'exceptions". Ils disent que "les choses qui seraient des exceptions d'exécution dans des langages typiques que les programmeurs typiques venant avec Elm auraient expérimentés, sont prises par le système de type". Bien sûr, quelqu'un venant d'Idris, Agda, Guru, Epigram, Isabelle / HOL, Coq ou d'autres langues similaires verra Elm comme assez faible en comparaison. L'instruction s'adresse davantage aux programmeurs Java, C♯, C ++, Objective-C, PHP, ECMAScript, Python, Ruby, Perl,… typiques.

Elm ne peut garantir aucune exception d'exécution pour la même raison C ne peut garantir aucune exception d'exécution: le langage ne prend pas en charge le concept d'exceptions.

Elm a un moyen de signaler les conditions d'erreur lors de l'exécution, mais ce système ne fait pas exception, il s'agit de "Résultats". Une fonction qui peut échouer renvoie un "résultat" qui contient soit une valeur régulière soit une erreur. Elms est fortement typé, c'est donc explicite dans le système de type. Si une fonction retourne toujours un entier, elle a le type Int. Mais s'il retourne un entier ou échoue, le type de retour est Result Error Int. (La chaîne est le message d'erreur.) Cela vous oblige à gérer explicitement les deux cas sur le site d'appel.

Voici un exemple de l'introduction (un peu simplifié):

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

    Ok age ->
        text "OK!"

La fonction toIntpeut échouer si l'entrée n'est pas analysable, donc son type de retour l'est Result String int. Pour obtenir la valeur entière réelle, vous devez "décompresser" via la correspondance de modèles, ce qui vous oblige à gérer les deux cas.

Les résultats et les exceptions font fondamentalement la même chose, la différence importante étant les «défauts». Les exceptions bouillonneront et mettront fin au programme par défaut, et vous devez les intercepter explicitement si vous voulez les gérer. Le résultat est dans l'autre sens - vous êtes obligé de les gérer par défaut, vous devez donc les passer explicitement jusqu'au sommet si vous voulez qu'ils terminent le programme. Il est facile de voir comment ce comportement peut conduire à un code plus robuste.

Tout d'abord, veuillez noter que votre exemple d'exceptions de «déglutition» est en général une pratique terrible et complètement sans rapport avec l'absence d'exceptions de temps d'exécution; lorsque vous y réfléchissez, vous avez eu une erreur d'exécution, mais vous avez choisi de la masquer et de ne rien y faire. Cela entraînera souvent des bogues difficiles à comprendre.

Cette question pourrait être interprétée de plusieurs façons, mais comme vous avez mentionné Elm dans les commentaires, le contexte est plus clair.

Elm est, entre autres, un langage de programmation typé statiquement . L'un des avantages de ce type de systèmes de types est que de nombreuses classes d'erreurs (mais pas toutes) sont détectées par le compilateur, avant que le programme ne soit réellement utilisé. Certains types d'erreurs peuvent être encodés en types (tels que Elm Resultet Task), au lieu d'être levés comme exceptions. C'est ce que les concepteurs d'Elm veulent dire: de nombreuses erreurs seront détectées au moment de la compilation plutôt qu'au "moment de l'exécution", et le compilateur vous forcera à les traiter au lieu de les ignorer et d'espérer le meilleur. Il est clair pourquoi c'est un avantage: mieux vaut que le programmeur prenne conscience d'un problème avant que l'utilisateur ne le fasse.

Notez que lorsque vous n'utilisez pas d'exceptions, les erreurs sont codées d'autres manières moins surprenantes. D'après la documentation d'Elm :

L'une des garanties d'Elm est que vous ne verrez pas d'erreurs d'exécution dans la pratique. NoRedInk utilise Elm en production depuis environ un an maintenant, et ils n'en ont toujours pas! Comme toutes les garanties dans Elm, cela se résume aux choix fondamentaux de conception de langage. Dans ce cas, nous sommes aidés par le fait qu'Elm traite les erreurs comme des données. (Avez-vous remarqué que nous faisons beaucoup de données ici?)

Les concepteurs d'orme sont un peu audacieux en déclarant "aucune exception de temps d'exécution" , bien qu'ils le qualifient de "en pratique". Ce qu'ils signifient probablement "moins d'erreurs inattendues que si vous codiez en javascript".

L'orme affirme:

Aucune erreur d' exécution dans la pratique. Pas de null. Aucun indéfini n'est pas une fonction.

Mais vous posez des questions sur les exceptions d' exécution . Il y a une différence.

Dans Elm, rien ne renvoie un résultat inattendu. Vous ne pouvez PAS écrire un programme valide dans Elm qui génère des erreurs d'exécution. Ainsi, vous n'avez pas besoin d'exceptions.

Donc, la question devrait être:

Quel est l'avantage d'avoir "aucune erreur d'exécution"?

Si vous pouvez écrire du code qui n'a jamais d'erreurs d'exécution, vos programmes ne se bloqueront jamais.