[X] Exception Handling

Reyx

Reyx schrieb:

Hier mal der erste Entwurf des Artikels. Ich hab ich nur grob selbst nochmal überblättert (mehr Zeit hatte ich heute leider nicht), deshalb entschuldige ich mich jetzt schon für die etlichen Rechtschreib- und Grammatikfehler ;).

Der Artikel ist noch nicht ganz fertig, es kommt noch die Verwendung der Exception-Klasseninstanzen hinzu. Zudem vielleicht noch ein paar mehr Beispiele?

Exception Handling
Wo Menschen arbeiten, da machen Sie Fehler.
Maschinen währen unfehlbar, würden sie nicht exakt das tun, was der Mensch ihnen befiehlt.
Der Mensch vererbt der Maschine die Fehlbarkeit, welche die Maschine an sich nicht kennt.
Jeder Fehler der Maschine ist somit auf den Menschen zurück zu führen, welcher die Pflicht hat, diese Vererbung soweit wie möglich einzugrenzen.

Vorwort :: Fehlerbehandlung – Fluch oder Segen?
Du, als Programmierer, hast es leicht: Das Programm, welches du entwickelts, macht ganz exakt das, was du willst. Der Endanwender jedoch -sei es der Kunde, der Informatiklehrer deiner Schule oder schlicht und ergreifend dein Freund von nebenan- hat ein schwereres Los gezogen: Er weiß nicht, wie das Programm funktioniert. Er weiß nicht, welche Handhabung es von ihm erwartet!

Als Beispiel soll folgende (zum Zweck der Demonstration sehr einfache) Situation dienen: Dein Programm soll den Zins c eines Geldbetrages a anhand eines Zinssatzes b berechnen.
Eine einfache Formel dazu könnte wie folgt aussehen:

c = a / 100 * b

Diese Formel wirkt einfach, ist funktional, und könnte ohne Probleme so in eine entsprechende Funktion in C++ umgesetzt werden.
Nun stehst du als Programmierer vor der Situation, dein Programm zu verwenden. Du besitzt einen Geldbetrag von 20.000 € und einen Zinssatz von 4 %, und möchtest dein Programm dazu benutzen, den Zins auszurechnen. Du weißt: dein Programm erwartet einen Geldbetrag und einen Zinssatz, und gibst ihm dementsprechend, völlig selbstverständlich, eben diese Informationen:

c = 20000 / 100 * b = 800

Wie erwartet errechnet dir das Programm den Zins von 800 € - was sonst sollte es auch tun? Es ist eine einfache Formel, die genau das tut, was man von ihr erwartet: Den Zins berechnen. Richtig?

Falsch! Du als Programmierer weißt genau, was das Programm von dir erwartet (bzw. was du als Programmierer von dir selbst bzw. dem Anwender im Allgemeinen erwartest). Was nun aber, wenn jemand anders dein Programm benutzt? Was, wenn dieser Jemand aus Verwirrung oder, was leider auch des öfteren der Fall ist, aus Boshaftigkeit dem Programm die Werte „Müller“ und „Meier“ angibt? Dein Programm stellt die entsprechende Formel auf:

c = "Müller" / 100 * "Meier"

Für eine solche, offensichtlich falsche, Verwendung hast du dein Programm in den allermeisten Fällen nicht konzipiert. Es soll den Zins berechnen, nicht mehr und nicht weniger ... und ganz bestimmt nicht den armen "Müller" in einhundert Stücke zerlegen, um anschließend den "Meier" unterzumischen!
Solche Situationen sind es, in denen die Maschine auf die Umsicht des Programmierers, auf dich, angewiesen ist, denn sie selbst kann eine solche Situation nicht bzw. nur sehr schwer erkennen (und wo Maschinen versuchen, selbstständig entscheidungen zu Treffen, kann die Sache nur noch schlimmer werden)!
Hier bist also du gefragt, um der Maschine zu sagen: Nein! kein "Müller", kein "Meier", nur X Werte darfst du verwenden. Und in Y Situation musst du dich Z verhalten!

