Hallo zusammen, in diesem Video sprechen wir über mögliche Fehler bei Fernaufrufen und

wie man sie mit Hilfe von Fernaufrufsemantiken fehlertolerant machen kann.

Bei Fernaufrufen muss man zuallererst zwei Arten unterschiedliche Fehler unterscheiden.

Ein Fehler kann ganz klassisch in der Anwendung gegründet sein und wäre bei einem lokalen

Aufruf der Methode ebenfalls aufgetreten.

Das können einfache Programmierfehler sein wie vergessene Ausnahmeprobleme, aber auch

gewollte Fehler, um zum Beispiel wie bei unserer VORCTION EXCEPTION den Nutzer auf eine fehlerhafte

Eingabe aufmerksam zu machen.

Die Erkenntnis bei solchen Fehlern ist dabei, dass es sich um ein reguläres Verhalten der

Methode an sich handelt.

Das Fernhoffsystem muss daher nur generell unterstützen, dass diese Fehler an den Nutzer

propagiert werden.

Hier wieder das Stichwort Transparenz.

Wenn diese Weiterleitung gegeben ist, kann das Fernhoffsystem diese Fehler aber ansonsten

einfach ignorieren.

Daneben gibt es die zweite Art von Fehlern.

Solche, die durch den Fernhoff selbst ausgelöst werden, im lokalen Fall also nicht aufgetreten

werden.

Da bei einem Fernhoff der Methodenaufruf in einer anderen Fehlerdomäne stattfindet,

wie die von der Methode selbst, kann der Server abstürzen oder auch durch starke Überlasts

einfach sehr lange brauchen, um eine Methode zu bearbeiten.

Eine weitere Fehlerquelle ist die Netzwerkkommunikation dazwischen.

Je nach den Garantien, die uns hier gegeben werden, können Nachrichten verloren gehen,

korruptiert werden und fehlerhaft ankommen oder sich auch bei der Übertragung gegenseitig

überholen und in veränderter Reihenfolge ankommen.

Zudem ist es generell immer möglich, dass die Netzwerkverbindung an sich unterbrochen

wird oder auch hier wieder durch eine starke Last sehr verlangsamt ist.

Da solche Fehler allein durch die Tatsache Fernhoffruf überhaupt erst möglich sind,

bedingt hier die Transparenz, dass sich das Fernhoffrufsystem wenn möglich selbst darum

kümmert und diese Fehler intern behandelt.

Nur wenn es tatsächlich nicht möglich ist, den Fehler zu beheben, wenn zum Beispiel die

Netzwerkverbindung langfristig getrennt ist, dann wird dies dem Aufrufer signalisiert.

Um unsere möglichen Fehler-Situationen nochmal zusammenfassen und zu vergleichen.

Bei Rechner- und Hardware-Fehlern haben wir bei einem lokalen Aufruf den Fall, dass Aufrufer

und Methode gleich betroffen sind und im Fehlerfall auch beide abstürzen oder sich sonst wie

anders verhalten.

Im Gegensatz dazu sind die beiden bei Fernhoffrufen unabhängig voneinander und nur eine Seite

kann von einem Fehler betroffen sein, während die andere sich fragt, wieso Dinge plötzlich

nicht weitergehen.

Ähnliches gilt für den Fehler in der Kommunikation zwischen Aufrufer- und Methodenausführung.

Im lokalen Fall gibt es normalerweise keine Netzwerkkommunikation dazwischen.

Und selbst wenn wir unterschiedliche Prozesse auf demselben Rechner haben, kümmert sich

das Betriebssystem darum und es wird nicht unnötig übers Netzwerk geleitet.

Diese Art der Fehler ist im lokalen Fall also eigentlich nicht relevant.

Bei einem Fernhoffruf haben wir jetzt aber ein Netzwerk dazwischen.

Dieses kann kaputt gehen und temporäre oder dauerhafte Ausfälle und Fehler sind möglich.

Einige Fehler, wie zum Beispiel den Verlust von wenigen Nachrichten, kann das Fernhoffssystem

durch Gegenmaßnahmen tolerieren.

Aber wenn zum Beispiel die Verbindung zwischen Server und Client dauerhaft getrennt ist,

Stichwort das Netzwerkkabel ist kaputt, dann kann auch das beste Fernhoffssystem dagegen