und Exceptions

Wenn ein Fehler – ein Error – in einem Programm auftritt, wird eine Meldung ausgegeben. Es gibt verschiedene Arten von Errors. Manche treten während dem Compiling, der Umwandlung von Skript in einer Programmiersprache zu Maschinencode, auf. Andere treten erst während der Laufzeit eines Programmes auf. Für auftretende Fehler gibt es in den verschiedenen Programmiersprachen verschiedene Fehlermeldungen, sogenannte Exceptions. Versursacht ein Error eine Fehlermeldung, spricht man davon, dass der Fehler eine Exception raised (hervorruft). Die entstandene Fehlermeldung muss bearbeitet werden, um ein funktionierendes Skript zu erhalten. Solch einen Vorgang bezeichnet man als Errorhandling. Dabei wird das weitere Vorgehen nach dem Auftreten der Fehlermeldung beschrieben. Man spricht dann vom Catchen der Exception.
Fehlermeldungen können auch manuell definiert und hervorgerufen werden. Nicht für jede Eventualität steht in jeder Programmiersprache eine Fehlermeldung zur Verfügung. Handelt es sich zum Beispiel um ein sehr spezifisches Problem, kann eine eigene Fehlermeldung und gewisse Parameter definiert werden, wann eine entsprechende Fehlermeldung hervorgerufen werden soll. Wenn eine grundlegende Annahme des Codes beispielsweise nicht erfüllt wird, oder seltene, außergewöhnliche Ereignisse auftreten, erkennt die Programmiersprache oder Entwicklungsumgebung (IDE) das nicht zwangsläufig als Error. Es gilt als Good Practice diese Sonderfälle als Error zu deklarieren, indem eine Exception dafür geraised wird. So kann es wesentlich einfacher gemacht werden, die Fehlerstelle im Code schnell und genau zu ermitteln.
Beim Errorhandling geht es nicht nur darum, bekannte Fehler zu beheben. Vielmehr geht es um die Fähigkeit der Antizipation. Für eine Problemstellung gibt es viele verschiedene Lösungen, die je nach Programmiersprache und Stil der Programmierer*in unterschiedlich aussehen können. Welche Anforderungen das fertige Programm erfüllen soll, ist klar definiert. Es ist also notwendig, sich vorab gewisser Fehler, die auf dem Weg zur Zielstellung entstehen könnten, bewusst zu sein. Und noch wichtiger: man muss diese Fehler klar benennen und sich mit ihnen beschäftigen.

TypeError

Objekte können in gewissen Programmiersprachen einem sogenannten Type zugeordnet werden. Ein einfaches Beispiel sind Datentypen. Der Datentyp Integer speichert ganzzahlige Werte in einem endlichen Wertebereich. Der Datentyp String ist eine Zeichenkette, also eine Sequenz von Zeichen in endlicher Länge. So könnte die Ziffer 4 den Datentyp Integer besitzen und der Satz “Hello world!” den Datentyp String.
Auf Objekte können verschiedene Operationen angewendet werden. Operationen sind zum Beispiel einfache Rechenoperationen wie +, – oder *. Ein TypeError tritt dann auf, wenn versucht wird eine Operation auf ein Objekt eines gewissen Typs anzuwenden, auf den die Operation nicht angewendet werden kann. Das tritt zum Beispiel ein, wenn man versucht in der Programmiersprache Python einen String durch einen anderen String zu dividieren.
Betrachtet man das Objekt als reales Objekt, die Operation als Gebäudefunktion oder -nutzung und den Type als Gebäudetypologie, können ähnliche Situationen entstehen. Entspricht eine beabsichtigte Nutzung nicht der Gebäudetypologie, oder weicht diese von unserer Erwartung ab, nehmen wir das als TypeError wahr.

ReferenceError

Jedes Objekt, das wir besitzen, verbraucht Platz. Hat man nur begrenzten Platz zur Verfügung, werden nichtmehr verwendete Objekte entsorgt. So gehen auch moderne Programmiersprachen vor. Gibt es keine Referenz mehr auf ein Objekt, wir dieses entsorgt. Wird nun versucht, sich auf das Objekt zu beziehen, wird ein ReferenceError ausgegeben.
Natürlich gibt es auch andere Gründe, sich verschiedener Objekte zu entledigen. Schwierig wird es immer dann, wenn das entfernte Objekt in einem anderen Kontext erneut benötigt wird, oder man versucht, sich erneut darauf zu beziehen.
Objekte im öffentlichen Raum, Gebäude, oder auch Nutzungen und Praxen, existieren nie als isolierte Einheiten. Sie sind Teil eines Netzwerkes. Wird ein Knotenpunkt des Netzwerkes entfernt, kann eine neue Anknüpfung entstehen, oder die entstandenen offenen Verbindungen verlaufen als Sackgasse.
Je nach Qualität und Quantität der neuen Anknüpfungen kann der entstandene Knotenpunkt das urbane Netz verdichten, es stärken, oder es schwächen.
Bleiben Nutzungen ohne designierten Ort zurück, verlagern sie sich, oder lösen sich auf. Dies kann unvorhergesehene Auswirkungen auf andere Verbindungen des Netzwerkes nach sich ziehen.
Orte, die ohne Nutzung zurückbleiben, werden als Artefakte wahrgenommen. Sie können durch neue Nutzungen wieder ins Netzwerk eingebunden werden. Ein Beispiel dafür ist die Umnutzung alter Fabrik- oder Industriegebäude.
Auch Statuen oder Objekte die abgebaut, oder an einem neuen Ort wieder errichtet werden, können als ReferenceError wahrgenommen werden. Oft fehlt der Bezug zum ihnen ursprünglich angedachten Ort. Im Fall der Aphrodite Statue im Linzer Bauernbergpark wurde ein Objekt entfernt, dessen Umgebung – ein Pavillon und ein Sockel – blieben erhalten. Der leere Sockel löst eine Erwartungshaltung, aber auch eine Irritation durch das offensichtliche Fehlen eines Objektes – eine Art Phantomschmerz – aus. Dies wurde durch verschiedene Aktionen zur Aufarbeitung und die Platzierung einer Tafel mit Informationen zur Statue adressiert.