Quelle est la différence? –

Problèmes informatiques. Nous les avons tous tôt ou tard. Connaître les tenants et les aboutissants des erreurs, des assertions, des plantages et bien plus est essentiel pour mieux comprendre le problème à résoudre. Apprenez tout à ce sujet.

Qu’est-ce qu’un Affirmer?

Lorsqu’un développeur commence à écrire du code, il introduira bientôt if déclarations qui y sont. Un if L’instruction est utilisée chaque fois qu’une certaine condition doit être testée. Par exemple, on pourrait écrire un pseudo-code if déclaration comme suit :

if (water_level > high_water_mark) then {
  raise_alert
}

En d’autres termes, si le niveau d’eau dépasse le repère haut, une alerte est déclenchée. Mais peut-être que le capteur d’eau est cassé, nous mettons donc à jour le code pour qu’il corresponde :

if (sensor_readout == nonsensical) then {
  raise_error
  fail
}else{
  if (water_level > high_water_mark) then {
    raise_alert
  }
}

Super, maintenant nous obtiendrons une erreur et échouerons la routine si le sensor_readout est absurde. Et seulement si la valeur s’avère sensée (en raison de la else clause – c’est-à-dire que faire dans la situation opposée), procédez à la vérification du water_level par rapport au high_water_mark.

Cependant, quelqu’un a peut-être coupé l’alimentation du capteur. On peut continuer comme ça un moment. Nous pouvons couvrir tous les scénarios possibles imaginables et en manquer encore quelques-uns. Bien sûr, nous pourrions couvrir toutes les situations possibles avec une correspondance else clause et vérifier que chaque condition est vérifiée par rapport à une autre, mais même dans de tels cas, nous pourrions avoir manqué certaines combinaisons de variables.

Même si nous n’avions qu’un ensemble limité de variables avec lesquelles travailler, le nombre de combinaisons possibles dans lesquelles un progiciel peut se trouver est assez nombreux. Et en plus, ce genre de if les tests conditionnels se produisent assez régulièrement dans presque tous les logiciels.

En raisonnant un peu plus loin sur ce dilemme, nous comprenons rapidement que nous (en tant que développeurs) pourrions (comme tous les humains faire des erreurs) tôt ou tard introduire du code qui permet au logiciel de s’exécuter dans un territoire indéfini. La variable x est définie sur une valeur spécifique, la variable y est affectée à une autre, et cela n’était pas prévu dans le code.

C’est précisément la situation qu’un assert peut, dans une certaine mesure, prévoir. Une assertion est une autre condition (Pensez-y comme une autre if déclaration.) qui affirme si une situation étrange/peu commune/non planifiée/imprévue existe et gère généralement une telle situation en arrêtant le programme plutôt que de continuer à s’exécuter avec un état indéfini/inconnu.

Bien que le filet que le test d’actif jette soit encore limité à l’intelligence et aux compétences du développeur qui implémente l’assertion, une assertion peut souvent être plus large que les limites limitées de if déclarations testant l’état de diverses variables, ou il pourrait être rendu assez spécifique pour éviter certaines situations dangereuses.

Par exemple, disons que notre petit capteur d’eau est monté dans un réservoir de pluie. L’eau ne doit donc jamais bouillir. Si notre capteur d’eau avait un thermomètre, cependant, nous pourrions nous en assurer, même si cela ne se produirait/ne devrait jamais se produire. Ajoutons une assertion au pseudo-code que nous avons commencé ci-dessus.

Au lieu du point d’ébullition (100 degrés Celsius), nous vérifierons un maximum plus raisonnable de 70 degrés Celsius, qui ne devrait toujours jamais être atteint lorsque l’on pense à récupérer l’eau de pluie, du moins, à notre avis. N’oubliez pas le mot « opinion », car cela devient important lorsque l’on considère l’intelligence du développeur implémentant l’assertion. (Plus d’informations à ce sujet ci-dessous.)

if (sensor_readout == nonsensical) then {
  raise_error
  fail
}else{
  assert (water_temp < 70.0){ 
    raise_assert_message 
    fail 
    exit 
  } 
  if (water_level > high_water_mark) then {
    raise_alert
  }
}

Nous avons écrit l’assertion à l’envers. Le code doit affirmer que la température de l’eau est inférieure à 70 degrés Celsius. Si ce n’est pas le cas, il exécutera le bloc de code, ce qui générera un message d’assertion, puis le logiciel échouera et se fermera.

Les assertions dans le code réel sont assez similaires à l’exemple ci-dessus. Ils testent si une situation donnée s’applique ou non, puis arrêtent (ou plantent de manière contrôlée) le programme/logiciel à portée de main.

Souvent, ces actifs sont enregistrés dans les fichiers journaux de l’application ou même directement sur la sortie d’écran. Les examiner et/ou rechercher une copie du message d’assertion exact dans votre moteur de recherche préféré vous mènera souvent (si le bogue a déjà été trouvé) à un rapport de bogue sur le même.

