Как вы передаете сообщения/ошибки уровня обслуживания на более высокие уровни с помощью MVP?

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

Не ловите исключения

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

Планирование простой иерархии исключений

Если вы собираетесь использовать исключения таким образом, вы должны создать иерархию исключений для своих собственных классов исключений. В минимуме создайте класс ServiceLayerException и бросьте один из них в свой метод обслуживания, когда возникает проблема. Затем, если вам нужно создать исключение, которое должно/могло бы быть обработано презентатором по-другому, вы можете создать определенный подкласс ServiceLayerException: скажем, AccountAlreadyExistsException.

Затем ваш ведущий может сделать следующее

try {
  // call service etc.
  // handle success to view
} 
catch (AccountAlreadyExistsException) {
  // set the message and some other unique data in the view
}
catch (ServiceLayerException) {
  // set the message in the view
}
// system exceptions, and unrecoverable exceptions are allowed to bubble 
// up the call stack so a general error can be shown to the user, rather 
// than showing the form again.

Использование наследования в ваших собственных классах исключений означает, что вам не нужно перехватывать многопильные исключения в вашем презентаторе-вы можете, если есть необходимость, - и вы не можете случайно перехватить исключения, которые не можете обработать. Если ваш ведущий уже находится в верхней части стека вызовов, добавьте блок catch( Exception ) для обработки системных ошибок с другим представлением.

Я всегда стараюсь думать о своем сервисном слое как о отдельной распространяемой библиотеке и выбрасываю такое конкретное исключение, какое имеет смысл. Затем реализация presenter/controller/remote-service решает, нужно ли ей беспокоиться о конкретных деталях или просто рассматривать проблемы как общую ошибку.

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

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

public static class Try {
    public static List<string> This( Action action ) {
      var errors = new List<string>();
      try {
        action();
      }
      catch ( SpecificException e ) {
        errors.Add( "Something went 'orribly wrong" );
      }
      catch ( ... )
      // ...
     return errors;
    }
}

Затем при вызове вашей службы просто сделайте следующее

var errors = Try.This( () => {
  // call your service here
  tasks.CreateMember( ... );
} );

Тогда в ошибках пусто, вы хорошо идете.

Вы можете пойти дальше и расширить его с помощью обработчиков исключений custome, которые обрабатывают необычные исключения.

В ответ на последующий вопрос:

Что касается создания исключений, которые становятся утомительными, вы как бы привыкаете к этому. Использование хорошего генератора кода или шаблона может создать класс исключений с минимальным ручным редактированием в течение примерно 5 или 10 секунд.

Однако во многих реальных приложениях обработка ошибок может быть 70% из работы, так что это все просто часть игры на самом деле.

Как предполагает tgmdbm, в приложениях MVC/MVP я позволяю всем моим необработанным исключениям всплывать наверх и попадать в диспетчер, который делегирует ExceptionHandler. Я настроил его так, что он использует ExceptionResolver, который смотрит в файле конфигурации, чтобы выбрать подходящее представление для отображения пользователя. Библиотека Java Spring MVC делает это очень хорошо. Вот фрагмент из конфигурационного файла для Spring MVC's Exception resolver - его для Java/Spring, но вы получите идею.

Это занимает огромное количество обработки исключений из ваших докладчиков / контроллеров в целом.

<bean id="exceptionResolver"
      class="org.springframework.web.servlet.handler.SimpleMappingExceptionResolver">

  <property name="exceptionMappings">
    <props>
      <prop key="UserNotFoundException">
        rescues/UserNotFound
      </prop>
      <prop key="HibernateJdbcException">
        rescues/databaseProblem
      </prop>
      <prop key="java.net.ConnectException">
        rescues/networkTimeout
      </prop>
      <prop key="ValidationException">
        rescues/validationError
      </prop>
      <prop key="EnvironmentNotConfiguredException">
        rescues/environmentNotConfigured
      </prop>
      <prop key="MessageRejectedPleaseRetryException">
        rescues/messageRejected
      </prop>
    </props>
  </property>
  <property name="defaultErrorView" value="rescues/general" />
</bean>