遠程方法的例外情況的最佳做法是什麼？遠程方法的例外情況
我確定您需要處理遠程方法實現級別的所有異常，因爲您需要將其記錄在服務器端。但之後你應該做什麼？
如果你將異常封裝在一個RemoteException（java）中並把它拋給客戶端？這意味着客戶端必須導入可能拋出的所有異常。用更少的細節拋出新的自定義異常會更好嗎？因爲客戶不需要知道錯誤的全部細節。你應該登錄客戶端？我甚至聽說過使用返回代碼（爲了提高效率？）來告訴調用者發生了什麼事。
重要的是要記住，客戶端必須被告知出了什麼問題。 「一些失敗」或根本沒有通知的通用答案是不可接受的。那麼運行時（未檢查）異常呢？
這就是我所做的。每個遠程方法實現都捕獲服務器端的所有異常並記錄它們。然後它們被封裝在自定義異常中，其中將包含問題的描述。此說明必須對客戶端有用，因此它不會包含捕獲的異常的所有細節，因爲客戶端不需要它們。他們已經登錄到服務器端。現在，在客戶端上，這些異常可以按照用戶的意願來處理。
爲什麼我選擇使用異常而不是返回代碼是因爲返回代碼的一個非常重要的缺點：你不能在沒有一些努力的情況下將它們扔到更高的層次。這意味着你必須在通話之後檢查錯誤並在那裏處理。但這可能不是我想要的。
在過去的項目中，我們會捕獲層頂部的所有服務層（層）異常，並通過DTO的/ VO將應用程序特定的錯誤代碼/信息傳遞給UI。這是一種簡單的方法，因爲在每個服務的同一個地方都有一個確定的錯誤處理模式，而不是散佈在服務和UI層上。
然後所有的用戶界面必須做的是檢查DTO/VO的標誌（hasError？）並顯示錯誤信息，它不必知道也不在乎實際的異常。
您似乎希望能夠區分故障是由於系統故障（例如服務或機器故障）還是業務邏輯故障（例如，用戶不存在）造成的。
我建議使用您自己的自定義異常來包裝來自RMI調用的所有系統異常。您仍然可以通過將異常中的信息傳遞給您的自定義異常（原因可能在Java中，不確定其他語言）來維護異常中的信息。這樣，客戶端只需要知道如何處理導致系統故障的一個例外。是否檢查此自定義異常或運行時是否有爭議（可能取決於您的項目標準）。我肯定會記錄這種類型的失敗。
業務類型失敗可以表示爲單獨的異常或某種類型的默認（或空）響應對象。我會嘗試從這種類型的故障中恢復（即採取一些替代措施），並且只有在恢復失敗時才進行日誌記錄。
我總是在我的應用程序內（在您的問題中定義的服務器端）記錄異常。
然後我會拋出一個異常，被客戶端抓住。如果調用者可以採取糾正措施來防止異常，那麼我會確保該例外包含此信息（例如DateTime argName must not be in the past）。如果錯誤是由第三方系統的某些中斷引起的，那麼我可能會將這些信息通過調用棧傳遞給調用者。
但是，如果這個異常實質上是由我係統中的一個錯誤引起的，那麼我將構造我的異常處理，以便使用非信息異常消息（例如General failure）。