Ein Error oder Bug ist ein Programm- beziehungsweise Softwarefehler, der sich als Dysfunktion äußert und oft als Fehlermeldung oder im Internet als Statusmeldung angezeigt wird. Computerprogramme können, bis auf kleine Programme, aufgrund ihrer Komplexität nicht vollkommen fehlerfrei sein. Stabile Software enthält ebenfalls Mängel, ohne aber ernsthaften Fehlfunktionen zu unterliegen.

Ein Error kann sich unterschiedlich bemerkbar machen: durch klare Fehlermeldungen, kryptische Codes, unerwartete Programmabbrüche, eingefrorene Oberflächen, Performance-Einbrüche oder stille Dateninkonsistenzen. Besonders tückisch sind Fehler, die nur sporadisch auftreten (Flaky Errors) oder nur unter Last bzw. in bestimmten Konstellationen sichtbar werden.

Falls eine Fehlfunktion vorliegt, ohne dass eine eindeutige Fehlermeldung erscheint, helfen Analyseprogramme (Debugger), der Ursache auf den Grund zu gehen. Um Fehler zu beheben, werden sogenannte Patches (Flicken) programmiert, die den Käufern oder Nutzern der Programme zumeist als Updates (Aktualisierungen) zum Herunterladen im Internet zur Verfügung gestellt werden.

Zur Fehlersuche und -behebung kommen zusätzlich zum Debugger häufig zum Einsatz:

• Logging und Tracing (z. B. strukturierte Protokolle, Crash-Dumps, Core-Dumps)
• Profiler (Zeit-, Speicher- und IO-Profiler) zur Performance-Analyse
• Automatisierte Tests (Unit-, Integrations-, System- und End-to-End-Tests)
• Fuzzing und Property-based-Testing für robuste Eingabevalidierung
• Statische und dynamische Codeanalyse zur frühen Erkennung typischer Fehlerquellen
• Hotfixes und Rolling Updates mit klarer Versionierung und Changelogs

Wie entsteht ein Error?

Computerprogramme beruhen auf Programmiersprachen, die ihren eigenen Regeln folgen – sie besitzen sozusagen ihre jeweils spezielle Grammatik. Darin lösen bereits geringfügige Abweichungen Fehlfunktionen aus, so wie in der Schriftsprache ein fehlendes Komma den Sinn eines Satzes entstellt. Wenn Programmierer unter Zeitdruck arbeiten oder bereits vorhandene Programme erweitern, ohne auf Fehler und Wiederholungen zu achten, sind spätere Fehlfunktionen unausweichlich. Der statistische Durchschnittswert beträgt zwischen zwei und drei Fehlern pro 1000 Zeilen Programmcode. Zur Vermeidung solcher Mängel werden standardisierte Vorgehensweisen während der Projektphasen (Planung, Analyse, Entwurf, Programmierung, Tests, Betrieb) angewendet.

Weitere typische Ursachen für Errors:

• Komplexität und technische Schulden: Wachsende Codebasis, unklare Architektur, fehlende Modularisierung.
• Konkurrenz und Parallelität: Race Conditions, Deadlocks, fehlende Synchronisation in Multi-Thread- oder verteilten Systemen.
• Schnittstellen und Abhängigkeiten: Änderungen an Bibliotheken, Treibern oder Services ohne kompatible Anpassungen.
• Ungenaue Anforderungen: Missverständnisse zwischen Stakeholdern führen zu funktionalen Lücken.
• Konfiguration und Umgebung: Falsche Umgebungsvariablen, fehlerhafte Zertifikate, unterschiedliche Laufzeitumgebungen.
• Internationalisierung und Datenformate: Zeichencodierung, Lokalisierung, Zeitzonen, Rundungs- und Gleitkommafehler.
• Ressourcenengpässe: Speicher- oder Dateihandle-Leaks, volle Datenträger, Netzwerk-Timeouts.

Gute Praxis gegen Fehlerentstehung: Code-Reviews, Pair Programming, Test-Driven Development, saubere Eingabevalidierung, defensive Programmierung und reproduzierbare Builds reduzieren die Fehlerquote über den gesamten Lebenszyklus hinweg.

Welche Fehler können auftreten?

Software kann Syntax-, Laufzeit-, Design- und logische Fehler enthalten, Regressionsbugs bei neuen Versionen kommen ebenfalls vor. Daneben gibt es Fehler, die nur begrenzt im Verantwortungsbereich der Programmierer liegen, etwa ein missverständliches Bedienkonzept oder äußere Einflüsse der Betriebsumgebung. Syntaxfehler verstoßen gegen die Regeln der jeweiligen Programmiersprache (Quellcode), sodass sie nicht in Maschinencode übersetzt (kompiliert) werden kann. Laufzeitfehler entstehen beim Ausführen eines Programms. Sie beruhen auf falsch platzierten oder auf die falsche Weise implementierten Funktionen beziehungsweise Programmbausteinen, wenn etwa auf geschützten Speicherplatz oder auf nicht vorhandene Dateien zugegriffen werden soll.

