"Unvorhergesehenes" in "Verarbeitbares" umwandeln:

Für alle erwartbaren Fälle sollten alle Komponenten des openWIM-Systems systematisch (re)agieren und die sich aus den Umständen und Anforderungen ableitbaren notwendigen "konstruktiven" Aktionen durchführen.

Aber auch das "Unerwartete" ist meist erwartbar, selbst wenn das exakte Ereignis im Einzelnen nicht immer vorhersehbar ist: Es ist praktisch unmöglich, für jede theoretisch denkbare Situation eine konkrete individuelle Vorsorge zu treffen, da sich beispielsweise das Umfeld einer Funktionalität unerwartet ändern kann oder benötigte Funktionalitäten ausfallen. Daher werden unter anderem Code-Bereiche des Systems in "try" & "catch"-Abschnitte eingefasst. Auch "default"-Zweige von "switch"-Statements oder "else"-Zweige in Abfragen können Orte für solcherart unerwarteter Ereignisse oder Situationen sein.

Die Behandlung unerwarteter Ereignisse sollte immer dann (und nur dann) geschehen, wenn das aufgetretene "unerwartete" Ereignis in eine "reguläre", konstruktive Aktion umgewandelt werden kann. Und sei es, dass dem Auftraggeber einer Funktionalität (per Message, Callback, etc.) mitgeteilt wird, dass ein Ausnahme-Ereignis stattgefunden hat. Sofern nützlich auch mit genaueren Angaben zu Details des unerwarteten Ereignisses und dem Umfeld bei seinem Eintreffen.

Unerwartetes notieren und Nutzer verständlich informieren:

Solche Ausnahme-Ereignisse sollten vom Abfang-Mechanismus (also in der catch-Mimik etc.) protokolliert werden, wenn Aktionen der Administration oder Entwicklung erfolgen sollten. Die Administration kann daraufhin beispielsweise den aktuellen Betrieb nachsteuern und die Entwicklung in zukünftigen Versionen des Systems neue "erwartbare Ereignisse" berücksichtigen.

Den aktuellen Nutzern (und meist auch der System-Administration) bringt eine direkte Mitteilung unerwarteter Ereignisse meist wenig. Daher werden diese Zielgruppen bei Bedarf auf dem Umweg über die Umwandlung in eine "verarbeitbare" Aktion informiert. Eine solche "verarbeitbare" Aktion kann beispielsweise die Behandlung eines Verbindungsabbruchs zwischen Client und Server bewirken, über den die Nutzer dementsprechend informiert werden, ohne dass sie dafür erfahren müssen, welcher hinterhältige Grund nun ganz genau das Problem ausgelöst hat.

Manchmal kann es sinnvoll sein, neben einem Logfile-Eintrag für die Entwickler auch einen Eintrag für die Administration zu erzeugen, falls administrative Maßnahmen aus dem unerwartetem Ereignis abgeleitet werden könnten. Dieses kann durchaus erst an nachgeordneter Stelle erfolgen und Zustandsdaten zur Auswirkung des aufgetretenen Problems enthalten.