Schlechte Idee, Ausnahmen mit RMI zu verketten?

Ist es eine schlechte Idee, beim Auslösen von RemoteExceptions die Ausnahmekette zu verwenden? Wir haben einen RMI-Server, der so etwas macht:

public Object doSomething() throws RemoteException
{
    try
    {
        return getData();
    }
    catch (CustomException ex)
    {
        throw new RemoteException(ex);
    }
}

Ich erhalte die UnmarshallException, die durch eine ClassNotFoundException in meinem Client verursacht wurde. Auf der positiven Seite stellt sich heraus, dass CustomException selbst exportiert wird. Leider wird eine weitere Ausnahme tief in diesem Typ NICHT exportiert. Hier kommt die ClassNotFoundException ins Spiel. Ich denke, die Hierarchie sieht ungefähr so aus:

RemoteException -> CustomException -> SQLException -> NotExportedException

as Problem, das ich sehe, ist, dass wir, obwohl wir garantieren können, dass CustomException exportiert wird, nicht garantieren können, dass es Ausnahmen auf einer niedrigeren Ebene gib

Ich neige dazu, NIEMALS Ausnahmeketten mit RemoteExceptions zu verwenden. Stattdessen sollte ich wahrscheinlich den Stack-Trace auf der Serverseite protokollieren und eine einfache Vanilla-RemoteException auslösen, an die keine "Ursachen" -Ausnahme gekettet ist. Hat sich schon jemand mit dieser Situation befasst?

Antworten auf die Frage(4)

Ihre Antwort auf die Frage