Ist die Fehlerbehandlung nun ein Fluch oder ein Segen? Nun, ich denke, beides. Für den Programmierer, welcher Stunden mit dem debuggen seines Codes zubringt, sind sie sicherlich ein Fluch. Für die Maschine jedoch, die selbst über keinerlei wirkliche Intelligenz verfügt, ist sie der einzige Anhaltspunkt, der einzige Leitfaden, an dem sie sich in einer unerwarteten Situation orientieren kann. Sie ist somit für die Maschine von essenzieller (und auch existenzieller) Bedeutung! Und der Endanwender? Nun, der erwartet, das das Programm, welches er, vielleicht für teures Geld, vielleicht mit viel Mühe, erstanden hat, auch so funktioniert, wie er es erwartet! Ist dies dann nicht der Fall, kann es zu Frustration (und dementsprechend vielleicht zu einer Rufschädigung deiner Selbst) oder auch zu Reklamation kommen. Bei groben Fehlern könnte dir sogar Fahrlässigkeit vorgeworfen werden! Demnach ist die Fehlerbehandlung ebenfalls für dich als Programmierer von existenzieller Bedeutung und darf niemals zu kurz kommen oder gar ignoriert werden!

Lieber ein Programm, welches nach zwei Tagen Programmierzeit wirklich das tut, was es soll, und dabei auf weitestgehend alle möglichen Fehler entsprechend reagieren kann, als eines, welches nach einer Stunde freigegeben wird, und dann Wochenlang (oder vielleicht sogar monatelang) Fehler in der Welt verbreitet!

1. Kapitel :: Fehler – Wer? Wo? Wie? Was?
Grob gesagt kann man Fehler beim Programmieren in zwei große Gruppen unteteilen:

1. Programmiertechnische Fehler
In diese Kategorie fallen Fehler in der Programmiertechnik sowie -Logik. Als Beispiel seien hier folgende beiden Codeausschnitte zu nennen:

if(Money = 1)	{
     std::cout << "Du hast nicht viel Geld :(";
}

bool Key[255];
for(int cnt = 0; cnt <= 255; cnt++)	{
    Key[cnt] = true;
}

Der erste Codeausschnitt zeigt einen sehr häufig auftretender Fehler, der selbst erfahrenen Programmierern öfters unterläuft, als es einem lieg sein kann: Der Variablen Money wird der Wert 1 zugewiesen, der Ausdruck ergibt einen Wert ungleich 0, und somit ist die Bedinung immer erfüllt und Money beinhaltet immer den Wert 1.
Der zweite Codeausschnitt zeigt eine typische "Access Violation": Durch "bool Key[255]" werden die Elemente Key[0] bis Key[254] reserviert, ein Zugriff auf den nicht existierenden Index 255 führt zu einer Zugriffsverletzung.

Diese Art von Fehlern ist meistens nicht ganz so kritisch, da die meisten dieser Fehler (welche zum Großteil auch oft einfach nur Vertipper auf der Tastatur sind) vom Compiler und/oder Linker gemeldet werden, welche dann des öfteren das weitere Kompilieren verweigern.

2. Logische Fehler
Nich zu verwechseln mit den Programmierlogischen Fehlern, sind diese Fehler, oder meistens einfach nicht Beachtete Situationen, Zustände etc., häufig die tükischsten, welche einem Programmierer begegnen könne. Dazu gehören sowohl recht einfache Vertreter, wie das Müller-Meier-Beispiel aus dem Vorwort, als auch komplexeste falsch einkalkulierte Situationen, auf die der Programmierer im Leben nicht kommen würde.

Auf diese Art der Fehler, und deren Vorbeugung so weit wie nur irgend möglich, wird sich der weitere Artikel beschäftigen!

2. Kapitel :: Ausnahmen – Probieren, Fangen und Werfen
Nach dem doch eher erstickend-theoretischen Vorwort und dem keinen Deut besseren 1. Kapitel wollten wir in diesem Kapitel nun endlich ein wenig Praxis ins Spiel bringen!
In C++ gibt es drei wichtige Schlüsselwörter, welche dir bei der alltäglichen Fehlerbehandlung des öfteren begegnen werden (es soll sogar Programme geben, die von den folgenden Schlüsselwörtern mehr beinhalten, als if-Zweife!)

try
"try" leitet einen Block ein, in welchem der risikobehaftete Code steht. Es kann als eine Art Gruppierung aufgefasst werden, die jene Funktionen gruppiert, auf die mit dem zweiten Schlüsselwort (s. unten) zentralisiert reagiert werden kann.

