Друк сліду стека винятку сам по собі не є поганою практикою, але тут, мабуть, проблема лише друку трасування стека, коли відбувається виняток - часто разів, просто надрукувати слід сліду стека.
Крім того, існує тенденція підозрювати, що належне поводження з винятками не виконується, якщо все, що виконується в catchблоці, є a e.printStackTrace. Неправильне поводження може означати в кращому випадку ігнорування проблеми, а в гіршому - програму, яка продовжує виконуватись у невизначеному або несподіваному стані.
Приклад
Розглянемо наступний приклад:
try {
initializeState();
} catch (TheSkyIsFallingEndOfTheWorldException e) {
e.printStackTrace();
}
continueProcessingAssumingThatTheStateIsCorrect();
Тут ми хочемо виконати деяку ініціалізацію, перш ніж продовжувати деяку обробку, яка вимагає, щоб ініціалізація відбулася.
У наведеному вище коді виняток повинен був бути вилучений та належним чином оброблений для запобігання переходу програми до continueProcessingAssumingThatTheStateIsCorrectметоду, який, на нашу думку, може спричинити проблеми.
У багатьох випадках e.printStackTrace()це вказівка на те, що якийсь виняток проковтується, і обробка дозволяється протікати так, ніби не виникає жодної проблеми.
Чому це стало проблемою?
Ймовірно, одна з найбільших причин того, що погана обробка винятків стала більш поширеною, пов'язана з тим, як IDE, такі як Eclipse, автоматично генерують код, який виконуватиме e.printStackTraceобробку виключень:
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
(Вищенаведене - це фактично try-catchавтоматично створене Eclipse для обробки InterruptedExceptionкинутого Thread.sleep.)
Для більшості застосувань, просто надрукувати слід стека до стандартної помилки, ймовірно, буде недостатньо. Неправильне поводження з винятками в багатьох випадках може призвести до запуску програми у несподіваному стані та може призвести до несподіваної та невизначеної поведінки.