Eine andere Ursache für den Laufzeitfehler kann die unpassende Laufzeitumgebung sein, wenn zum Beispiel ein an sich stabiles Programm auf einem ungeeigneten Betriebssystem installiert wurde. Den Grund eines Laufzeitfehlers herauszufinden, ist deshalb oft nicht ganz einfach, weil sich dieser Fehlertyp zumeist unspezifisch äußert, indem das Programm beispielsweise „abstürzt“ (sich selbst beendet) oder „einfriert“, sodass keine Eingabe mehr möglich ist. Designfehler betreffen entweder bereits das Konzept der Software oder das konkrete Softwaredesign, weshalb das Programm den gestellten Anforderungen letztlich nicht genügt. Die häufigsten Ursachen für Designfehler sind fehlende Spezialkenntnisse der Programmierer sowie Missverständnisse zwischen Entwicklern und Nutzern/Auftraggebern bezüglich des Anforderungsprofils.

Fehler des Bedienkonzepts sind eigentlich keine Designfehler, denn das jeweilige Programm kann durchaus zuverlässig arbeiten – es verhält sich jedoch anders, als die Anwender es erwarten. Logische oder semantische Fehler werden durch Fehlschlüsse und Fehlinterpretationen seitens des Programmierers verursacht. Sie entstehen vor allem dann, wenn Problemlösungsansätze (Algorithmen) missverstanden werden. Regressionsbugs sind bereits behobene Fehler aus früheren Programmversionen, die später erneut erscheinen. In äußerst seltenen Fällen können Fehler durch die Betriebsumgebung verursacht werden; denkbar sind vor allem physikalische Phänomene wie extreme Temperaturen, elektromagnetische Felder und Erschütterungen.

Erweiterte Einordnung und Beispiele:

• Syntaxfehler: Tippfehler, fehlende Klammern, falsche Typannotationen – vom Compiler/Interpreter früh erkannt.
• Laufzeitfehler: Nullzeiger-Dereferenzierung, Division durch Null, Zugriffe auf geschützten Speicher, Out-of-Bounds, Zeitüberschreitungen, Netzwerkfehler.
• Logische Fehler: Falsche Bedingungen, off-by-one, vertauschte Einheiten/Parameter, unvollständige Randfallbehandlung.
• Designfehler: Ungeeignete Architektur, fehlende Skalierbarkeit, enge Kopplung, unzureichende Fehlertoleranz.
• Konkurrenzfehler: Race Conditions bei gemeinsamem Speicher, Deadlocks durch zyklische Sperren.
• Ressourcenfehler: Speicherlecks, Deskriptor-Leaks, nicht geschlossene Dateien/Sockets.
• Internationalisierung: Zeichenkodierung (UTF-8 vs. ISO-8859-1), Datums-/Zeit- und Locale-Probleme.
• Regressionsfehler: Wiederkehrende Bugs nach Refactoring oder Versionswechseln.

Risiken durch Programmfehler

Mag ein „Absturz“ im privaten Bereich lästig sein und kann das fehlerhafte Belegen von zunehmendem Speicherplatz zu Problemen führen, sind nur Programmfehler bei lebenswichtigen Funktionen tatsächlich gefährlich. Unfälle mit Flugzeugen, medizinischen Geräten oder auch enorme wirtschaftliche Einbußen sind bisher in Einzelfällen zu verzeichnen. Betroffen sind sämtliche Bereiche, die sich auf Computersteuerung stützen, insbesondere Militär, Luft- und Raumfahrt, Börsen und Kliniken.

Konkrete Auswirkungen im Überblick:

• Sicherheitskritische Systeme: Fehlfunktionen in Avionik, Medizintechnik oder Industrieanlagen können Menschenleben gefährden.
• Finanzielle Schäden: Produktionsstillstand, Handelssystem-Ausfälle, Vertrags- und SLA-Verletzungen.
• Compliance und Haftung: Verstöße gegen Normen (z. B. in Automotive/Luftfahrt) und daraus resultierende rechtliche Folgen.
• Datenintegrität: Falsch verarbeitete oder inkonsistente Informationen führen zu falschen Entscheidungen.

Risikominimierung: Mehrstufiges Testen, formale Verifikation in kritischen Bereichen, Redundanz und Failover, Monitoring/Alerting sowie klar definierte Notfall- und Patch-Prozesse reduzieren das Schadenspotenzial nachhaltig.

Angestrebte Fehlerfreiheit

Daraus folgt, dass in entsprechend sensiblen Bereichen Fehlerfreiheit angestrebt wird. De facto ist es zwar nicht möglich, komplexe Programme, an denen mehrere Programmierer arbeiten, restlos korrekt zu schreiben. Trotz langwieriger Tests können noch während des Betriebs Probleme auftauchen. Je früher Fehler programmiert wurden und je später sie entdeckt werden, desto schwieriger ist es, die Ursache zu ergründen. Dennoch erlaubt ein sorgfältig geplantes, durchgeführtes und dokumentiertes Vorgehen, das jeweilige Projekt nahezu einwandfrei abzuwickeln. Die Schwierigkeit liegt in der mangelnden Nachweisbarkeit der Fehlerfreiheit, weshalb ein augenscheinlich makelloses Programm als stabil oder robust bezeichnet wird, nicht jedoch als fehlerfrei.