catch
"catch" wird genutzt, um beim Auftreten einer Exception (s. unten) zentralisiert auf diese zu reagieren. Diesem Schlüsselwort kann als Begriff eine Klasse übergeben werden, die auf die entsprechende Exception passt. So kann auf unterschiedliche Fehler unterschiedlich reagiert werden. Zusätzlich können ihm drei Punkte übergeben werden, was signalisiert, dass die folgende Verzweigung auf jede Exception passt. Das ganze kann man sich so ähnlich vorstellen wie das "case" in einer "switch"-Verzweigung.

Eine Exception passt auch dann auf einen catch-Block, wenn die in ihm angegebene Klasse eine von der Exception abstammenden Klasse ist.

throw
Mit "throw" kann innerhalb eines try-Blocks eine Exception ausgelöst werden, auf die ein catch anspringen kann. throw wird ein Datentyp oder, was der Sache wesentlich mehr Flexibilität verleit, eine Klasse übergeben. An diesem Datentyp bzw. dieser Klasse wird dann geprüft, ob ein catch vorhanden ist, welches auf eben jene Klasse passt.
Beim Auftreten einer Exception werden die Destruktoren aller lokalen Klassen, structs und unions aufgerufen!

So, nun endlich mal ein wenig Code:

double Divide(double ValueA, double ValueB)    {
    if(ValueB == 0)   {
       throw new int;
   }
   return ValueA / ValueB;
}

Die Funktion teiltt den Wert des ersten Parameters durch den des zweiten. Wenn ValueB jedoch 0 ist (was eine Division durch 0 zur Folge hätte), wird eine Exception vom Typ int* erzaugt. Die Funktion ist damit beendet! Verwenden könnte man die Funktion wie folgt:

#include <iostream>

int main()    {
    int Result;
    try    {
        Result = Divide(5, 0);
    }    catch(int*)    {
        std::cout << "Division durch 0 ist nicht möglich!";
    }
}

Tritt innerhalb des try-Blocks eine Exception vom Typ int* auf, so wird dies mit der Meldung "Division durch 0 ist nicht möglich" gehandhabt. Da der zweite der Funktion Divide übergebene Parameter (Zeile 5) 0 ist, würde eine Division durch 0 stattfinden. Da die Funktion Divide() jedoch in eben jener Situation eine Exception vom Typ int* erzeugt, springt unser catch-Ausdruck in Zeile 6 an und fängt diese ab. Somit haben wir das unkontrollierte Verhalten im Falle einer Division durch 0 durch eine kontrollierte Fehlermeldung ersetzt, welche wir bei Bedarf jederzeit ausbauen können (z.B. zu einer richtigen Fehlerbehebung, zum neuerfragen der Daten bis gültige vorliegen, zum Eintragen des Fehlers in ein Protokoll uvm.)!

3. Kapitel :: Klassen – Anwendung und Vorteile
Eins vorweg: Für das Verständig dieses Kapitels (und ab hier an auch für den Rest des Artikels) sind funamentale Kentnisse der objektorientierten Programmierung unabdingbar!

Im vorherigen Kapitel hatten wir unsere Exception mit int typisiert; so haben wir an Stelle der bevorstehenden Division durch 0 eine Exception des Typs "Pointer auf int" oder einfach nur int* erzeugt. Diese haben wir in dem try-Block abgefangen. Was aber, wenn wir dem Datentyp mehr Informationen über den aufgetretenen Fehler entnehmen wollen?

In der Praxis werden für Exceptions oft ganz eigene Klassenhierachien verwenden, bei den z.B. der Name die Art der Exception bestimmen kann. Zudem kann man Member-Funktionen implementieren, welche weitergehende Auskunft über den Fehler geben. Eine solche Hierachie, bezogen auf unser Beispiel aus Kapitel 2, könnte z.B. wie folgt aussehen (das "e" vor jedem Klassennamen steht für "Exception"):

eMathException
   -> eDivisionByZero
   -> eSqrtOfNegative
   -> eOutOfRange

Nun könnte man in einer Rechenoperation auf eben jene Fehler prüfen und, wenn sie auftreten, entsprechende Exceptions erzeugen.

Beachte, dass eine Exception-Klasse ebenfalls für jede von ihr abgeleitete Exception passt!
Der folgende catch-Block passt also sowohl auf eine eMathException-Exception als auch auf eine eDivisionByZero-Exception:

try   {
   // Irgendwelche gefährlichen Aktionen ...
}   catch(eDivisionByZero*)   {
}

