Я столкнулся с NoStackTraceмиксином для исключений в Scala.
Полезно ли его использовать, или его следует считать «внутренним» для скалы и оставить его в покое?
На мгновение давайте перейдем к переполнению стека - насколько медленными являются исключения Java?
Оказывается, что дорогой частью создания исключений является заполнение трассировки стека, которая сопровождает исключение.
Эта трассировка стека очень полезна при отладке проблем, чтобы попытаться выяснить, откуда что вызывается . Один из стандартных вопросов, которые задают о проблемах: «что такое код» и «что такое трассировка стека». Без этих двух вещей диагностика проблемы практически невозможна.
Однако не все исключения порождаются проблемами . Некоторые из них вы почти ожидаете.
Рассмотрим ситуацию, когда у вас есть строка из какого-то источника, и вы хотите вернуть ее в целочисленный формат с помощью Integer.decode .
Integer foo = Integer.decode(str);Но это decodeбросает проверено NumberFormatException. Хорошо...
Integer foo;
try {
foo = Integer.decode(str);
} catch (NumberFromatException e) {
// raise an error back to the input form
}Но вы действительно не заботитесь о трассировке стека там ... но это там. И чуть чуть медленнее, потому что он заполнил трассировку стека.
Таким образом, в Scala вы получаете NoStackTrace:
Характеристика исключений, которые по соображениям эффективности не заполняют трассировку стека. Подавление трассировки стека можно отключить глобально с помощью оболочки системных свойств в scala.sys.SystemProperties.
Не заполняйте то, что вам не нужно. Вы не заботитесь о трассировке стека, потому что обрабатываете ее тут же и тогда. Это не то, что упускают из виду, и это не так уж и исключительно.
Это неплохая практика, когда вы знаете, с чем обращаетесь. Но, если вы передаете это по цепочке - не используйте это - вам может понадобиться просто записать, откуда пришло какое-то исключение.