不能這麼說吧，JDK自帶的異常畢竟不能完全描述“程式碼執行過程中的所丟擲的所有問題”，比如：引數為空，引數格式不正確，資料無法查詢，呼叫第三方程式異常……的情況，所以自定義異常在所難免，我們將異常一般在表現層需要做“合適的處理，防止異常丟擲到頁面上”，如果全用JDK的異常，那麼我們就如何區分？不可能所有的錯誤，我們都返回的是“系統繁忙，請稍後重試！”，所以不認為throw自定義異常就不優雅了，如果感覺不優雅我們可以採用切面上處理異常，核心程式碼中沒有異常資訊，這就優雅了！！！

樓主，首先負責任的告訴你，手動拋異常是一件優雅的事。

1、寫程式碼時候，我們經常會用到try catch語句，但是由於專案迭代速度比較快，可能一個專案會出現好幾波人來寫。各種異常、各種捕獲、各種處理，各自為政。這個時候，定義專案規範就很重要。

2、在開發過程中，如果某塊程式碼出現了異常，那麼我們很多時候其實並不知道是由於什麼原因導致的異常，而只是透過經驗來判斷這裡需要加try catch語句捕獲。這個時候，那麼catch一般我們會宣告Exception來捕獲，因為Exception是Java中異常的基類，可以捕獲所有程式執行時異常。異常發生時，我們透過catch塊拿到異常，日誌記錄該異常的具體原因，同時透過對異常或程式碼業務的判斷，選擇性的向上層丟擲我們之前定義的異常和異常碼，這樣系統上層（Controller層）就知道如何通知給使用者了。

3、定義框架異常統一處理機制。大型系統，我們一般都會手動定義異常，也就是自定義異常。這樣做的好處有很多，其中尤為重要一點的就是可以透過列舉定義系統各模組的異常碼。比如說，系統中某個請求出現session丟失或者引數異常的狀況時，就會丟擲異常碼為10001的執行時異常。那麼使用者在使用中透過閱讀使用者手冊，就知道出現10001異常碼時，重新登入一下系統，那麼這個異常處理無論是在開發、測試、甚至上線後執行中都是比較優雅的。

故，在我來看，不論您用什麼框架去做開發，在前期定義好異常處理機制和異常碼（異常字典）都是非常重要的。

你換個角度考慮，如果把A異常包裝成B異常確實是不規範的做法，應該禁止使用，那麼我們的程式碼會變成什麼樣？

比如系統的底層，不管是查詢資料庫，還是呼叫某個REST服務，本質都是訪問網路，那麼訪問網路必然丟擲IOException、SocketTimeoutException等異常，但因為不能對這些異常再次包裝，所以要麼catch住，列印一下日誌，然後返回一個false代表本次操作失敗，要麼就是把這些底層異常層層往上拋，然後在最前端的Controller/Action/Servlet裡處理，或者Controller/Action/Servlet也不處理，繼續拋、拋給框架或者容器，那麼這樣是不是就規範了呢？是不是就優雅了呢