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

PD>Мы же пишем код очень низкий по стеку вызовов.
Мы — это кто? В реальном ентерпрайз-коде типичная глубина стек-трейса — пара сотен фреймов.

PD>А это чаще всего означает, что мы вкладываем некую новую функциональность, которая изначально не была заложена во всех этих четырех библиотеках от семи разных источников. Ну например, работа с данными, которые поступают из файлов, которые лежат в какой-то встраиваемой ФС, а мы решили встроить новую ФС, а в ней нам нужно завести какое-то исключение, которого ни в одной из существующих ФС никогда не было. Такая уж странная ФС.
Ничего странного. Например, предкам не приходило в голову, что данные могут лежать не на диске, а в клауде.

PD>Если его и впрямь нельзя уложить в одно из исключений ранее существовавших ФС, то это значит, что мы работаем с чем-то принципиально новым. И тогда понятно, что прежний код (все четыре библиотеки от семи источников), в общем-то, не рассчитан на это нововведение. И обработать эту ошибку он не может (вариант с его переписыванием в виде (1) не обсуждаем). А вообще-то должен бы именно он это делать. А мы фактически хотим пробросить эту ошибку, минуя все слои, которые могли бы ее обработать, на один из верхних уровней, где обработать ее по существу едва ли удастся, удастся лишь признать неудачу.
С чего бы это? На самом верху — наш код, он знает, чем retryable HTTP error отличаются от non-retryable.
в самом низу — тоже наш код, он как раз порождает разные виды исключений, в зависимости от кода HTTP-респонса.
А вот в середине — треш, угар и содомия возрастом 30+.

PD>В самом деле, ну поймали мы ее там, и что дальше ? Разве что повторить операцию с какими-то изменениями... А это и значит, что возникло исключение, которого код не ждал. То есть фактически unchecked exception. И тут действительно можно выбросить RuntimeException.

Ну, так проблема — в том, что компилятор теперь нам ничего не говорит о том, где это исключение нужно ловить. Нам показалось, что мы его перехватили, а на практике оно вылетело куда-то вовсе не туда, где мы поставили catch.
Это и есть подрыв всей идеологии checked exceptions.

PD>Подозреваю, что не поэтому, а потому что унаследовались от C++, а в нем тогда (не знаю как сейчас) throws в сигнатуре метода ровным счетом ничего не делало. Так, для красоты...
Нет. Никто там от С++ не наследовался. И подозревать причины нет — все ходы записаны, включая ход мысли отцов-основателей.


PD>А с uncheked exception другая проблема. Я с ней именно на C# когда-то столкнулся. Все сделано по документации, все работает, и вдруг вылетает XyzException. В документации ни слова о том, что оно может быть выброшено. Да это и неудивительно, так как оно выбрасывается не вызываемым методом самим, а методом третьей из 4 библиотек семи разработчиков, о которых вызываемый метод и не знает ничего. Ну ладно, чертыхнулся, написал для него catch (хорошо, хоть было понятно, что за исключение и что делать) и задумался — а какие еще исключения этот метод может выбросить не сам, а в одной из этих 4 библиотек ? Дай ответ... Не дает ответа.
В Java у вас будет ровно то же самое. Как раз потому, что в сигнатуре ничего нет, и вдруг вылетает какой-то XyzException, отнаследованный от RuntimeException.

PD>С этим согласен.