Respostas:
Por um momento, vamos para o Stack Overflow - Quão lentas são as exceções de Java?
Acontece que a parte cara de lançar exceções é a população do rastreamento de pilha que acompanha a exceção.
Esse rastreamento de pilha é muito útil ao depurar problemas para tentar descobrir de onde as coisas estão sendo chamadas. Uma das perguntas padrão dos problemas é "qual é o código" e "qual é o rastreamento de pilha". Sem essas duas coisas, diagnosticar um problema é quase impossível.
No entanto, nem todas as exceções são geradas por problemas . Alguns deles, você quase espera.
Considere a situação em que você obteve uma String de alguma fonte e deseja recuperá-la em um formato inteiro com Integer.decode .
Integer foo = Integer.decode(str);Mas isso decodedá uma checada NumberFormatException. Está bem...
Integer foo;
try {
foo = Integer.decode(str);
} catch (NumberFromatException e) {
// raise an error back to the input form
}Mas você realmente não se importa com o rastreamento de pilha lá ... mas está lá. E um pouco mais devagar porque preenchia o rastreamento da pilha.
Assim, em Scala, você tem o NoStackTrace:
Uma característica para exceções que, por motivos de eficiência, não preenchem o rastreamento de pilha. A supressão do rastreamento de pilha pode ser desativada globalmente por meio de um wrapper de propriedades do sistema em scala.sys.SystemProperties.
Não preencha o que você não precisa. Você não se importa com o rastreamento de pilha porque está lidando com ele ali mesmo. Isso não é algo que está sendo esquecido, e também não é tão excepcional.
Não é uma prática ruim usá-lo quando você sabe o que está lidando. Mas, se você estiver passando isso adiante - não use - talvez seja necessário registrar de onde veio alguma exceção.