Dans GHCi :
Pourquoi n’est pas le premier une exception imbriquée ?
Réponse
Trop de publicités?
La réponse est que c'est le (un peu surprenant) la sémantique de imprécis exceptions
Quand il est pur code peut être montré à évaluer un ensemble de valeurs exceptionnelles (c'est à dire la valeur de error ou undefined, et de manière explicite pas le genre d'exceptions générées dans IO), puis la langue permet à toute la valeur de cet ensemble à être retourné. Les valeurs exceptionnelles en Haskell sont plus comme NaN en virgule flottante de code, plutôt que le contrôle de flux basé sur des exceptions dans des langages impératifs.
Occasionnel gotcha pour la même avancé Haskellers est un cas tel que:
case x of
1 -> error "One"
_ -> error "Not one"
Depuis que le code donne un ensemble d'exceptions, GHC est libre d'en choisir un. Avec les optimisations sur, vous pouvez ainsi trouver cela prend toujours la valeur "Non".
Pourquoi faisons-nous cela? Parce que sinon, nous serions trop contraindre l'ordre d'évaluation de la langue, par exemple, on devrait corriger un résultat déterministe pour:
f (error "a") (error "b")
par exemple, exiger qu'elle soit évaluée de gauche à droite si les valeurs d'erreur sont présents. Très Haskelly!
Puisque nous ne voulons pas nous paralyser les optimisations qui peut être fait sur notre code juste pour appuyer error, la solution est de préciser que le résultat est non-déterministe choix à partir de l'ensemble des valeurs exceptionnelles: imprécis des exceptions! En un sens, toutes les exceptions sont retournés, et un seul est choisi.
Normalement, vous n'avez pas de soins - une exception est une exception, à moins que vous vous souciez de la chaîne à l'intérieur de l'exception, dans les cas où l'utilisation d' error debug est très déroutant.
Références: Une sémantique de l'imprécision des exceptions, Simon Peyton Jones, Alastair Reid, Tony Hoare, Simon Marlow, Fergus Henderson. Proc Langages de Programmation, de Conception et de mise en Œuvre (PLDI'99), à Atlanta. (PDF)
