Obsługa błędów za pomocą albo -> Gdzie jest stos śledzenia?

Słyszałem od niektórych osób, że w Scali mamy tendencję (podobnie jak inne języki funkcyjne), aby nie przerywać przepływu sterowania. Zamiast tego, zgodnie z konwencją, zwracamy błąd w postaci EitherLeft.Obsługa błędów za pomocą albo -> Gdzie jest stos śledzenia?

Ale w jaki sposób uzyskujemy tracktrack z tego wyjątku? Na razie wracam po lewej stronie do zwykłej klasy przypadku Error z kodem, wiadomością i przyczyną (Error). Ale jeśli mam błąd, nie mogę pobrać stosu. Jeśli moja aplikacja stanie się skomplikowana, może być trudno znaleźć blok kodu, który zwrócił ten Error ... Przyczyna główna jest niezbędna.

Co zatem robimy w praktyce?

Jeżeli wrócę, zamiast zwyczaju Error, rodzaj java Exception lub Throwable w moim Left? Jaka jest najlepsza praktyka obsługi wyjątków Scala bez utraty ważnych informacji, takich jak stacktrace i przyczyna?

Źródło

2012-09-16 Sebastien Lorber

Tak samo jak w przypadku nadchodzącej Scala 2.10 [jest również Try] (http://blog.richdougherty.com/2012/06/error-handling-with-scalas-try.html) do obsługi błędów –

@ om nom-nom dzięki temu wydaje się naprawdę fajnie! –

Sugeruję użyciu Either[java.lang.Throwable, A] (gdzie Throwable nadal daje dostęp do śledzenia stosu), i (w ogóle), co niestandardowe typy błędów przedłużyć java.lang.Exception.

Jest to praktyka stosowana przez Dispatch 0.9, na przykład, gdzie Either[Throwable, A] jest wykorzystywany do reprezentowania obliczeń, które może zakończyć się niepowodzeniem, a niestandardowe typy błędów wyglądać następująco:

case class StatusCode(code: Int) 
    extends Exception("Unexpected response status: %d".format(code))

Scalaz 7 „s Validation.fromTryCatch(a: => T) zwraca również Validation[Throwable, T] , gdzie Validation jest mniej więcej równoważne Either.

Źródło

2012-09-16 19:57:46

Twierdzę, że chociaż istnieją przykłady wyłączających wyjątków w jednym, to jest to głupia rzecz do zrobienia w praktyce. Jeśli masz jakiś schemat kodowania błędów, to albo ma sens; w przeciwnym razie po prostu wyrzuć wyjątek, aby osoby znajdujące się wyżej w łańcuchu wywołania mogły je obsługiwać lub przekazywać. –

@rs_atl: Powiedzmy, że utknąłem z możliwością czegoś takiego jak 'NumberFormatException' przy próbie parsowania łańcucha na liczbę całkowitą, na przykład. Zarówno wyrzucanie wyjątku, jak i używanie niestandardowej klasy błędów lub opakowania, wydają mi się o wiele gorsze niż proste podejście "Albo [Throwable, Int]". –

@TravisBrown thanks. Czy dobrą praktyką jest zwrócenie lewej (Throwable) zamiast lewej (wyjątek)? Ponieważ i tak nie powinniśmy złapać Throwables. Może sprawić, że programista wykryje błąd OutOfMemory na przykład nie? –

Obsługa błędów za pomocą albo -> Gdzie jest stos śledzenia?

Odpowiedz

Powiązane problemy