Mi sono imbattuto in NoStackTrace mixin per Exceptions in scala.
È buona pratica usarlo, o dovrebbe essere considerato "interno" a scala e lasciato solo?
Per un momento, passa a Overflow dello stack - Quanto lente sono le eccezioni Java?
Risulta che la parte costosa delle eccezioni di lancio è la popolazione della traccia dello stack che accompagna l'eccezione.
Questa traccia dello stack è molto utile quando si esegue il debug dei problemi per cercare di capire da dove vengono chiamate le cose. Una delle domande standard poste ai problemi è "qual è il codice" e "qual è la traccia dello stack". Senza queste due cose, la diagnosi di un problema è quasi impossibile.
Tuttavia, non tutte le eccezioni sono generate da problemi . Alcuni di loro, quasi ti aspetti.
Considera la situazione in cui hai una stringa da una fonte e vuoi recuperarla in un formato intero con Integer.decode .
Integer foo = Integer.decode(str);
Ma quel decode genera un controllo NumberFormatException . Ok ...
Integer foo;
try {
foo = Integer.decode(str);
} catch (NumberFromatException e) {
// raise an error back to the input form
}
Ma davvero non ti interessa la traccia dello stack lì ... ma è lì. E solo un po 'più lento perché popolava la traccia dello stack.
Quindi, in Scala, hai ottenuto NoStackTrace :
A trait for exceptions which, for efficiency reasons, do not fill in the stack trace. Stack trace suppression can be disabled on a global basis via a system property wrapper in scala.sys.SystemProperties.
Non popolare ciò di cui non hai bisogno. Non ti interessa la traccia dello stack perché la stai gestendo proprio lì e poi. Questo non è qualcosa che sta per essere superato, e non è nemmeno così eccezionale.
Non è una cattiva pratica usarlo quando sai cosa stai gestendo. Ma, se passi questo sulla catena - non usarlo - potresti semplicemente registrare da dove provengono alcune eccezioni.
Leggi altre domande sui tag exceptions scala