Natknąłem się na NoStackTracemixin dla wyjątków w scali.
Czy dobrą praktyką jest używanie go, czy też powinno być uważane za „wewnętrzne” dla Scali i pozostawione samym sobie?
Na chwilę przejdźmy do przepełnienia stosu - jak powolne są wyjątki Java?
Okazuje się, że kosztowną częścią rzucania wyjątków jest populacja śladu stosu, która idzie w parze z wyjątkiem.
Ten ślad stosu jest bardzo pomocny podczas debugowania problemów, aby dowiedzieć się, skąd się biorą wywołania. Jednym ze standardowych pytań zadawanych na temat problemów jest „co to jest kod” i „co to jest ślad stosu”. Bez tych dwóch rzeczy zdiagnozowanie problemu jest prawie niemożliwe.
Jednak nie wszystkie wyjątki są generowane przez problemy . Niektóre z nich, prawie się spodziewasz.
Zastanów się, czy masz ciąg znaków z jakiegoś źródła i chcesz przywrócić go do formatu liczb całkowitych za pomocą Integer.decode .
Integer foo = Integer.decode(str);Ale to decoderzuca sprawdzone NumberFormatException. Dobrze...
Integer foo;
try {
foo = Integer.decode(str);
} catch (NumberFromatException e) {
// raise an error back to the input form
}
Ale tak naprawdę nie obchodzi cię ślad stosu, ale tam jest. I tylko odrobinę wolniej, ponieważ zapełnił ślad stosu.
Tak więc w Scali masz NoStackTrace:
Cecha wyjątków, które ze względów wydajności nie wypełniają śladu stosu. Eliminację śledzenia stosu można wyłączyć globalnie za pomocą opakowania właściwości systemowych w scala.sys.SystemProperties.
Nie wypełniaj tego, czego nie potrzebujesz. Nie obchodzi Cię ślad stosu, ponieważ zajmujesz się nim od razu. To nie jest coś, co się omija, i nie jest to wcale takie wyjątkowe.
Nie jest to zła praktyka, aby używać go, gdy wiesz, z czym masz do czynienia. Ale jeśli przekazujesz to w górę łańcucha - nie używaj go - być może będziesz musiał zalogować się, skąd pochodzi jakiś wyjątek.