Переопределение fillInStackTrace для стандартных исключений JVM

Question

Если я использую отражение и хочу выяснить, реализован метод или нет, я могу использовать метод getMethod (). Этот метод генерирует исключение NoSuchMethodException.

Есть ли способ перегрузить fillInStackTrace этого исключения для оптимизации производительности? Прямо сейчас, около 40% времени тратится на этот метод.

Я использую фреймворк, использующий исключения как способ выполнения определенного вида потока управления.

Так что я не хочу быть слишком агрессивным. Если я создаю класс, расширяющий Throwable, и использую этот новый класс вместо NoSuchMethodException, у меня будет что-то вроде:

NewException is never thrown in body of corresponding trystatement

спасибо

Answer 1

Нет, поскольку getMethod() вызывает new напрямую, и вы не можете заменить код для NoSuchMethodException, поскольку класс подписан, а fillInStackTrace() равен native.

Лучше всего кэшировать звонки на getMethod() в центральном месте: просто создайте двухуровневую карту: Map<Class, Map<String, Method>> и используйте быстрый поиск без каких-либо исключений.

Answer 2

Мои два следующих пункта не совсем соответствуют названию вашего вопроса, но я думаю, что они могут быть полезны ...

---

Я подтверждаю ваш показатель эффективности.

Я читал о решении в книге по производительности Java. Мы применили это к нашему собственному приложению, за некоторыми исключениями (где трассировка стека не важна и возможная частота высока). Я не знаю, понравится ли вам это;; -)

Создайте уникальный экземпляр вашего класса Exception, сохраните его. Брось этот экземпляр .

Это кажется идеальным, когда вы не хотите нарушать существующий поток, основанный на исключениях.

---

Если ваш компилятор жалуется на то, что другой метод не генерирует это исключение, то это потому, что вы выбрали проверенное исключение.
Используйте подкласс RuntimeException (они не проверены, поэтому компилятор не знает, брошены они или нет, не будет жаловаться).