1樓：闞灰灰
過載fillInStackTrace在業務異常中很常見，但是如果一定要說弊端的話，如果想要stack的時候反而沒有辦法了，遮蔽異常棧主要是為了不執行private native Throwable fillInStackTrace(int dummy);這個方法而提高效率，出於這個目的考慮的話有更好的方案，動態決定需不需要異常棧——新增業務異常增加建構函式，用引數決定是否需要異常棧。呼叫Throwable的建構函式：
protected Throwable(String message, Throwable cause,
boolean enableSuppression,boolean writableStackTrace);。
2樓：
可以。但是最主要的是取決於你怎麼使用Exception。
有種觀點認為，業務失敗異常流程應該基於Exception控制，在這樣的專案裡就會看到大量的基於業務定義的Exception類，比如UserNotFoundException，LoginFailException什麼的。或者把Service層所有的異常分支都包裝成乙個ServiceException什麼的。這種情況下，throw Exception 就成為乙個很常見的事件，這時過載fillInStackTrace 是可以有效益的。
但是我看到的大多數情況，大家還是把Exception作為技術上的異常而不是業務上的異常。所以，理論上要用到異常的時候不多。要真是發生了Exception，由於超出預期，反而恰恰需要stack trace。
3樓：
如果樓主做的是業務系統的話，建議避免使用這種做法來提高效能，從其他方面考慮吧。像R大說的，不需要stacktrace資訊的時候，可以覆蓋這個方法達到提高異常效能的目的。不過，業務系統變化太快，今天不需要異常資訊，說不定明天就需要了。
我自己就遇見過這樣的case。
過載與重寫？
Leah 重寫與過載，名稱上雖一字之差，但卻是兩個完全不同的東西，所以區分起來很容易。如何分清楚方法過載與重寫，可以從以下幾點來區分 一 1 過載 指不同的方法使用相同的名稱，但是方法的引數個數或型別不同。呼叫的時候根據函式的引數來區別不同的函式。如 int Add int a,int b 與 fl...
C 過載 後可以直接 a 2 ，那為什麼過載 後不能 a 2 而要a 2
ZDH 源程式要先過詞法分析這一關 比如 a 2 就要拆成 a,2,這幾個單詞 然後過語法分析 a,2,會歸約為乙個類似函式呼叫的節點 然後才是語義繫結 函式呼叫 賦值 仿函式或是其他有限可能中的乙個 a,2 過不了語法分析，就沒辦法向下進行了。 支援向量機 你在用別人的東西，別人的編譯器，就得聽別...
過載是多型體現嗎？
黃亮anthony 過載和多型之間概念有交叉。多型是同乙個型別，表現出多種不同行為。過載可以根據靜態子型別分派不同實現，所以它是一種靜態多型。但是，有些過載並不是針對靜態子型別，所以它不是多型。classA class BextendsA class CextendsA public class C...