Плохая идея перехватывать исключения с RMI?

Question

Неплохая идея использовать цепочку исключений при бросании RemoteExceptions? У нас есть сервер RMI, что делает что-то вроде этого:

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

я получаю UnmarshallException вызванный ClassNotFoundException в моем клиенте. С положительной стороны выясняется, что сам CustomException экспортируется. . К сожалению, другое исключение глубоко внутри этого парня не экспортируется, который где ClassNotFoundException приходит, я думаю, что иерархия что-то вроде этого:

RemoteException -> CustomException -> SQLException -> NotExportedException

Проблема I см. то, что, хотя мы можем гарантировать, что CustomException будет экспортироваться, мы не можем гарантировать, что будут исключения на более низком уровне.

Я склоняюсь к НИКОГДА, используя исключение цепочки с RemoteExceptions из-за этого. Вместо этого, я думаю, я должен, вероятно, зарегистрировать трассировку стека на стороне сервера и выбросить простое, vanilla RemoteException без исключения «причины», прикованное к нему. Кто-нибудь раньше занимался этой ситуацией?

Answer 1

Вместо оберточной CustomException в RemoteException, вы можете изменить свой удаленный интерфейс, как это:

interface Foo extends Remote { 

    Object doSomething() throws CustomException, RemoteException; 

} 

Принцип здесь является то, что только во время выполнения RMI должно быть повышение RemoteExceptions; они сигнализируют о некотором сбое в удалении, а не в логике приложения. Фактически, конкретным реализациям даже не нужно объявлять RemoteException.

Но это не относится к случаю, когда ваша служба перехватывает исключение из какой-либо сторонней библиотеки, но не хочет раскрывать это в предложении throws.

public Object doSomething() throws CustomException { 
    try { 
    return theirSvc.getData(); 
    } catch (ThirdPartyException ex) { 
    throw new CustomException("Failed to obtain requested data."); 
    // or: throw new CustomException("Failed to obtain requested data.", ex) ? 
    } 
} 

В этом случае я рекомендую вам не создать «дырявую абстракцию», где зависимость будет создана в клиенте, который бы в противном случае иметь не нужно знать о том, что библиотеках третьей стороны.

Как правило, регистрация и бросание - это плохая практика, потому что одна и та же ошибка регистрируется повторно. Но в этом случае я считаю, что это оправдано, поскольку брошенное исключение переносится клиенту; может быть полезно зарегистрировать его как на клиенте, так и на сервере. Таким образом, блок улов заканчивает тем, как это:

catch (ThirdPartyException ex) { 
    String message = "Failed to obtain requested data."; 
    log.error(message, ex); 
    throw new CustomException(message); 
} 

Таким образом, зависимость ThirdPartyException ограничивается сервером, журналы сервера содержат соответствующую информацию от конкретной реализации, и ошибка правильно сообщается клиенту.

Answer 2

Мы фиксируем сообщение + целую трассировку стека из исключения источника и передаем это как содержимое удаленного исключения. Таким образом, вы получаете все детали стека, но вам не нужно беспокоиться о том, что любой из внутренних исключений не является сериализуемым.

Вы никогда не знаете, что другие объекты могут быть в какой-либо другой третьей стороной