Является ли использование исключений плохой практикой в scala?

Я видел много раз фрагменты кода scala, используя Option (для простых значений) или Либо [List [Error], T] для обработки ошибок.

это дает место для кода вроде этого

def createApplicationToken(accessToken: AccessToken): Either[List[Error], ApplicationToken] = {

// go to social info provider and fetch information
retrieveProviderInfo(accessToken).fold(
  errors  => Left(errors),
  info    => {
    // try to find user using the info from the provider
    // if it not there, create user
    User.findOrCreateFromProviderInfo(info).fold(
      errors  => Left(errors),
      user    => {
        // try to create a fresh token and save it to the user
        user.refreshApplicationToken.fold(
          errors  => Left(errors),
          user    => Right(user.token)
        )
      }
    )
  }
)

Что создает не очень приятное вложение кода, заставляет вас справляться с ошибками на каждом шаге, а также заставляет вас возвращать все ваши функции Aither [...]

Итак, я хотел бы знать, если

использование исключений не рекомендуется в scala (или вообще функциональном программировании)
есть какие-либо недостатки в их использовании (относительно неизменяемости или кода concurrency)
исключения как-то противоречат принципам или функциональному программированию
вы можете придумать лучший способ кодирования данного примера

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

Ответ 1

В следующей версии используется тот факт, что правая проекция Either является монадой и в точности эквивалентна вашему коду:

def createApplicationToken(accessToken: AccessToken) = for {
   info <- retrieveProviderInfo(accessToken).right
   user <- User.findOrCreateFromProviderInfo(info).right
   refr <- user.refreshApplicationToken.right
} yield refr.token

И гораздо лучше продемонстрировать преимущества Either.

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

Ответ 2

Как сказал om-nom-nom, я задал аналогичный вопрос: Выбрасывание исключений в Scala, что такое "официальное правило"

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

Вы можете проверить эти ссылки: Обработка сбоев с помощью Either → Где находится stacktrace?
Также можно относиться к обработке ошибок, которые могут вас заинтересовать: Проверка параметров метода в Scala, для понимания и монад В котором Трэвис Браун дал более подробный ответ об использовании аппликативных функторов и Scalaz для выполнения отказов (первая ошибка блокирует процесс) или собирает все ошибки набора операций Тот же вопрос: Обработка отказоустойчивых сбоев, когда тип возврата - опция [Ошибка]
И вы можете проверить эту ссылку, которая использует параметры by-name, выполнить последовательность операций. Это может быть хорошей альтернативой использованию правильных проекций для понимания, но вы не можете создавать промежуточные результаты:( Проверка с последовательностью параметров имени в Scala? Я не знаю, может ли он использоваться с вашим примером кода, но я не думаю, что в этом случае (предполагая, что ваш refreshApplicationToken свободен от побочных эффектов и возвращает вновь созданный неизменяемый пользовательский экземпляр вместо изменения переменной токена)

Ответ 3

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

Scala кажется предпочтительным для однострочных линий, а вдоль этих строк v2.10 имеет новую монаду Try:

import scala.util.Try

def percentCompleted( total:Int, done:Int ): Int = Try (done * 100 / total) getOrElse 100

percentCompleted( 0, 10 )    // Catches divide-by-zero and returns 100% instead