Angeben von Fehlern nach Ausnahmen

Bei herkömmlichen C-Programmierern werden Fehler häufig über Rückgabewerte oder einen speziellen out-Parameter zurückgegeben, [ ] der den Fehlercode zurückgibt. Dies führt zu Schnittstellen, die wie folgt implementiert werden:

long sample(...)
{
    ...
    p = new Cbar(...);
    if (p == NULL)
    {
        // cleanup
        ...
        return ERROR_OUTOFMEMORY;
    }
}

Das Problem bei diesem Ansatz besteht darin, dass RPC-Rückgabewerte einfach lange ganze Zahlen sind. Sie haben keine besondere Bedeutung als Fehler (beachten Sie, dass der _ Fehlerstatus _ keine spezielle Semantik auf serverseitiger Seite aufweist), was wichtige Auswirkungen hat.

Erstens wird RPC nicht benachrichtigt, dass der Vorgang fehlgeschlagen ist. Es wird versucht, alle [ ein-, ausgehenden ] und [ ausgehenden Argumente zu ] entmarshalen. Die Fehlersemantik von Kontexthandles unterscheidet sich ebenfalls. Das an den Client zurückgegebene Paket ist im Wesentlichen ein Erfolgspaket, wobei der Fehlercode tief in das Paket eingedrungen ist. Dies bedeutet auch, dass RPC keine erweiterten Fehlerinformationen verwendet, sodass Clientsoftware häufig nicht erkennen kann, wo der Aufruf fehlgeschlagen ist.

Das Angeben von Fehlern in RPC-Serverroutinen durch Auslösen von SEH-Ausnahmen (Structured Exception Handling, strukturierte Ausnahmebehandlung) (nicht C++) ist ein viel besserer Ansatz. Wenn eine SEH-Ausnahme ausgelöst wird, wird die Steuerung direkt an die RPC-Laufzeit geleitet. Ein Fehler tritt manchmal tief in einer Routine auf, die nicht ordnungsgemäß bereinigt werden kann, und muss dem Aufrufer einen Fehler anzeigen. Die Routine sollte einen Fehler an den Aufrufer zurückgeben, der wiederum einen Fehler an den Aufrufer zurückgeben kann usw. Die letzte Serverroutine auf dem Stapel sollte jedoch eine Ausnahme auslösen, bevor sie zu RPC zurückkehrt, um RPC anzuzeigen, dass ein Fehler aufgetreten ist.

Ausnahmebehandlung