我試圖找出什麼異常的正確形式拋出將是我寫的庫。我需要處理的一個例子是將用戶登錄到電臺。他們通過掃描徽章來做到這一點。可能的事情可能出錯包括：何時使用自定義異常與現有的例外與一般例外
使用這個庫將不得不處理這些異常的一種方式或其他應用程序。他們可能會決定只是說「錯誤」，或者他們可能想給用戶更多有用的信息。這種情況下的最佳做法是什麼？爲每種可能性創建一個自定義異常？使用現有的例外？使用例外並通過原因（throw new Exception("Badge is deactivated.");）？我認爲這是前兩種方式的組合，在適用的情況下使用現有的例外情況，並在需要時創建新的例外情況（並在有意義的情況下對例外進行分組）。
你有兩種例外。
那些特定於您的應用程序，這是很好的，以避免任何現有的例外。
您的應用程序特定異常應簡化使用您的庫的人的使用案例。您的應用程序特定異常是用戶可以執行的操作。第四個（徽章不存在）顯然不是程序性的，但更嚴重。
看起來您有兩個特定於應用程序的錯誤：面向用戶的事情和管理錯誤。
其他是其他技術的一部分;即數據庫錯誤。你可以 - 通常 - 忽略這些。如果數據庫不可用，則該API將拋出錯誤，並且可以讓這些數據庫通過您的庫發泡。
您也可以將它們「包裝」爲包含較低級別異常的特定於應用程序的異常。如果有很多較低級的技術，這有時會很有幫助。在你的情況下，它只是一個數據庫。忽略它，讓數據庫錯誤冒泡。
使用異常，並傳入原因（拋出新的異常（「徽章被禁用。」）;）
這當然是一個不好的做法，因爲它違反了例外的目的 - 不僅僅是以表示異常情況的信號，但提供區分類型級別的異常的能力，因此模塊的用戶可以根據異常的類型做出決定。
一般來說，這是好事，儘可能再利用標準的例外，因爲他們完全可以描述你的代碼實際上面臨着異常情況。這是很很難給在當前情況下的提醒，因爲異常往往依賴於語義（參數異常或無效操作異常（也許適合「他們的徽章被停用」的情況下，例如）。
我基本上同意與目前的想法
InvalidOperationException應該表示與您的API有關的不正確的操作，而不是違反業務規則BadgeAuthException，並始終拋出該異常類。具體的方案應在每次獲得自己的子類（BadgeDeactivatedException，NoPermissionsAtWorkstationException等），這樣，如果他們想要的應用程序可以單獨處理各個子的情況下，但他們也可以正好趕上通用BadgeAuthException如果他們不想卑躬屈膝在具體情況。Message字段總是包含不僅僅是異常名的有用信息。我認爲你需要爲每個你描述的座標（實際上你可以使db和內部db錯誤具有相同的基本例外）有一個基本異常和一個子類型異常。關鍵在於最好有自己的例外情況。
通過擴展公共基類的細粒度異常類幾乎不會出錯。那樣的話，需要專門抓住一些並讓其他人通過的呼叫者，以及想要一起對待他們的呼叫者可以這樣做。