Aus diesem Grund werden von anderen Exception-Klassen abgeleitete Klassen immer vor ihren Ursprungsklassen abgefragt:

try   {
   // Irgendwelche gefährlichen Aktionen ...
}   catch(eMathError*)   { // Fange alle mathematischen Exceptions ab...
}   catch(eDivisionByZero*)   { // Macht keinen Sinn, da Zeile 3 bereits alle eDivisionByZero-Exceptions abfängt!
}

try   {
   // Irgendwelche gefährlichen Aktionen ...
}   catch(eDivisionByZero*)   { // So ist's richtig!
}   catch(eMathError*)   { // Fange alle mathematischen Exceptions ab, falls keine spezielle aufgetreten ist
}

Schlussendlich passt

catch(...)

auf jede Exception, gleich welchen Typs. Dieser catch-Block sollte als letzter nach allen speziellen Prüfungen erfolgen. Insgesamt solltest du die Reihenfolge der Exception-Abfragen nach der Speziefik der Exceptions ordnen: Die sehr speziellen (eDivisionByZero -> Teilung duch 0) am Anfang, die weniger speziellen (eMathException -> Allgemeiner, mathematischer Fehler) danach, und ganz am Ende mit "catch(...)" auf alle verbleibenden Exception prüfen. Beachte, dass, wenn ein catch-Block passt, die weiteren nicht mehr geprüft werden, die Anweisung ist somit beendet!

Eine vollständige Implementierung aller Techniken dieses Kapitels könnte wie folgt aussehen:

#include <iostream> // Bei älteren Compilern ggf. #include <iostream.h>
#include <math.h>
using namespace std;

class eMathException   {   };
class eDivisionByZero : public eMathException   {   };
class eSqrtOfNegative : public eMathException   {   };

// MyCalc() führt eine etwas komplexere Berechnung durch, bei der zuerst
// ValueA durch ValueB geteilt wird und anschließend aus dem
// Ergebnis die Wurzel gezogen wird.
double MyCalc(double ValueA, double ValueB)   {
   // Zuerst prüfen wir die Werte:
   if(ValueB == 0)   {
      throw new eDivisionByZero;
   }
   double PreResult = ValueA / ValueB;

   // Nun prüfen wir, ob das Ergebnis der Teilung negativ ist
   // (falls ja können wir ohne weiteres keine Wurzel daraus ziehen):
   if(PreResult < 0)   {
      throw new eSqrtOfNegative;
   }

   double FinalResult;
   try   {
      FinalResult = sqrt(PreResult);
   }   catch(...)   {
      throw new eMathException;
   }
   return FinalResult;
}

int main()   {
   double ValueA = 45, ValueB = 5, ValueC;

   try  {
      ValueC = MyCalc(ValueA, ValueB);
      cout << ValueC;
   }   catch(eDivisionByZero*) {
      cout << "Division durch 0 ist nicht erlaubt!";
   }   catch(eSqrtOfNegative*)  {
      cout << "Wurzel aus negativer Zahl nicht im reellen Zahlenbereich!";
   }   catch(eMathException*)   {
      cout << "Ein mathematischer Fehler ist aufgetreten!";
   }

   return 0;
}

