Behauptungen, Fehler und Abstürze: Was ist der Unterschied?

Shutterstock/SkillUp

Computerprobleme. Wir alle haben sie früher oder später. Das Wissen um Fehler, Behauptungen, Abstürze und mehr ist entscheidend, um mehr über das vorliegende Problem zu verstehen. Erfahren Sie alles darüber.

Was ist ein Assert?

Wenn ein Entwickler mit dem Schreiben von Code beginnt, sie werden bald if-Anweisungen darin einführen. Eine if-Anweisung wird immer dann verwendet, wenn eine bestimmte Bedingung getestet werden muss. Zum Beispiel könnte man eine pseudo-code if-Anweisung wie folgt schreiben:

if (water_level > high_water_mark) then { raise_alert }

Mit anderen Worten, wenn der Wasserstand über die hohe Marke geht, wird eine Warnung ausgelöst. Aber vielleicht ist der Wassersensor kaputt, also aktualisieren wir den Code entsprechend:

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

Großartig, jetzt erhalten wir einen Fehler und die Routine schlägt fehl, wenn die sensor_readout unsinnig ist. Und nur wenn sich der Wert als sinnvoll erweist (aufgrund der else-Klausel—dh was in der umgekehrten Situation zu tun ist), fahren Sie mit dem Überprüfen des water_level gegen das high_water_mark fort.

Vielleicht hat es jedoch jemand schaltete die Stromversorgung des Sensors aus. Wir können noch eine Weile so weitermachen. Wir können jedes erdenkliche Szenario abdecken und dennoch einige vermissen. Natürlich könnten wir jede mögliche Situation mit einer passenden else-Klausel abdecken und überprüfen, ob jede Bedingung gegen eine andere geprüft wird, aber selbst in solchen Fällen könnten wir einige Kombinationen von Variablen übersehen haben.

Selbst wenn wir nur eine begrenzte Anzahl von Variablen hätten, mit denen wir arbeiten konnten, ist die Anzahl der möglichen Kombinationen, in denen ein Softwarepaket sich finden kann, ziemlich zahlreich. Und außerdem kommen diese bedingten Tests in fast jeder Software ziemlich regelmäßig vor.

Wenn wir über dieses Dilemma noch ein wenig weiter nachdenken, verstehen wir schnell, dass wir (als Entwickler) (genau wie alle Menschen Fehler machen) früher oder später Code einführen, der die Software in undefiniertes Terrain laufen lässt. Variable x wird auf einen bestimmten Wert gesetzt, Variable y wird einem anderen zugewiesen, und dies war im Code nicht vorgesehen.

Genau dies kann ein Assert bis zu einem gewissen Grad vorsehen . Ein Assert ist eine weitere Bedingung (Denken Sie darüber nach wie eine andere if-Anweisung.), die bestätigt, ob eine bestimmte ungerade/ungewöhnliche/ungeplante/unvorhergesehene Situation existiert und eine solche Situation normalerweise durch Anhalten des Programms behandelt, anstatt mit einem undefinierten/unbekannten Zustand weiterzulaufen .

Während das Netz, das der Asset-Test werfen wird, immer noch auf die Intelligenz und Fähigkeiten des Entwicklers beschränkt ist, der die Zusicherung implementiert, kann eine Zusicherung oft weiter gefasst werden als die begrenzten Grenzen von if-Anweisungen, die den Zustand verschiedener Variablen testen, oder es könnte sein ganz spezifisch gemacht, um bestimmte gefährliche Situationen zu vermeiden.

Nehmen wir zum Beispiel an, dass unser kleiner Wassersensor in einem Regentank montiert ist. Das Wasser sollte daher niemals kochen. Wenn unser Wassersensor jedoch einen Temperaturmesser hätte, könnten wir uns vergewissern, auch wenn es nie passieren würde/sollte. Fügen wir dem Pseudo-Code, den wir oben begonnen haben, eine Assertion hinzu.

Anstelle des Siedepunkts (100 Grad Celsius) suchen wir nach einem vernünftigeren Maximum von 70 Grad Celsius, das sollte immer noch nie zu erreichen, wenn man daran denkt, Regenwasser aufzufangen, zumindest unserer Meinung nach. Denken Sie an das Wort “Meinung” da dies wichtig wird, wenn man die Intelligenz des Entwicklers berücksichtigt, der die Assertion implementiert. (Mehr dazu weiter unten.)

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

Wir haben die Behauptung umgekehrt geschrieben. Der Code muss behaupten, dass die Wassertemperatur weniger als 70 Grad Celsius beträgt. Ist dies nicht der Fall, wird der Codeblock ausgeführt, der eine Assert-Nachricht ausgibt, und dann schlägt die Software fehl und wird beendet.

Asserts im tatsächlichen Code sind dem obigen Beispiel sehr ähnlich. Sie testen, ob eine bestimmte Situation zutrifft oder nicht, und stoppen (oder stürzen kontrolliert) das jeweilige Programm/die aktuelle Software ab.

Oft werden diese Assets in den Protokolldateien der Anwendung protokolliert oder sogar direkt auf der Bildschirmausgabe. Wenn Sie sie überprüfen und/oder in Ihrer bevorzugten Suchmaschine nach einer Kopie der genauen Assert-Nachricht suchen, werden Sie oft (wenn der Fehler zuvor gefunden wurde) zu einem Fehlerbericht darüber.

Assert-Meldungen sind häufig Fehler, obwohl sie möglicherweise einfach Fehler in der Argumentation des Entwicklers sind. Wer sagt schließlich, dass der Regen in 1.000 Jahren nicht mehr als 70 Grad Celsius betragen wird? (Hoffen wir es aber nicht!)

