Defensives Programmieren

Unter defensivem Programmieren wird eine Programmierung von Computersystemen verstanden, die möglichst viele Voraussetzungen selbst überprüft, bevor der eigentliche Selbstzweck erfüllt wird. Ein Programmierer ist mit verschiedenen bekannten und unbekannten Aspekten bezüglich Benutzer-Eingabe, verschiedener Betriebssysteme und -Versionen konfrontiert. Die so defensiv programmierten Applikationen sind misstrauisch gegenüber allen Eingaben und Voraussetzungen und verhalten sich gegenüber Verstößen robust. Durch das Voraussehen möglichst vieler Umstände laufen sie weiter oder brechen in einem geordneten Prozess ab.

Ein Alternativansatz zur defensiven Programmierung ist Design by contract. Dabei stellt diejenige Komponente, welche die Dienstleistung einer anderen Komponente in Anspruch nimmt, lediglich auf der Basis eines Vertrages eine Reihe von Vorbedingungen sicher und verlässt sich auf Nachbedingungen, die für die Dienstleistung im Vertrag definiert wurden. Bei defensiver Programmierung wären hingegen die Vorbedingungen unklar, während die Nachbedingungen von der in Anspruch nehmenden Komponente überprüft werden müssten.

Ein System muss sich nicht einem einzigen Konzept verschreiben. Grundsätzlich lässt es sich so aufteilen, dass Einwirkungen von außen (Benutzereingaben, Datenimport, API) defensiv zu handhaben sind, während das bei inneren Abläufen nicht erforderlich ist.

Beispiele
Potenziell unerwartete Benutzereingabe, mit der nicht wie geplant umgegangen werden kann und die deshalb bei defensivem Programmieren abgefangen werden muss
  • Ein Druckereintrag soll gelöscht werden. Das defensiv erstellte Programm prüft zuerst, ob der anzusprechende Drucker überhaupt vorhanden ist. Das Programm prüft den Rückgabewert der Löschfunktion. Falls wegen fehlender Zugriffsrechte nicht gelöscht werden kann, versucht das Programm sich die Rechte einzuräumen und probiert das Löschen nochmals.
  • Eine Datei soll von einem Verzeichnis in ein anderes Verzeichnis kopiert werden. Ein defensives Programm prüft, ob das Quellverzeichnis vorhanden und lesbar ist. Dann wird geprüft, ob das Zielverzeichnis vorhanden und beschreibbar ist. Ist es nicht vorhanden, so legt das Programm das benötigte Verzeichnis selbst an und verschafft sich ggf. vorher die dazu erforderlichen Rechte. Letztendlich wird dann die Datei in die verifiziert vorhandenen und erreichbaren Verzeichnisse kopiert.
  • Die Eingabe eines Benutzers verläuft den Erwartungen völlig konträr (siehe Abbildung). Ein Programmierer mit Weitblick erkennt solche möglichen Situationen und überprüft die Benutzereingaben, bevor die eigentliche Verarbeitung beginnt. Im Beispiel der Abbildung müsste das Programm den Prozess abbrechen und dem Benutzer eine Meldung ausgeben, dass dieser die Eingaben korrigieren muss.

Gegenteil des defensiven Programmierens

Der Programmierer hat – je nach Programmiersprache – verschiedene weitere Möglichkeiten des Exception Handlings, der Behandlung von Ausnahmen. Diese Möglichkeiten werden jedoch nicht mehr unter dem Begriff defensive Programmierung zusammengefasst, sondern es geht darum, beliebig auftretende, nicht vorhersehbare Fehler abzufangen. Gerade konträr zur defensiven Programmierung verhält sich beispielsweise die in Visual Basic beliebte Anweisung On Error Resume Next (umgangssprachlich aus unbekannter Quelle auch OERNy genannt, auf Deutsch „mach einfach weiter“). Der Vorteil dabei ist, dass die Applikation nicht abstürzt, dies allerdings mit unabsehbaren Folgen, das heißt, das Resultat kann unter Umständen völlig inkorrekt sein.

This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.