Czy stosowanie wyjątków to zła praktyka w scala?

Question

Widziałem wielokrotnie fragmenty kodu scala za pomocą Opcji (dla prostych wartości) lub [Lista [Błąd], T] do obsługi błędów.

daje to miejsce na kod jak poniżej

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's 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) 
     ) 
     } 
    ) 
    } 
) 

który wytwarza kod nie tak piękny zagnieżdżania, zmusza do czynienia z awariami na każdym kroku, a także zmusza do mieć wszystkie funkcje zwracają Albo [ ...]

Więc chciałbym wiedzieć, czy

• stosowanie wyjątków jest zalecane w Scala (lub programowania funkcyjnego w ogóle)

• są jakieś niedogodności w korzystaniu z nich (dotyczące niezmienności lub kodu współbieżności)

• wyjątki są w jakiś sposób w sprzeczności z zasadami lub programowania funkcyjnego

• można myśleć o lepszym sposobem Kodeksu podany przykład

-

Można by uniknąć zagnieżdżania zamykając FUNCT jon natychmiast po wykryciu błędu za pomocą instrukcji return, ale użycie zwrotu również jest odradzane w scala ...

Answer 1

Następująca wersja wykorzystuje fakt, że prawy rzut Either jest monadą i jest dokładnie taki sam jak twój Kod:

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

i robi dużo lepszą pracę popisać zalety Either.

Bardziej ogólnie, reguły są takie same jak w Javie: używaj wyjątków w wyjątkowych sytuacjach. Może się okazać, że zmienisz swoją definicję wyjątkową trochę, gdy pracujesz w tym stylu - np. Nieprawidłowe dane wejściowe użytkownika nie są naprawdę wyjątkowe, przekroczenie limitu czasowego żądania sieciowego nie jest naprawdę wyjątkowe, itp.

Answer 2

jak OM-nom-nom powiedział, zadałem podobne pytanie: Throwing exceptions in Scala, what is the "official rule"

Ale to nie jedyny poprosiłem, które mogą Cię zainteresować, bo używany do kodowania z wieloma standardowy kod i wiele poziomów wcięć ze względu na dopasowanie wzoru itp ...

---

• Można sprawdzić te linki: Handling failures with Either -> Where is the stacktrace?

• Kind of związane obsługi błędów zbyt, które mogą Cię interesować: Method parameters validation in Scala, with for comprehension and monads W którym Travis Brown dał bardziej szczegółową odpowiedź, o używanie funktorów aplikacyjnych i Scalaza do szybkiego działania (pierwszy błąd blokuje proces) lub zbieranie wszystkich błędów z zestawu operacji To samo pytanie: Handling fail-fast failures when the return type is Option[Error]

• Możesz również sprawdzić ten link, który wykorzystuje parametry nazwy-użytkownika do wykonania sekwencji operacji. Może to być dobra alternatywa dla użycia właściwych projekcji w celu zrozumienia, ale nie można utworzyć wyników pośrednich :( Validation with a sequence of by-name parameters in Scala? Nie wiem, czy można go użyć z własnym przykładem kodu, ale nie sądzę, aby ta sprawa (zakładając swoją refreshApplicationToken jest wolne od działań niepożądanych i powrócić do nowo utworzonej instancji niezmienne użytkownika, zamiast mutacji symbolicznego zmiennej)

Answer 3

odpowiedź zmienia się pomiędzy tym, co jest idealna, co jest praktyczne. Najlepiej, unikać Wyjątkiem jest to, że praktycznie nie możesz bez nich żyć

Scala wydaje się faworyzować jedno-liniowce i wzdłuż tych linii v2.10 ma nową mona d Spróbuj:

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