Les messages d’assertion sont souvent des bogues, bien qu’ils puissent simplement être des bogues dans le raisonnement du développeur. Après tout, qui a dit que dans 1 000 ans, la pluie ne dépasserait peut-être pas 70 degrés Celsius ? (Espérons que non, cependant !)

Un message d’assertion est la sortie rendue par l’assertion introduite par les développeurs dans le code, c’est-à-dire la sortie textuelle réelle générée par le logiciel et affichée à l’écran ou dans les journaux. Par exemple, imaginez ce message d’assertion affiché pour le programme ci-dessus.

Assert: (water_temp < 70): (88 < 70): false

Bien que cela semble un peu cryptique (comme le sont certains messages d’assertion), y regarder d’un peu plus près nous fait réaliser que dans la deuxième partie, water_temp a été échangé par 88 et que la sortie est false (c’est-à-dire que l’assertion water_temp < 70 a échoué car l'eau était à 88 degrés, et donc, l'assertion a déclenché le message d'assertion). Oui, cela peut devenir un peu déroutant.

Armé de ces nouvelles compétences, le débogage d’un message d’assertion la prochaine fois que vous en voyez un devient beaucoup plus facile. Vous pourriez également trouver plus facile de comprendre exactement ce qui n’allait pas au moment de l’arrêt de l’application.

Qu’est-ce qu’un Erreur?

Les erreurs informatiques se produisent tout le temps et pour une grande variété de raisons. Ils se produisent à la fois au niveau du développeur et de l’utilisateur et à chaque étape intermédiaire. Par exemple, un ingénieur DevOps peut oublier d’inclure un fichier nécessaire, ou un signataire de package peut utiliser la mauvaise clé pour signer le logiciel, etc.

En bref, une erreur informatique peut être définie comme un problème de matériel informatique ou de logiciel. Il y a quelques exemples d’erreur même dans le pseudo-code limité ci-dessus. Quand le sensor_readout == nonsensical condition est remplie, un message d’erreur s’affiche.

Certaines erreurs sont plus fréquentes que d’autres. Par exemple, l’utilisation d’un chemin ou d’un nom de fichier erroné est une erreur courante. Les problèmes liés à l’alimentation (par exemple, batterie faible) sont également des erreurs assez courantes.

Les erreurs sont assez distinctes et différentes des messages d’assertion, même si le message d’assertion en lui-même peut être considéré comme une erreur, ou plutôt comme une situation indéfinie désormais couverte par l’assertion. En général, une erreur informatique se traduit généralement par « J’ai besoin d’un humain pour résoudre ce problème » assez bien.

À mesure que les ordinateurs deviennent plus intelligents et que l’IA évolue, espérons-le, moins d’erreurs seront produites, bien qu’il reste beaucoup de place pour la discussion et même les arguments dans ce domaine.

Qu’est-ce qu’un crash?

Un crash informatique peut prendre plusieurs formes. Nous connaissons tous les écrans bleus de Microsoft Windows, qui avaient tendance à se produire lorsqu’une application se comportait mal ou qu’une partie centrale du système d’exploitation ou du matériel de la machine tombait en panne.

La plupart du temps, cependant, un crash est une application logicielle qui s’est heurtée à une situation indéfinie. Il existe de nombreux scénarios indéfinis possibles. Un ordinateur a peut-être essayé d’écrire dans une zone de RAM déjà utilisée, se perturbant ainsi lui-même ou une autre application, ou peut-être s’est-il heurté à un scénario dans lequel il a tenté de diviser par zéro (ce qui est impossible), ou une situation similaire.

De nombreux systèmes d’exploitation écrivent un fichier de vidage de mémoire (s’il est ainsi configuré), ce qui permet à un développeur et, parfois, à un utilisateur final quelque peu qualifié, de déboguer le problème en question.

Si vous souhaitez en savoir plus sur le débogage en cas de problème, y compris l’analyse des fichiers de vidage de mémoire, vous trouverez probablement notre article Débogage avec GDB : Mise en route qui vous intéressera.

Un plantage peut également être le résultat d’une application se heurtant à une situation indéfinie, qui n’est pas gérée par une erreur (le moyen le plus léger pour une application de vous informer que quelque chose ne va pas) ou une assertion (un problème plus profond, exclu à l’origine par le développeur comme impossible mais toujours en cours).

Notez également qu’un programme construit pour les tests, c’est-à-dire avec des informations de débogage (y compris des assertions de niveau de débogage uniquement) intégrées dans le binaire de résultat final, peut planter lorsqu’il produit une assertion, comme c’est le cas, par exemple, avec MySQL serveur.

Emballer

Dans cet article, nous avons exploré les concepts d’assertions, d’erreurs et de plantages ainsi que leur relation. Nous avons examiné en profondeur à quoi pourraient ressembler les assertions à l’intérieur du code et comment cela se rapporte à un exemple réel de surveillance du niveau et de la température de l’eau avec un capteur d’eau. La prochaine fois que vous rencontrerez un message d’assertion, regardez de plus près et profitez du débogage !