Computerproblemen. We hebben ze allemaal vroeg of laat. Het kennen van de ins en outs van fouten, beweringen, crashes en meer is van vitaal belang om meer te weten te komen over het probleem in kwestie. Leer er alles over.
Wat is een Assert?
Als een ontwikkelaar code begint te schrijven, ze zullen binnenkort if-statements daarin introduceren. Een if-statement wordt gebruikt wanneer een bepaalde voorwaarde moet worden getest. Men zou bijvoorbeeld een pseudo-code if-statement als volgt kunnen schrijven:
if (water_level > high_water_mark) then { raise_alert }
Met andere woorden, als het waterpeil boven de hoge markering komt, wordt er een alarm gegeven. Maar misschien is de watersensor kapot, dus we werken de code bij zodat deze overeenkomt met:
if (sensor_readout == onzinnig) then { raise_error fail }else{ if (water_level > high_water_mark) then { raise_alert } }
Geweldig, nu krijgen we een foutmelding en mislukken de routine als de sensor_readout onzinnig is. En alleen als de waarde zinnig blijkt te zijn (vanwege de else-clausule, wat te doen in de tegenovergestelde situatie), gaat u verder met het controleren van het waterpeil tegen het hoge watermerk.
Misschien heeft iemand dat wel gedaan schakelde de stroom naar de sensor uit. Zo kunnen we nog wel een tijdje doorgaan. We kunnen elk denkbaar scenario dekken en toch een paar missen. Natuurlijk kunnen we elke mogelijke situatie afdekken met een overeenkomende else-clausule en controleren of elke voorwaarde wordt vergeleken met een andere, maar zelfs in dergelijke gevallen hebben we mogelijk enkele combinaties van variabelen gemist.
Zelfs als we maar een beperkte set variabelen hadden om mee te werken, is het aantal mogelijke combinaties waarin een softwarepakket zich kan bevinden behoorlijk talrijk. En wat meer is, dit soort als voorwaardelijke tests komen vrij regelmatig voor in bijna alle software.
Als we wat verder redeneren over dit dilemma, begrijpen we al snel dat wij (als ontwikkelaars) (net als alle mensen fouten maken) vroeg of laat code kunnen introduceren waarmee de software ongedefinieerd terrein kan betreden. Variabele x is ingesteld op een specifieke waarde, variabele y is toegewezen aan een andere, en hier was geen voorziening voor in de code.
Dit is precies de situatie waarin een bewering tot op zekere hoogte kan voorzien in . Een assert is een andere voorwaarde (denk erover na als een andere if-instructie.) die stelt of een bepaalde vreemde/ongewone/ongeplande/onvoorziene situatie bestaat en gewoonlijk een dergelijke situatie afhandelt door het programma te stoppen in plaats van door te gaan met een niet-gedefinieerde/onbekende toestand .
Hoewel het net dat de activatest zal uitbrengen nog steeds beperkt is tot de intelligentie en vaardigheden van de ontwikkelaar die de bewering implementeert, kan een bewering vaak breder worden gemaakt dan de beperkte grenzen van if-statements die de toestand van verschillende variabelen testen, of het zou kunnen zijn heel specifiek gemaakt om bepaalde gevaarlijke situaties te vermijden.
Laten we bijvoorbeeld zeggen dat onze kleine watersensor in een regentank is gemonteerd. Het water mag daarom nooit koken. Als onze watersensor echter een temperatuurmeter had, zouden we er zeker van kunnen zijn, ook al zou/mag dit nooit gebeuren. Laten we een bewering toevoegen aan de pseudo-code die we hierboven begonnen.
In plaats van kookpunt (100 graden Celsius), zullen we controleren op een redelijker maximum van 70 graden Celsius, wat zou moeten nog steeds nooit worden bereikt als we denken aan het opvangen van regenwater, althans naar onze mening. Onthoud het woord “mening,” omdat dit belangrijk wordt bij het overwegen van de intelligentie van de ontwikkelaar die de bewering implementeert. (Meer hierover hieronder.)
if (sensor_readout == onzinnig) then { raise_error fail }else{ assert (water_temp < 70.0){ raise_asset_message fail exit } if (water_level > high_water_mark) then { raise_alert} }
We schreven de bewering in omgekeerde volgorde. De code moet bevestigen dat de watertemperatuur lager is dan 70 graden Celsius. Als dit niet het geval is, zal het het codeblok uitvoeren, dat een bevestigingsbericht zal oproepen, en dan zal de software falen en afsluiten.
Beweringen in de werkelijke code lijken veel op het bovenstaande voorbeeld. Ze testen of een bepaalde situatie van toepassing is of niet, en stoppen vervolgens (of crashen op een gecontroleerde manier) het programma/de software in kwestie.
Vaak worden deze middelen vastgelegd in de logbestanden van de applicatie of zelfs direct op de schermuitvoer. Als u ze bekijkt en/of zoekt naar een kopie van het exacte bericht in uw favoriete zoekmachine, leidt dit vaak (als de bug eerder is gevonden) u naar een bugrapport over hetzelfde.
Assert-berichten zijn vaak bugs, hoewel het gewoon bugs in de redenering van de ontwikkelaar kunnen zijn. Immers, wie zegt dat over 1000 jaar de regen misschien niet heter is dan 70 graden Celsius? (Laten we echter hopen van niet!)
Een assert-bericht is de uitvoer die wordt weergegeven door de assert die door ontwikkelaars in de code is geïntroduceerd. weergegeven op het scherm of in de logboeken. Stel je bijvoorbeeld voor dat dit bevestigingsbericht wordt getoond voor het bovenstaande programma.
Assert: (water_temp < 70): (88 < 70): false
Hoewel het er een beetje cryptisch uitziet (zoals sommige berichten zijn), doet een beetje beter kijken ons realiseren dat in het tweede deel water_temp werd uitgewisseld door 88 en dat de uitvoer onwaar is (dwz de assert water_temp < 70 is mislukt omdat het water 88 graden was, en dus activeerde de assert het bericht assert). Ja, het kan een beetje verwarrend zijn.
Gewapend met deze nieuwe vaardigheden, wordt het debuggen van een assertbericht de volgende keer dat je er een ziet een stuk eenvoudiger. Misschien vindt u het ook gemakkelijker om precies te begrijpen wat er fout ging op het moment dat de toepassing werd stopgezet.
Wat is een Fout?
Fouten in de computer doen zich voortdurend voor en om uiteenlopende redenen. Ze gebeuren zowel op ontwikkelaar- als op gebruikersniveau en bij elke stap daartussenin. Een DevOps-technicus kan bijvoorbeeld vergeten een noodzakelijk bestand op te nemen, of een pakketondertekenaar kan de verkeerde sleutel gebruiken om de software te ondertekenen, enzovoort.
Kortom, een computerfout kan worden gedefinieerd als een probleem met computerhardware of -software. Er zijn enkele voorbeelden van een fout, zelfs in de beperkte pseudo-code hierboven. Wanneer aan de sensor_readout == onzinnige voorwaarde wordt voldaan, wordt een foutmelding weergegeven.
Er zijn bepaalde fouten die vaker voorkomen dan andere. Het gebruik van een verkeerd pad of een verkeerde bestandsnaam is bijvoorbeeld een veelvoorkomende fout. Stroomgerelateerde problemen (bijvoorbeeld batterij bijna leeg) zijn ook veel voorkomende fouten.
Fouten staan geheel los van en verschillen van assert-berichten, hoewel het assert-bericht op zichzelf kan worden gezien als een fout, of beter gezegd, als een ongedefinieerde situatie die nu door het assert-bericht wordt gedekt. Over het algemeen vertaalt een computerfout zich meestal in “Ik heb een mens nodig om dit op te lossen” best goed.
Naarmate computers intelligenter worden en AI evolueert, zullen er hopelijk minder fouten worden gemaakt, hoewel er op dat gebied veel ruimte overblijft voor discussie en zelfs argumenten.
Wat is een crash?
Een computercrash kan vele vormen aannemen. We kennen allemaal de blauwe schermen van Microsoft Windows, die de neiging hadden om te gebeuren wanneer een toepassing zich misdroeg of een kernonderdeel van het besturingssysteem of de hardware van de machine zou falen.
Meestal is een crash echter een softwaretoepassing die in een ongedefinieerde situatie is terechtgekomen. Er zijn veel van dergelijke ongedefinieerde scenario's mogelijk. Een computer heeft misschien geprobeerd te schrijven naar een RAM-gebied dat al in gebruik is, waardoor hij zichzelf of een andere toepassing van streek maakte, of misschien kwam hij in een scenario terecht waarin hij probeerde te delen door nul (wat onmogelijk is), of een vergelijkbare situatie.
Veel besturingssystemen zullen een kerndumpbestand schrijven (indien geconfigureerd), waarmee een ontwikkelaar en soms een eindgebruiker die enigszins vaardig is, het probleem kan oplossen.
Als je meer wilt weten over debuggen als er iets misgaat, inclusief het analyseren van core dump-bestanden, zul je waarschijnlijk ons artikel Debugging with GDB: Getting Started interessant vinden.
Een crash kan ook de oorzaak zijn. resultaat van een toepassing die in een ongedefinieerde situatie terechtkomt, die niet wordt afgehandeld door een fout (de lichtste manier voor een toepassing om u te informeren dat er iets mis is) of een bewering (een dieperliggend probleem, oorspronkelijk uitgesloten door de ontwikkelaar als onmogelijk maar nog steeds voorkomend) ).
Houd er rekening mee dat een programma dat is gebouwd om te testen, dat wil zeggen, met foutopsporingsinformatie (inclusief beweringen op alleen foutopsporingsniveau) ingebed in het binaire eindresultaat, kan crashen wanneer het een beweren, zoals bijvoorbeeld het geval is met de MySQL-server.
Afronding
In dit artikel hebben we de concepten van beweringen, fouten en crashes en hoe deze zich verhouden. We hebben diepgaand gekeken naar hoe beweringen er in de code uit kunnen zien en hoe dit zich verhoudt tot een realistisch voorbeeld van het bewaken van het waterniveau en de temperatuur met een watersensor. De volgende keer dat je een bevestigingsbericht tegenkomt, kijk er dan eens goed naar en geniet van het debuggen!