使用Either處理故障 - >堆棧跟蹤在哪裏？

我聽說有些人在Scala中傾向於（像其他函數式語言一樣）不要打斷控制流程......而是按照慣例我們返回錯誤EitherLeft。使用Either處理故障 - >堆棧跟蹤在哪裏？

但是，我們如何從這個異常中得到散記？現在我回到左邊一個簡單的Error案例類與代碼，消息和原因（Error太）。但是，如果我有一個錯誤，我無法獲得堆棧跟蹤。如果我的應用程序變得複雜，則可能很難找到返回Error的代碼塊......根本原因很重要。

那麼我們在實踐中做什麼？

我應該返回，而不是自定義Error，在我的Left Java類型Exception或Throwable？ Scala異常處理的最佳實踐是什麼，而不會丟失重要信息，如堆棧跟蹤和原因？

就像一個說明，在即將到來的斯卡拉2.10 [也有嘗試]（http://blog.richdougherty.com/2012/06/error-handling-with-scalas-try.html）錯誤處理 –

@ om-nom-nom感謝這似乎非常好！ –

我建議使用Either[java.lang.Throwable, A]（其中Throwable仍然允許您訪問堆棧跟蹤），並且（通常）使您的自定義錯誤類型擴展爲java.lang.Exception。

這是通過Dispatch 0.9使用的做法，例如，其中Either[Throwable, A]用於表示可能出現故障的計算和定製的錯誤類型是這樣的：

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

Scalaz 7的Validation.fromTryCatch(a: => T)也返回一個Validation[Throwable, T] ，其中Validation大致相當於Either。

2012-09-16 19:57:46

我會爭辯說，儘管有一些封裝異常的例子，但在實踐中這是一件很愚蠢的事情。如果你有一些錯誤編碼方案，一個是有道理的;否則只是拋出異常，以便呼叫鏈中較高的那個可以處理或傳遞它。 –

@rs_atl：例如，當我嘗試將一個字符串解析爲一個整數時，我遇到了類似'NumberFormatException'的可能性。拋出異常並使用自定義錯誤類或包裝對我來說似乎比簡單的'Either [Throwable，Int]'方法更可怕。 –

@TravisBrown謝謝。返回Left（Throwable）而不是Left（Exception）是否是一種好習慣？因爲我們不應該捕捉Throwables。它可能會導致開發人員發現一個OutOfMemory錯誤，例如沒有？ –

回答