2015-04-22 7 views
2

Я создаю услуги в Scala, как и в Java:Должен ли я использовать Try как возвращаемый тип в сервисах Scala?

trait PersonService { 
    def getById(id: Long): Person 
    def getAll: Iterable[Person] 
} 

, а также я соответствующие реализации данной услуги.

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

У меня есть вопрос: следует ли мне возвращать тип методов обслуживания с помощью Try?

I.e. следует ли использовать следующую декларацию:

trait PersonService { 
    def getById(id: Long): Try[Person] 
    def getAll: Try[Iterable[Person]] 
} 
+0

Да. Или «Будущее». –

ответ

4

Это зависит от того, является ли ошибка, вызванная службой, полезной для потребителя. То есть должны ли они знать о различных сбоях БД и, возможно, повторить попытку? Или вы сопоставляете исключения с потребительским значимым экземпляром? В обоих случаях я использовал бы Try[Person]

Если все, что вы закончите, регистрирует ошибку, и вы просто пытаетесь избежать этого, я бы рекомендовал войти в систему PersonService и вернуть Option[Persons].

В качестве альтернативы, если вы хотите сообщить некоторую информацию, чтобы отличить отказ от пустой, что не поднимается до уровня исключения, рассмотреть возможность использования Either[FailureReason,Person]

1

У вас есть 4 стандартных варианта:

  1. Future: Это может быть самым идиоматичным и гибким, позволяя потребителю более легко использовать услугу асинхронно и справляться с ошибками (путем сопоставления с Failure).

  2. Try: A Try сигнализирует потребителю, что операции могут потерпеть неудачу и что они должны быть готовы иметь дело с его исключениями.

  3. Either: Вы можете использовать Either подобно Try здесь, но с более настраиваемой информацией об ошибках (например, Either[ErrorType, ReturnType]).

  4. Option: Самый простой вариант здесь Option, в результате чего вы игнорируете причину ошибки и возвращать только Some, если операция прошла успешно.

+1

Учитывая взаимодействие с («медленным») уровнем БД, «Будущее» охватывает все базы. – millhouse

+1

Только если уровень БД имеет асинхронный шаблон доступа. В противном случае упаковка блокирующего ответа чего-то типа JDBC в будущем просто связывает другой поток –