Исключения из-за удаленных методов

Question

Каковы лучшие практики для исключений по удаленным методам?

Я уверен, что вам нужно обработать все исключения на уровне реализации удаленного метода, потому что вы должны регистрировать его на стороне сервера. Но что делать потом?

Стоит ли обернуть исключение в RemoteException (java) и выбросить его клиенту? Это будет означать, что клиент должен будет импортировать все исключения, которые могут быть выброшены. Будет ли лучше создать новое пользовательское исключение с меньшим количеством деталей? Потому что клиенту не нужно знать все детали того, что пошло не так. Что вы должны войти в клиент? Я даже слышал об использовании кодов возврата (может быть, для эффективности?), Чтобы сообщить звонящему о том, что произошло.

Важно помнить, что клиент должен быть проинформирован о том, что пошло не так. Общий ответ «Что-то не получилось» или вообще никакого уведомления недопустим. А что насчет исключений во время выполнения (без проверки)?

Answer 1

Похоже, вы хотите иметь возможность различать, был ли сбой вызван сбоем системы (например, не работает служба или компьютер) или сбоем бизнес-логики (например, пользователь не существует).

Я бы порекомендовал обернуть все системные исключения из вызова RMI вашим собственным пользовательским исключением. Вы по-прежнему можете сохранить информацию в исключении, передав ее в свое собственное исключение в качестве причины (это возможно в Java, но не уверен в других языках). Таким образом, клиенту нужно только знать, как обрабатывать одно исключение в случае сбоя системы. Проверено ли это пользовательское исключение или время выполнения (возможно, зависит от стандартов вашего проекта). Я определенно буду регистрировать этот тип ошибки.

Ошибки бизнес-типа могут быть представлены либо как отдельное исключение, либо как некоторый тип объекта ответа по умолчанию (или ноль). Я попытался бы восстановить (то есть предпринять некоторые альтернативные действия) от этого типа ошибки и регистрировать, только если восстановление не удается.

Answer 2

Вот что я сделал. Каждая реализация удаленного метода перехватывает все исключения на стороне сервера и регистрирует их. Затем они помещаются в пользовательское исключение, которое будет содержать описание проблемы. Это описание должно быть полезно для клиента , поэтому оно не будет содержать все детали перехваченного исключения, поскольку клиенту они не нужны. Они уже были зарегистрированы на стороне сервера. Теперь на клиенте эти исключения могут быть обработаны по желанию пользователя.

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

Answer 3

Я всегда регистрирую исключение в моем приложении (на стороне сервера, как определено в вашем вопросе).

Я бы тогда бросил исключение, чтобы его поймал клиент. Если вызывающая сторона может предпринять корректирующие действия для предотвращения исключения, тогда я гарантирую, что исключение содержало эту информацию (например, DateTime argName must not be in the past). Если ошибка была вызвана каким-либо отключением сторонней системы, я мог бы передать эту информацию вызывающему абоненту.

Если, однако, исключение было по существу вызвано ошибкой в ​​моей системе, то я бы структурировал свою обработку исключений так, чтобы использовалось неинформативное сообщение об исключении (например, General failure).

Answer 4

В прошлых проектах мы ловили все исключения уровня обслуживания (уровня) в самой верхней части уровня, передавая специфические коды приложений / информацию об ошибках в пользовательский интерфейс через DTO / VO. Это простой подход в том, что существует установленная схема обработки всех ошибок в одном и том же месте для каждой службы, а не разбросанная по слоям службы и пользовательского интерфейса.

Тогда все, что нужно сделать пользовательскому интерфейсу, это проверить DTO / VO на наличие флага (hasError?) И отобразить сообщение (я) об ошибках; ему не нужно ни знать, ни заботиться о том, что именно являлось исключением.