2009-07-15 24 views
4

在我現在所在的公司,代碼中有很多地方引發OurCompanyRuntimeException(其中OurCompany是公司的實際名稱)。據我所知,這個異常被描述爲「我們在這家公司編寫的代碼拋出的運行時異常。」Java中的OurCompanyRuntimeException類型有什麼意義?

我有點新的爪哇,但我認爲異常類型被認爲反映什麼出了問題,不是其代碼拋出異常。例如,IllegalArgumentException意味着某人通過了某個非法的參數。如果在Sun編寫的代碼中傳遞了非法參數,然後出現IBMIllegalArgumentException,那麼您將不會有SunIllegalArgumentException - 這會是愚蠢且毫無意義的,對嗎?如果你想知道拋出異常的位置,你可以看看堆棧跟蹤。我知道想擴展RuntimeException(所以你沒有儘可能多的try/catches或「throws」es),但爲什麼不制定解釋發生的事情的子類,而不是發生在公司的代碼中?

有沒有人曾經使用過OurCompanyRuntimeException想法,或者有想法說明他們爲什麼會這樣做?

+0

我以前見過。由於它更像是一種其他的約定,所以它在應用程序中並未廣泛使用,因此對於newcommer而言是無用的和誤導的。 – 2009-07-15 09:42:12

回答

6

聽起來像通常定製的代碼廢話,你發現在內部代碼基地給我。我懷疑,如果你問到會有一些法令,OurCompanyRuntimeException是基於一些沒有人敢問的高級人物的錯誤邏輯而使用的,並且很久以後就開始了 - monkeys, bananas and hose-pipes的故事令人浮想聯翩。

我同意你的意見,異常的名稱應該表明發生了錯誤。

2

幫助讀取堆棧跟蹤時,這是肯定的。即當通過很多「由...引發」的線掃描時,它有助於看到它發生在你所拋出的東西上,而不是某個容器的內部。

還允許您執行自定義操作作爲throwable的一部分 - 例如,寫在某處的特殊日誌等。

1

這是一個糟糕的概念。例外情況應該特定於用例。

好吧,如果公司確實產生了很多錯誤的代碼/產品,他們可能會使用這種類型的例外,因爲廣告的;)

+0

+1對於通過日誌語句進行廣告的錯誤想法。 – 2009-07-15 16:18:00

2

是的,我遇到了,但是它沒有意義的,我無論是。我的猜測是,這些公司在採用Java之後很早就寫出了這些例外情況,卻沒有正確理解異常拋出和處理的真實工作方式(就像Nick已經說過的......高級程序員沒有人敢質疑)。 如果公司認爲需要創建自己的異常類(例如,針對公司特定的日誌記錄porpuses),則不應該直接拋出此異常(使其變得抽象)。我會派生具體的問題來描述異常,或者只是遵循Spring框架的異常處理/拋出的想法。

1

貴公司可能會將代碼添加到已存在的項目中,例如開源代碼庫,並且可能只是添加了很少的代碼。因此,爲了追蹤公司開發人員發生的錯誤,他們認爲他們將擁有自己的異常類來區分之前發生的錯誤和擴展造成的錯誤。這樣,他們只能關注由公司開發人員引起的問題,並且可能要求原始源代碼維護人員修復其他問題。隨着時間的推移,當人們通過內部開發開發出足夠大的代碼庫時,您可能會添加更多異常並刪除CompanynameRuntimeException altogother。此外,他們可以更輕鬆地利用開發人員的專業知識水平,讓他們把所有錯誤視爲一種錯誤,而不是更加可疑地查看公司開發人員造成的錯誤。

1

將此作爲特定例外的基類是非常有意義的。你拋出一個特定的異常並捕獲基類。

此外,它可能允許攜帶一個原因(REAL異常)加上附加信息。這對於爲日誌記錄創建診斷輸出可能非常方便。

+0

我檢查了層次結構,而OurCompanyRuntimeException有20多個子類,如DeleteException,OurCompanySQLException和DatabaseTransactionException。所以這可能是這是最初的意圖,他們只是沒有想到通過使基類抽象來強制執行它。我見過的大多數OurCompanyRuntimeExceptions確實帶來了一個原因,這確實使日誌消息更有幫助。 – MatrixFrog 2009-07-15 16:32:07

+0

與你的老闆交談。這可能是一個下午練習,使基類抽象並修復所有產生的編譯錯誤。 – 2009-07-15 17:46:06

1

看起來非常愚蠢,日誌記錄輸出或堆棧跟蹤會告訴你誰是違規類,所以解釋不會洗。也似乎很危險,好像人們被鼓勵拋出OurCompanyRuntimeException,他們拋出RuntimeExceptions,這不會強制調用者處理它們,並可以取消你的應用程序。

我同意你的意見,例外應該反映出背後的原因。我已經看到一個自定義異常作爲層次結構的根,儘管它可能應該是抽象的,所以你需要創建一個特定的擴展來使用它,它絕對不應該是一個RuntimeException。

0

像你描述更具體的異常情況繼承從一個泛型公司範圍的異常類,這不是一個壞主意。一個答案已經提到了能夠專門捕獲內部代碼異常,並忽略/傳遞來自核心Java或第三方庫代碼的異常。這裏的關鍵是更具體的例外應該從這個繼承。拋出通用公司命名的異常很少需要,幾乎從不建議。

相關問題