Здравствуйте, Pzz, Вы писали:

Pzz>>>Можно, разумеется, но народ забывает. Это невозможно не забыть. Вот и вылетают непойманные на своем уровне исключения наверх, где их никто не ждет.

D>>Да и нехай значит. Всё лучше, повторюсь, чем молча глотать. А на верхнем уровне можно журналировать всё непойманное, потихоньку фикся ранее забытое.

Pzz>Тогда их на верхнем уровне будут молча глотать. С журналированием в /dev/null, ага.

Pzz>P.S. Наверное, было бы легче, если бы исключения, которые могут прилететь от методов класса, должны были бы быть описаны в самом классе. И если метод класса зовет швыряющуюся чужеродными исключениями функцию, то компилятор бы требовал обложить ее соответствующими try/catch, чтобы незаявленные исключения наружу бе вылетали.

Это Checked Exceptions в Java.

Проблема в том, что во-первых есть очень много исключений, которые вылетают очень редко. Например ошибка связи с БД. У нас БД надёжная и работает надёжно и с ней нет ошибок связи. Но теоретически то вылететь может! А значит придётся обкладывать try-catch каждую операцию с БД.

Во-вторых ряд исключений не вылетит вообще никогда. Например Integer.parseInt("1"). Никогда тут не вылетит исключение NumberFormatException. А компилятор попросит обложить try-catch-ем.

В-третьих ряд исключений могут вылететь в любом месте. В разных языках по-разному. Например NullPointerException теоретически может вылететь на любой строчке, где есть ссылки или вызывается функций. StackOverflowError может вылететь опять же везде, где вызывается любая функция. Что с ними делать?

Первая и третья проблема решаются выделением NonChecked Exceptions. Опять же возникает исходная проблема, что хотя исключение и вылетает раз в год или "по идее" не должно вылетать, но оно вылетит. NullPointerException особенно. И это надо помнить и обрабатывать.

Вторая проблема вообще никак не решается. Вот получил я userId от API, вызываю userService.getUserInformation(userId). А он мне говорит обрабатывай UserNotFoundException. Не может такого быть, я только что этот userId из базы считал, он там 100% есть. Как я буду обрабатывать? Только выкину UnexpectedSituationException, а вы там выше логгируйте и разбирайтесь. И таких catch-ей на каждом шагу очень много будет. Синтаксический хлам.

Кстати ещё одна интересная проблема с наследованием. Вот описали мы

interface Closeable {
    void close();
}

теперь примеряем его на FileInputStream, а оказыавется, что close там хочет кидать IOException. Чего нам делать? Либо добавляем в throws IOException, либо перекидыаем как непроверяемое исключение. И имеем опять что имеем.

Если добваляем throws IOException, то куча классов этот IOException никогда кидать не будет. StringWriter, например, пишет во внутренний буффер-строку, никакого там IO нет. А вот при закрытии — изволь, обработай IOException, мало ли, вдруг кинется, в сигнатуре написано же.