Eine Assert-Nachricht ist die Ausgabe, die durch die von den Entwicklern in den Code eingeführte Assert-Ausgabe gerendert wird, dh die tatsächliche Textausgabe, die von der Software und als generiert wird auf dem Bildschirm oder in den Protokollen angezeigt. Stellen Sie sich zum Beispiel vor, dass diese Assert-Nachricht für das obige Programm angezeigt wird.

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

Obwohl es etwas kryptisch aussieht (wie manche Assert-Nachrichten sind), stellt uns bei genauerem Hinsehen klar, dass im zweiten Teil water_temp ausgetauscht wurde um 88 und dass die Ausgabe falsch ist (dh die Bestätigung water_temp < 70 schlug fehl, da das Wasser 88 Grad betrug, und somit löste die Bestätigung die Bestätigungsnachricht aus). Ja, es kann ein wenig verwirrend werden.

Ausgestattet mit diesen neuen Fähigkeiten wird es viel einfacher, eine Assert-Nachricht zu debuggen, wenn Sie das nächste Mal eine sehen. Möglicherweise ist es auch einfacher zu verstehen, was zum Zeitpunkt des Anwendungsstopps schief gelaufen ist.

Was ist ein Fehler?

Fehler beim Rechnen treten ständig und aus einer Vielzahl von Gründen auf. Sie passieren sowohl auf Entwickler- als auch auf Benutzerebene und bei jedem Schritt dazwischen. Beispielsweise könnte ein DevOps-Ingenieur vergessen, eine erforderliche Datei einzufügen, oder ein Paketunterzeichner könnte den falschen Schlüssel zum Signieren der Software verwenden usw.

Kurz gesagt, ein Computerfehler kann als ein Problem mit der Computerhardware oder -software definiert werden. Es gibt einige Beispiele für einen Fehler, selbst im obigen eingeschränkten Pseudocode. Wenn die sensor_readout == unsinnige Bedingung erfüllt ist, wird eine Fehlermeldung angezeigt.

Es gibt bestimmte Fehler, die häufiger auftreten als andere. Beispielsweise ist die Verwendung eines falschen Pfads oder Dateinamens ein häufiger Fehler. Strombezogene Probleme (z. B. schwacher Akku) sind ebenfalls recht häufige Fehler.

Fehler sind ziemlich getrennt und unterscheiden sich von Assert-Nachrichten, obwohl die Assert-Nachricht an sich als Fehler angesehen werden kann, oder vielmehr als undefinierte Situation, die jetzt von der Assertion abgedeckt wird. Im Allgemeinen bedeutet ein Computerfehler normalerweise “Ich brauche einen Menschen, um das zu beheben” ganz gut.

Wenn Computer intelligenter werden und sich die KI weiterentwickelt, werden hoffentlich weniger Fehler produziert, obwohl in diesem Bereich viel Raum für Diskussionen und sogar Argumente bleibt.

Was ist ein Absturz?

Ein Computerabsturz kann viele Formen annehmen. Wir alle kennen Microsoft Windows-Bluescreens, die häufig auftreten, wenn sich eine Anwendung falsch verhält oder ein Kernteil des Betriebssystems oder der Hardware des Computers ausfällt.

Meistens ist ein Absturz jedoch eine Softwareanwendung, die in eine undefinierte Situation geraten ist. Es sind viele solcher undefinierten Szenarien möglich. Ein Computer hat möglicherweise versucht, in einen bereits verwendeten RAM-Bereich zu schreiben, wodurch er sich selbst oder eine andere Anwendung gestört hat, oder er ist in ein Szenario geraten, in dem er versucht hat, durch Null zu teilen (was unmöglich ist) oder eine ähnliche Situation.

Viele Betriebssysteme schreiben eine Core-Dump-Datei (sofern konfiguriert), die es einem Entwickler und manchmal auch einem etwas erfahrenen Endbenutzer ermöglicht, das vorliegende Problem zu debuggen.

Wenn Sie mehr über das Debuggen erfahren möchten, wenn etwas schief geht, einschließlich der Analyse von Core-Dump-Dateien, wird Ihnen wahrscheinlich unser Artikel Debugging mit GDB: Erste Schritte interessant sein.

Ein Absturz könnte auch die Ergebnis, dass eine Anwendung in eine undefinierte Situation gerät, die nicht durch einen Fehler (der einfachste Weg für eine Anwendung, Sie zu informieren, dass etwas nicht stimmt) oder einen Assert (ein tieferes Problem, das ursprünglich vom Entwickler als unmöglich ausgeschlossen wurde, aber immer noch auftritt) behandelt wird ).

Beachten Sie außerdem, dass ein Programm, das zum Testen erstellt wurde, d. h. mit Debugging-Informationen (einschließlich Asserts nur auf Debug-Ebene), die in die Binärdatei des Endergebnisses eingebettet sind, abstürzen kann, wenn ein assert, wie es zum Beispiel beim MySQL-Server der Fall ist.

Zusammenfassung

In diesem Artikel haben wir die Konzepte von Behauptungen, Fehlern und Abstürzen sowie deren Beziehung. Wir haben uns eingehend damit befasst, wie Assertionen im Code aussehen könnten und wie dies mit einem realen Beispiel für die Überwachung des Wasserstands und der Temperatur mit einem Wassersensor zusammenhängt. Wenn Sie das nächste Mal auf eine Zusicherungsnachricht stoßen, schauen Sie genauer hin und genießen Sie das Debuggen!