Dieser Code wirkt auf den ersten Blick etwas erdrückend, ist aber bei genauerem Hinsehen ganz einfach zu verstehen:
- Die Funktion MyCalc() übernimmt zwei Parameter.
- Sie teilt den erste Parameter durch den zweiten.
-> Wenn der zweite Parameter 0 ist, wird eine eDivisionByZero-Exception ausgelöst (Division durch 0 ist mathematisch undefinierT)
- Sie zieht aus dem Ergebnis der Division die Wurzel.
-> Wenn das Ergebnis der Division negativ ist, wird eine eSqrtOfNegative-Exception ausgelöst (Wurzel aus negativer Zahl existiert nicht im reelen Zahlenbereich.
- Wenn beim Wurzelziehen irgend ein sonstiger Fehler auftritt, wird eine eMathException-Exception ausgelöst (ein nicht weiter definierter, allgemeiner mathematische Fehler. Diese Exception-Klasse passt sowohl auf eDivisionByZero als auch auf eSqrtOfNegative).
- Sie gibt den errechneten Wert zurück (wenn keine der obigen Exceptions aufgetreten ist, ansonsten 0)

In der main()-Funktion definieren wir die drei Variablen ValueA (45), ValueB (5) und ValueC (in welcher das Ergebnis gespeichert werden soll). In unserem try-Block führen wir MyCalc() mit ValueA und ValueB als Parameter aus, und prüfen in den catch-Blöcken zuerst, ob eine Teilung durch Null (eDivisionByZero), eine Wurzel aus einer negativen Zahl (eSqrtOfNegative) oder irgend ein anderer mathematischer Fehler aufgetreten ist. Ist dies der Fall, geben wir eine entsprechende Meldung aus. Ist dies nicht der Fall, wird der errechnete Wert ausgegeben.

Führst du das obige Programm so wie geschrieben aus, wird die Zahl 3 auf dem Bildschirm ausgegeben (wie erwartet: 45 / 5 = 9, Wurzel aus 9 = 3).
Änderst du jedoch in Zeile 35 das "ValueA = 45" nach "ValueA = -45", so wird in MyCalc() (Zeile 11) der negative Wert erkannt und eine eSqrtOfNegative-Exception ausgelöst. Diese wird in Zeile 47 abgefangen und die Meldung "Wurzel aus negativer Zahl nicht im reellen Zahlenbereich" ausgegeben.
Änderst du in Zeile 35 hingegen das "ValueB = 5" nach "ValueB = 0", so wird in Zeile 15 eine eDivisionByZero-Exception ausgelöst, in Zeile 41 abgefangen und die Meldung "Division durch 0 ist nicht erlaubt!" ausgegeben. Selbst wenn ValueA weiterhin -45 ist, wird ihnen nun die eDivisionByZero-Exception abgefangen. Warum? Weil auf sie in MyCalc() zuerst reagiert wird, und nach dem Auslösen dieser Exception die Funktion beendet ist!

7H3 N4C3R

Auch wenn Du noch nicht fertig bist - schonmal ein wichtiger Einwurf von mir, quasi eine Exception die ich beim Lesen bekommen habe

Ein sehr wichtiger Grundsatz mit Exceptions ist:

throw by value
catch by reference

also nicht throw new eDivisionByZero;
sondern throw eDivisionByZero();

und später dann:
catch (const eDivisionByZero& e) /// nur mit const Referenz auffangen
{
}

Ansonsten wirft man mit irgendwelchen Zeigern um sich, von denen niemand mehr weiß, wann man sie zu löschen hat (das passiert in deinem Beispiel nämlich nicht -> Speicherloch).
Das ist nicht nur einfach meine Meinung dazu (sonst hätte ich mir den Kommentar sicherlich gespart ), sondern eine allgemeine Grundlage.

Reyx

Mh?
Peinlich
Hast natürlich recht, 'n ganz dummer Fehler -> Wird sofort korrigiert!

Hab da mein Dokument oben und unten umgekrempelt, aber wie mir das passieren konnte, ist mir echt ein Rätsel...

Reyx

Reyx schrieb:

Pointer-Exceptions entfernt (keine Ahnung, wie die mir untergekommen sind) und einige Rechtschreibfehler korrigiert.

Exception Handling
Wo Menschen arbeiten, da machen Sie Fehler.
Maschinen währen unfehlbar, würden sie nicht exakt das tun, was der Mensch ihnen befiehlt.
Der Mensch vererbt der Maschine die Fehlbarkeit, welche die Maschine an sich nicht kennt.
Jeder Fehler der Maschine ist somit auf den Menschen zurück zu führen, welcher die Pflicht hat, diese Vererbung soweit wie möglich einzugrenzen.

Vorwort :: Fehlerbehandlung – Fluch oder Segen?
Du, als Programmierer, hast es leicht: Das Programm, welches du entwickelts, macht ganz exakt das, was du willst. Der Endanwender jedoch -sei es der Kunde, der Informatiklehrer deiner Schule oder schlicht und ergreifend dein Freund von nebenan- hat ein schwereres Los gezogen: Er weiß nicht, wie das Programm funktioniert. Er weiß nicht, welche Handhabung es von ihm erwartet!

Als Beispiel soll folgende (zum Zweck der Demonstration sehr einfache) Situation dienen: Dein Programm soll den Zins c eines Geldbetrages a anhand eines Zinssatzes b berechnen.
Eine einfache Formel dazu könnte wie folgt aussehen:

c = a / 100 * b

Diese Formel wirkt einfach, ist funktional, und könnte ohne Probleme so in eine entsprechende Funktion in C++ umgesetzt werden.
Nun stehst du als Programmierer vor der Situation, dein Programm zu verwenden. Du besitzt einen Geldbetrag von 20.000 € und einen Zinssatz von 4 %, und möchtest dein Programm dazu benutzen, den Zins auszurechnen. Du weißt: dein Programm erwartet einen Geldbetrag und einen Zinssatz, und gibst ihm dementsprechend, völlig selbstverständlich, eben diese Informationen:

c = 20000 / 100 * b = 800

Wie erwartet errechnet dir das Programm den Zins von 800 € - was sonst sollte es auch tun? Es ist eine einfache Formel, die genau das tut, was man von ihr erwartet: Den Zins berechnen. Richtig?

Falsch! Du als Programmierer weißt genau, was das Programm von dir erwartet (bzw. was du als Programmierer von dir selbst bzw. dem Anwender im Allgemeinen erwartest). Was nun aber, wenn jemand anders dein Programm benutzt? Was, wenn dieser Jemand aus Verwirrung oder, was leider auch des öfteren der Fall ist, aus Boshaftigkeit dem Programm die Werte „Müller“ und „Meier“ angibt? Dein Programm stellt die entsprechende Formel auf:

c = "Müller" / 100 * "Meier"

Für eine solche, offensichtlich falsche, Verwendung hast du dein Programm in den allermeisten Fällen nicht konzipiert. Es soll den Zins berechnen, nicht mehr und nicht weniger ... und ganz bestimmt nicht den armen "Müller" in einhundert Stücke zerlegen, um anschließend den "Meier" unterzumischen!
Solche Situationen sind es, in denen die Maschine auf die Umsicht des Programmierers, auf dich, angewiesen ist, denn sie selbst kann eine solche Situation nicht bzw. nur sehr schwer erkennen (und wo Maschinen versuchen, selbstständig entscheidungen zu Treffen, kann die Sache nur noch schlimmer werden)!
Hier bist also du gefragt, um der Maschine zu sagen: Nein! kein "Müller", kein "Meier", nur X Werte darfst du verwenden. Und in Y Situation musst du dich Z verhalten!

Ist die Fehlerbehandlung nun ein Fluch oder ein Segen? Nun, ich denke, beides. Für den Programmierer, welcher Stunden mit dem debuggen seines Codes zubringt, sind sie sicherlich ein Fluch. Für die Maschine jedoch, die selbst über keinerlei wirkliche Intelligenz verfügt, ist sie der einzige Anhaltspunkt, der einzige Leitfaden, an dem sie sich in einer unerwarteten Situation orientieren kann. Sie ist somit für die Maschine von essenzieller (und auch existenzieller) Bedeutung! Und der Endanwender? Nun, der erwartet, das das Programm, welches er, vielleicht für teures Geld, vielleicht mit viel Mühe, erstanden hat, auch so funktioniert, wie er es erwartet! Ist dies dann nicht der Fall, kann es zu Frustration (und dementsprechend vielleicht zu einer Rufschädigung deiner Selbst) oder auch zu Reklamation kommen. Bei groben Fehlern könnte dir sogar Fahrlässigkeit vorgeworfen werden! Demnach ist die Fehlerbehandlung ebenfalls für dich als Programmierer von existenzieller Bedeutung und darf niemals zu kurz kommen oder gar ignoriert werden!

Lieber ein Programm, welches nach zwei Tagen Programmierzeit wirklich das tut, was es soll, und dabei auf weitestgehend alle möglichen Fehler entsprechend reagieren kann, als eines, welches nach einer Stunde freigegeben wird, und dann Wochenlang (oder vielleicht sogar monatelang) Fehler in der Welt verbreitet!

1. Kapitel :: Fehler – Wer? Wo? Wie? Was?
Grob gesagt kann man Fehler beim Programmieren in zwei große Gruppen unteteilen:

1. Programmiertechnische Fehler
In diese Kategorie fallen Fehler in der Programmiertechnik sowie -Logik. Als Beispiel seien hier folgende beiden Codeausschnitte zu nennen:

if(Money = 1)	{
     std::cout << "Du hast nicht viel Geld :(";
}

bool Key[255];
for(int cnt = 0; cnt <= 255; cnt++)	{
    Key[cnt] = true;
}