Aktuelle Vorgehensweisen für hohe Software-Qualität:

• Qualitätssicherung über den gesamten Lebenszyklus: CI/CD-Pipelines, automatische Builds, Testabdeckung und Code-Metriken.
• Statische/Dynamische Analyse: Erkennen typischer Muster (Nullzugriffe, Leaks, Threading-Fehler) vor dem Rollout.
• Fuzzing und Chaos-Tests: Widerstandsfähigkeit gegenüber unerwarteten Eingaben und Störungen prüfen.
• Observability: Strukturierte Logs, Metriken und Traces zur schnellen Ursachendiagnose im Betrieb.
• Defensive Programmierung: Explizite Fehlerbehandlung, Timeouts, Circuit Breaker, Retry-Strategien.

Error im Internet

Jede Anfrage an einen Server wird mit einem Statuscode beantwortet. Diese Statusmeldungen werden in Hunderter-Schritte eingeteilt, wobei die 100er Informationscharakter besitzen, die 200er positive Rückmeldungen sind, die 300er auf Umleitungen verweisen, die 400er und 500er hingegen tatsächlich Fehler bedeuten.

Hinweis zum Stand der Technik: Die bekannten HTTP-Statuscodes gelten konsistent über HTTP/1.1, HTTP/2 und HTTP/3; neuere Protokollversionen ändern die Semantik der Codes nicht, sondern optimieren Transport und Parallelisierung.

Clientfehler – ab Error 400
Wenn vom Nutzer eine ungültige, formal/technisch unpassende oder unberechtigte Anfrage an einen Server erfolgt, antwortet dieser mit einem 400er-Statuscode, wobei der Fehler nicht immer eindeutig dem Nutzer zugeschrieben werden kann. Eine der bekanntesten Statusmeldungen ist Error HTTP 404 Not found (Die Seite konnte nicht gefunden werden.). In diesem Fall hat der Nutzer entweder eine falsche URL (Internetadresse) eingegeben oder er ist einem sogenannten toten Link gefolgt – einem Verweis auf eine nicht mehr (auf diesem Server) existierende Seite.

• 400 Bad Request: Ungültige Syntax der Anfrage.
• 401 Unauthorized: Authentifizierung fehlt oder ist abgelaufen.
• 403 Forbidden: Zugriff verweigert trotz gültiger Identität.
• 404 Not Found: Ressource nicht vorhanden oder entfernt.
• 405 Method Not Allowed: HTTP-Methode für die Ressource unzulässig.
• 408 Request Timeout: Server wartet zu lange auf die Anfrage.
• 409 Conflict: Versionskonflikte oder widersprüchliche Zustände.
• 410 Gone: Ressource dauerhaft entfernt.
• 413/414/415: Zu große Anfragen, zu lange URLs, nicht unterstützte Medientypen.
• 422 Unprocessable Content: Semantisch fehlerhafte, aber technisch gültige Anfrage.
• 429 Too Many Requests: Rate-Limit überschritten.

Serverfehler – ab Error 500
Ist die Anfrage seitens des Nutzers zwar korrekt, ohne aber vom Server bearbeitet werden zu können, antwortet dieser mit einer 500er-Statusmeldung, wobei auch hier gilt, dass die Zuschreibung des Fehlers nicht eindeutig sein muss. Der häufigste dieser Statuscodes ist Error HTTP 500, der als Sammelcode für Serverausfälle oder nicht spezifizierbare Serverfehler gilt.

• 500 Internal Server Error: Allgemeiner Fehler ohne spezifische Ursache.
• 501 Not Implemented: Funktionalität nicht verfügbar.
• 502 Bad Gateway: Fehlerhafte Antwort eines Upstream-Servers.
• 503 Service Unavailable: Überlastung oder Wartung, oft mit Retry-After.
• 504 Gateway Timeout: Zeitüberschreitung bei Upstream-Anfrage.
• 507 Insufficient Storage: Speicherplatz oder Kontingent erschöpft.

Praxis-Tipps zur Fehleranalyse im Web:

• Request/Response-Details prüfen (Header, Payload, Content-Type, Caching).
• Authentifizierung/Autorisierung und Tokens verifizieren.
• Server-Logs, Korrelation-IDs und Metriken auswerten.
• Konfiguration von Proxy, CDN, Firewall und TLS-Zertifikaten kontrollieren.

Quellen:
http://de.wikipedia.org/wiki/Programmfehler
http://de.wikipedia.org/wiki/HTTP-Statuscode
http://de.wikipedia.org/wiki/Toter_Link

Häufige Fragen und Antworten