| |
Zugrif auf das Netzwerk nichts Ungewöhnliches. Ein anderes Beispiel wäre der Netzwerkfehler
“no route to host”, dem wohl kaum ein Fehler auf dem lokalen Rechner entspricht.
Will man auf alle Fehler reagieren, die beim Ruf einer Prozedur auftreten können, was in
einigen kritischen Programmen durchaus notwendig sein kann und auch für weniger kritische
empfehlenswert ist, wird dies durch die Zugrifstransparenz erschwert. Konnte man nämlich
vorher vorab eingrenzen, dass der Fehler lokal aufgetreten ist, weil man z.B. selbst die auf-
gerufene Prozedur geschrieben hat, so muss man nun bei Prozeduren, von denen man nur
die Signatur kennt, sowohl für lokale Fehler als auch für Netzwerkfehler Behandlungsroutinen
definieren, weil man nicht weiß, ob sie lokal oder entfernt ausgeführt werden bzw. sich das
sogar von Ruf zu Ruf ändern kann2.
2.3.2 Zugrifstransparenz und Fehlertransparenz
Diese Problematik der Zugrifstransparenz führt zu einer weiteren, der Fehlertransparenz und
der Diskussion, welches Maß an Fehlertransparenz das richtige ist. Führt man nur einen
einzigen zusätzlichen Fehler “Netzwerkfehler” ein, um den Unterschied zum Ruf einer lokalen
Prozedur gering zu halten, gibt es unter anderem folgende Probleme:
Angenommen, die Implementierung der Methode begegnet dem Umstand, dass ein be-
stimmter Rechner nicht erreichbar ist; soll “Netzwerkfehler” sofort, nach einer bestimm-
ten maximalen Zahl von Wiederholungsversuchen oder nach einer maximalen Dauer
einer beliebigen Anzahl von Wiederholungsversuchen gemeldet werden?
Angenommen die Implementierung der Methode konnte alle Daten, die zur Ausführung
nötig sind, an einen anderen Rechner senden, erhält aber keine Antwort darauf; soll
dies sofort, nach einer bestimmten maximalen Zahl von Wiederholungsversuchen, etc.
gemeldet werden und soll der Vorgang als Fehler oder als Erfolg gewertet werden?
Um echte Fehlertransparenz zu erreichen, könnte man sogar auf die Idee kommen, Netz-
werkfehler überhaupt nicht zu melden bzw. so wie schwere Hardwarefehler zu handhaben.
Im Falle schwerer Hardwarefehler, die vom Betriebsystem erkannt werden, hält dieses typi-
scherweise den Rechner an. Die Idee ist, dass der Besitzer des Rechners dann die betrofene
Hardware-Komponente untersucht, den Fehler unter Umständen durch Austausch der Kom-
ponente behebt und dann wieder das Betriebssystem startet. Im Fall von Netzwerkfehlern
könnte man entsprechend den Prozess vorübergehend stoppen und dem Besitzer bzw. Nutzer
oder Administrator des Rechners den Fehler mitteilen. Ein C-Programm für Unix-Systeme,
welches dies realisiert, könnte folgenden Programmtext enthalten:
retry:
if (connect(socket, name, namelen) == Netzwerkfehler) {
notify_administrator();
sigsend(P_PID, getpid(), SIGSTOP);
goto retry;
}
2Objektmigration!
19
|  |
|
| |
|
|
