Existe-t-il des exceptions pour empêcher un système de tomber en panne?

Deuxièmement, je me demandais si quelqu'un savait quelle était la différence entre les exceptions (dans le domaine du flux de contrôle des exceptions) et les exceptions (comme celles utilisées en Java).

Mais sont-ils là pour protéger le système contre les pannes en mettant fin au programme utilisateur?

Il existe des exceptions pour permettre la gestion des exceptions , ce qui peut éviter les plantages mais, plus généralement, empêcher un comportement système indésirable ou imprévisible. Par exemple, si la connexion de mon programme à une base de données expire, cela ne va généralement pas planter le système, mais si je dépendais des données de la base de données, une exception peut me permettre de traiter cette situation sans données différemment de la normale.

Disons que par défaut, mon programme affiche une page de données basée sur ce qui a été renvoyé de la base de données - enfin merde, je n'ai pas de données. Au lieu de présenter une vue foireuse ou de poursuivre une opération potentiellement invalide, je peux intercepter cette exception et revenir à une autre base de données, lire des données locales, demander à l'utilisateur des données ou autrement remettre l'utilisateur ou le système dans un état sûr (vraisemblablement un cela ne provoquera pas immédiatement la même exception!)

De plus, dans les systèmes où la saisie de l'utilisateur peut être la cause / la solution d'un problème, des exceptions peuvent permettre à un utilisateur de connaître des informations détaillées et utiles sur le problème. Au lieu du trop commun "Une exception non gérée s'est produite à ..." ou "Message d'erreur intimidant directement à partir de SQL", vous pouvez dire à l'utilisateur quelque chose d'utile ou au moins compréhensible comme "Impossible de se connecter à la ressource B."

Des exceptions ont été créées pour simplifier la gestion des erreurs. Sans exception, la logique de gestion des erreurs doit être répartie dans toute une application. Toute fonction qui pourrait éventuellement entraîner une erreur doit en quelque sorte renvoyer un état d'erreur, et chaque appel doit être suivi d'une vérification d'erreur. Souvent, l'appelant ne peut rien faire d'utile en cas d'erreur et ne peut renvoyer qu'une erreur elle-même. La moitié du code d'application peut être consacrée à la gestion des erreurs. Un tel code est extrêmement fragile. Il est trop facile d'omettre une vérification d'erreur et de planter, ou pire, de retourner des résultats incorrects en raison d'une erreur inaperçue.

À quelques exceptions près, les erreurs ne peuvent être vérifiées qu'au point où elles peuvent être gérées. La plupart du code d'application peut être écrit en mode linéaire, car les fonctions renvoient une valeur utilisable ou lèvent une exception.

Le point d'une exception devrait être d'informer l'utilisateur de circonstances exceptionnelles. Si quelque chose ne va pas avec le système, le programme devrait le savoir et être autorisé à le gérer * de manière appropriée.

Cela dit, non, aucune exception n'existe pour empêcher le système de "planter". Une exception, il me fait savoir qu'il y a un problème. La façon dont je procède détermine peut déterminer si le système "plante".

Notez également qu'une exception n'a pas à mettre fin à une application comme vous l'avez dit. Une exception peut être gérée par le programmeur et corrigée ou transformée en une erreur significative pour l'utilisateur.

* L'utilisation d'exceptions vérifiées (exceptions qui sont forcées d'être interceptées) est un peu douloureuse. Certains (peut-être la plupart) des développeurs trouvent que la gestion des exceptions forcées est lourde, inutile et juste une mauvaise pratique.

Les exceptions permettent une gestion moderne des erreurs en séparant l'emplacement de l'erreur du gestionnaire d'erreurs. Parfois, cela est également utilisé pour le contrôle de flux.

Les exceptions non gérées mettent fin à un programme. Mais celles-ci ne sont pas différentes des anciennes exceptions, juste un programmeur paresseux qui a oublié d'inclure des gestionnaires d'erreurs appropriés dans chaque chemin les rend visibles pour l'utilisateur final. Je considère qu'un programme terminé par exception est tombé en panne comme n'importe quelle autre fin inattendue.

Les systèmes d'exploitation sont très efficaces pour nettoyer les processus en panne, quelle que soit la façon dont ils se sont bloqués, de sorte que les exceptions n'ajoutent pas de sécurité pour le système d'exploitation autrement que l'arrêt des processus défectueux et la libération de leurs ressources.

C'est très simple.

• Pour ne planter que le programme et non le système entier - nous avons [de bons] systèmes d'exploitation.
• Pour planter un programme au lieu d'ignorer une erreur fatale - nous avons des exceptions.

Avant que des exceptions ne soient inventées, chaque fonction devait renvoyer un code de sortie (erreur / succès) et tout résultat ou sortie de la fonction devait être récupéré en lui passant un pointeur en mémoire à définir par elle.

Le problème était que de nombreux programmeurs ne se souvenaient pas / ne prenaient pas la peine de vérifier les codes de sortie erronés pour chaque fonction, et donc des erreurs fatales étaient parfois ignorées, conduisant à des comportements tout à fait inexplicables.

Par conséquent, il a été décidé - lorsqu'une erreur se produit, que vous n'avez pas prise en compte, plantez immédiatement! Gestion des exceptions AKA.

Les exceptions sont simplement un mécanisme de détection d'erreur. En soi, ils ne sont d'aucune utilité.

Mais en détectant une erreur, ils permettent de déclencher des mécanismes de tolérance aux pannes afin de se remettre de l'état erroné en passant à un état sans erreur (un état précédent ou un nouveau). De cette façon, l'erreur n'est pas propagée aux autres parties du système.

Il existe des exceptions pour séparer le flux de programme normal (ce que le programme est conçu pour faire) du flux de gestion des erreurs (comment le programme essaie de se remettre d'une situation exceptionnelle).

Cela rend le code plus clair et plus facile à maintenir.

Considérez deux sniplets de code:

try:
    do1()  # this is obvoiusly a normal
    do2()  # program flow
except:
    oups()  # this is exception handling code

Par rapport à celui-ci:

if foo():
    thing1()  # is this part of normal program flow?
else:
    thing2()  # or maybe this one? Or both? When?

Bien sûr, la gestion des exceptions peut être utilisée pour empêcher le programme de planter en:

try {    // very bad code
    my();
    whole();
    ugly();
    application();
    here();
} catch (Throwable t) {
    // pretend it's ok
}

mais ce n'est pas la raison des exceptions dans les langages de programmation modernes.

Vous pouvez également utiliser whileet breakau lieu de ifmais ce n'est pas pour quoi whileet à quoi ça sert break.