BlazkowiczА если мне нужно обработать исключение на уровне, который про IO вообще ничего знать не должен
это как? уровень явно работает с IO, но знать про него ничего не должен?

Blazkowiczchpashaэто как? уровень явно работает с IO, но знать про него ничего не должен?
Ну, расскажи, что ты обычно сделаешь в случане IOException? Закрываются ресурсы в блоке finally. С эксепшном-то че делать?с эксепшеном ничего особенного (как правило) не делаю. Модуль работает с IO. что плохо в том, что он знает - в результате IO может возникнуть IOException? зачем IOException оборачивать в какой-нибудь ImportFailedException только ради самого факта, что последний будет unchecked и модуль ничего не узнает об IO. что мы выиграем?

BlazkowiczПроблема в том что "обработать" исключение может только самый верхний уровень. Или GUI покажет. Или Web Controller перекинет на страницу ошибки.
на самом деле человек правильно написал, обработать исключение должен тот уровень, который по поводу исключения может что-то сделать. и это не обязательно будет самый верхний уровень.

Blazkowiczbla-bla-bla. ... Я не говорил что это абсолют.

BlazkowiczПроблема в том что "обработать" исключение может только самый верхний уровень


ну и кто здесь бла-бла-бла?

Blazkowiczприведите конкретные примеры, как у вас обрабатываются SQLException, IOException без проброса на верхние уровни.
например: создание отчетов через openoffice + jodconverter. можно получить IOException если openoffice демон еще не стартовал или нештатно отвалился. после этого его можно попытаться перезапустить и только если это не помогло выкинуть исключение наверх.

Blazkowiczchpashaну и кто здесь бла-бла-бла?

Тот кто не приводит конкретику.
нет, тот, кто сначала безапелляционно говорит одно, а потом утверждает, что он такого не говорил.

BlazkowiczЯ вам специальных сценариев могу насочинять вагон.
я не сочиняю, а привожу реальный пример. сочинять все умеют. вот тебе еще пример - андроид. есть у нас допустим снятые на камеру смартфона фотки. если их показать в оригинальном виде в списке - вероятность нарваться на OutOfMemory чуть меньше 100%. по-этому что? правильно, надо показывать не картинки а уменьшенные копии. но проблема в том, что невозможно угадать наверняка какого размера картинки не вызовут проблем при этом угодив как владельцам экранов с 2xx ppi и кучей рама так и "нищебродам" с 320х480. Но проблема в том, что метод BitmapFactory.decodeStream уже при ресайзе может выкинуть OutOfMemory
поэтому распространенным подходом является выбор разумного дефолта - поимка OutOfMemory, уменьшение дефолта и повторение ресайза - все это без отягощения пользователя сообщениями о том, что у нас память кончилась.
кстати если посмотреть в логи самого андроида, то можно увидеть например при обращениях к базе, что ему периодически не удается выделить память под блоб, при этом в клиентский код это исключение не попадает.

Blazkowiczэто "частные случаи" для отдельных решений единичных задач. В общем случае (читай подавляющем большинстве) исключение оборачивается и выкидывается наверх.это не частные и не общие случаи, это всего лишь статистика. исключение обрабатывается там, где по его поводу нужно что-то сделать. то что таким местом является чаще всего верхний слой, самого правила не отменяет.