e.printStackTrace() заменяет throw?

Часто встречаю подобный код:
Scanner in = null;
try { in = new Scanner(new File(FILE_NAME)); } catch (FileNotFoundException e) { e.printStackTrace(); }
if (in.hasNext()) {
В случае исключения вызовется e.printStackTrace();, что выведет ошибку в stderr, но ведь дальнейшее выполнение метода продолжится с некорректным состоянием?

Ответ

Представленный в вопросе код плох в любом случае:
Если исходное исключение важно (например, этот метод в библиотеке и вызывается извне), то, вероятно, разработчики, использующие эту библиотеку, "отвесят низкий поклон" её создателям за невозможность обработать исключение так как им надо и за довольствование stacktrace-ом в stderr Если исключение не важно (важен только результат), то тут всё равно вместо результата будет NullPointerException, который ещё и непонятно на каком уровне будет обработан. Даже если вызывающая сторона обладает знанием (из документации или магическим образом) того что нужно отлавливать NullPointerException и показывать при этом пользователю сообщение "Файл не найден", то при наличии в методе других потенциальных мест возникновения NullPointerException, эта логика рискует оказаться сломанной

К каким выводам можно прийти:
Если метод используется в библиотеке, то имеет смысл пробрасывать исходное исключение (возможно, в какой-то обёртке). Даже если с точки зрения бизнес-логики важен только результат, то для отладки исключение вполне может понадобиться Если метод является внутренним для программы, то тут уже "на вкус и цвет". Где-то имеет смысл "проглотить" исключение и сделать в catch, например, return null (или дальнейшую логику с in обернуть в if (in != null), если возникшее исключение - ещё не повод прекращать работу метода), где-то - пробросить вверх и обработать, например, глобально