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

BlazkowiczЛюбители выдирать цитаты из контекста и приводить их в качестве контр аргумента
можешь привести контекст, который я якобы опустил и который перестанет делать ограничительное наречие "только" безапелляционным?

Blazkowiczchpashaвот тебе еще пример - андроид
Давай ещё J2ME вспомним. Android это не Java Platform
это конечно все меняет.

BlazkowiczТ.е. вообще никак оценить доступную память и размер экрана???
оценить можно, и выбрать разумные значения по умолчанию тоже. нет полной гарантии что исключение все же не возникнет в тот момент когда ты начнешь даунскейлить картинки и выплевывать их в Listview. по-этому его можно перехватить и еще уменьшить размер thumbnail.

BlazkowiczЛовить OOME и потом жаловаться что Андроид тормозная платформа?
это пример того, когда можно "восстановиться" после исключения. это не значит, что оно выскакивает постоянно. более того, оно может возникнуть лишь каждый надцатый раз после смены ориентации, что в нормальной ситуации никогда не происходит - и тем не менее. теперь разрешаю прочитать лекцию о том, какая чудесная система андроид, и какие кривые руки у тех, кто под него пишет.

BlazkowiczВаше же новое утверждение сводится к тому что "программа должна работать так как задумано". С этим нет смысла спорить.я всего лишь спросил, по каким причинам модулю не стоит знать про IOException. причем спросил не подкола ради, а из любопытства.

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

Petro123chpasha,
ну зачем так усложнять код.
Нехватка памяти обычно означает фатальную ошибку.
в том-то и дело что нет. во первых еще раз повторяю, при правильном подборе размеров исключения почти никогда не бывает. во-вторых если оно и случается, мы уменьшаем размер и все работает прекрасно дальше, для пользователя полностью незаметно.

BlazkowiczстатьяTo avoid java.lang.OutOfMemory exceptions, check the dimensions of a bitmap before decoding it, unless you absolutely trust the source to provide you with predictably sized image data that comfortably fits within the available memory.

Блин, и ничего нет про то что нужно ловить исключение и делать re-scale.
check the dimensions of a bitmap - означает задавайте размер, который система сможет переварить. ты видишь где-то расчет формулы размера, который система сможет переварить? а с учетом неизвестного количества объектов, показываемых одновременно? в примере передается размер 100х100. Откуда взялись эти цифры? Есть ли уверенность, что битмапы такого размера проканают всегда и везде? что будет результатом того, что они не проканали?


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

ОзверинТам просто предупреждают, что таки может выбросить и дают пару советов, как минимизировать риски как бе
ну т.е. как бы понятно, что минимизировать риски это не тоже само что исключить оные. нет? т.е.описанный в статье метод все же выкинеть исключение на одном из 100 смартфонов, если я быстро быстро поверну экран туда сюда пару десятков раз. то бишь на одном из 100 смартфонов "оптимальный" размер все таки окажется не оптимальным и вот тогда захват исключения и повторный вызов может решить исход сражения ну или оттянуть конец, а там глядишь андроид прибьет ненужный сервис и с памятью опять станет шоколадно.

Озверин..понятное дело, что аутофмемори может все что угодно выбросить
в отличии от упомянутой ситуации придется очень сильно постараться

Petro123chpasha,

ok. Хочу ещё примеров ремонтирования программы на ходу и добавления в кавычках памяти.
JetBrains IDEA вроде пытается не умереть и просит увеличить себе лимит heap size

из своего репертуара так сразу больше не припомню. впрочем неверно расценивать фразу "что-то сделать по этому поводу" обязательно как попытку починить. выдать ошибку в лог и послать мыло тоже себе вполне "что-то сделать".

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

Blazkowiczchpashaа с учетом неизвестного количества объектов, показываемых одновременно?
Это как? Программа не знает сколько ей показывать? Или не может прикинуть по размеру экрана? Или что?
[терпеливо] это так, что когда ты показываешь список объектов в ListView очевидно что рендерятся они не все, а только некоторые. сколько конкретно, зависит как минимум от реализации ListView, размеров твоего экрана, пропорций каждого элемента.

Blazkowiczchpashaв примере передается размер 100х100. Откуда взялись эти цифры?

В примере выводится строка "Hello World!". Откуда взялась эта строка? КО сообщает что это просто пример.
хватит паясничать. это как-то странно сочетается с попыткой общения на Вы - вызывает когнитивный диссонанс.

BlazkowiczЯ прочитал статью, поэтому способен сравнить с тем что ты говоришь. Не нужно мне пересказывать что там написано.
пока что ты рассуждаешь о сферических конях.

BlazkowiczТ.е. прокидывает исключение на верхний уровент - GUI\Uncaught и показывает сообщение пользователю. OOME никак не чинится в том месте где он произошел, есть речь про IDEA.
это был ответ на просьбу о примере починки. а ты со своим "прокидывается" все никак не угомонишься.

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


BlazkowiczНу, и проект будет испещрен кодом вида



ясно, аппендеры у нас уже отменили. а если ошибку в базу надо записать, то вызов видимо будет выглядеть как logAndPersist. видимо сегодня просто не твой день, да? ну или азарт молодецкий.

BlazkowiczТ.е. соответствующий API в Android отсутствует в принципе
чтобы не быть категоричным - мне о подобной возможности не известно (имеется в виду узнать из аппа сколько ему доступно всего и сколько еще свободно). знаю только, что выделяемый объем от устройства к устройству и от версии к версии варьирует.

Blazkowiczchpashaзависит от реализации ListView
Ещё один мистический фактор. Программа не знает какую реализацию ListView она использует и отсюда не может оценить количество картинок.т.е. что кол-во версий андроида строго больше одной - это для тебя открытие? и соответственно реализация ListView в версии 2.1 не обязана быть идентичной с 4.1?

Blazkowiczchpashaхватит паясничать. это как-то странно сочетается с попыткой общения на Вы - вызывает когнитивный диссонанс.
Твои попытки перейти на демагогию не располагают меня к другому стилю общения.
ясно

Blazkowiczchpashaпока что ты рассуждаешь о сферических конях.
Смотри как зацепился. Хоть бы на один пост по теме ответил.
по какой теме? мы от темы топика уползли уже очень далеко.

BlazkowiczНу, смотри. Тебе самому по сути сказать нечего.
с учетом того, что ты мне приписал утверждение, которого я не говорил и теперь меня же за него азартно разоблачаешь :) ? что тут скажешь.

Blazkowicz Как не поглумиться с такого? Ну, будет аппендер. Будет 5-10 писем на одно исключение.
да-да, я как раз об этом выше написал.

Blazkowiczи азарт никуда не девался.
что да то да. наш паровоз летит вперед и все такое. ну ты эта, еще читай иногда, что тебе в ответ пишут.

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