Здравствуйте, jazzer, Вы писали:
J>Правда? Это только в двухстрочных примерах все так хорошо и разницы не видно. J>А на самом деле внутри твоей функции ReadProfile зовется еще 50 функций на 10 уровнях вложенности. И ни одна из них, заметь, не способна обработать ошибку на своем уровне, и ей остается лишь передать ошибку на верхний уровень, который способен принять решение "Не считалось? Ну и хрен с ним, создадим новый".
Описаны очень чёткие симптомы кривой и не модульной изначальной архитектуры.
J>Так что твой пример с загрузкой чего-то сложного хз откуда — это как раз идеальный пример кода, в котором исключения работают просто офигительно. Потому что любая ошибка в процессе загрузки фатальна для этого самого процесса загрузки и может быть обработано лишь на самом верхнем уровне, откуда пришел приказ загружать. J>А такой порядок работы можно гарантировать только исключениями.
Хыхыхы, а уже куча народа в этой темке (в том числе и сторонники исключений) уверенно заявила что мой пример даже близко не имеет никакого отношения к исключениям.
Здравствуйте, Tanker, Вы писали:
T>Очень просто — в С++ не смотря на слова try catch throw нет полноценных исключений. Нет слова leave, нет слова finally, зато есть неприятные особенности деструкторов и раскрутки исключений. T>Лично я встречал и не раз, когда деструктор вызывает какую то логику финализации и один из методов из этой логики после какого то фикса вдруг начинает бросать исключения, что даёт недокументированый Terminate.
Нуу в каком-то смысле в C++ заменой finally и т.п. могут быть просто {} скобки... Но в целом да, соглашусь, что цельной системы нет.
хъ
_>Хыхыхы, а уже куча народа в этой темке (в том числе и сторонники исключений) уверенно заявила что мой пример даже близко не имеет никакого отношения к исключениям.
Не имея полной информации о том, что и как делают твои ф-й, как они взаимодействуют, какой контекст и уровень ответственности каждая из них имеет — можно предположить что угодно.
ЗЫ Судя по всему тебе не интересно обсуждение, тебе интересно погыгыкать.
хъ
_>Не согласен. На мой взгляд исключение действительно удобны только для очень узкого вида ошибок, которые должны приводить к глубокой раскрутке стека.
Я не понимаю, что значит "должны приводить к глубокой раскрутке стека". Ошибки никому ничего не должны, наоборот их должны обрабатывать.
Кто, как и где — вопрос выбора в каждом конкретном случае, я лично затрудняюсь дать общие рекомендации.
Возвращаясь к своему примеру анализатора входных данных под заданную спецификацию формата —
парсим нек. заголовок -> опс, нарушение констрейнов (значение должно быть меньше Х) -> обработка — добавляем к списку ошибок
парсим нек. заголовок -> опс, по нек. признакам делаем вывод что это говно какое-то -> исключение -> на уровне где происходит отделение мух от котлет, ловим, записываем и пытаемся пересинхронизироваться, т.е. найти след. sync word. Пытаться обработать ошибку на том же кровне где мы поняли что данные тотально "не те" — значить пытаться упорно найти нужным нам заголовок не понятно из чего, забить список ошибок нерелевантными сообщениями и обтормозить весь процесс. Пытаться там же пересинхронизироваться — размывать логику разбора, размывать ответственность, протаскивать ненужный контекст.
_>Для большинства же случаев (а чаще всего какая-то минимальная обработка ошибок идёт уже на предыдущем уровне стека вызовов) на практике исключения привносят только увеличение сложности и объёма кода.
Практика конечно у всех разная, у меня не было прецендентов усложнения из-за исключений. Обратные преценденты были.
В том числе и с "заменой кодов возврата" (что в принципе порицается) — нужно было протаскивать коды возврата из 3d party, из самой глубины на самый вверх, вплоть до JS скрипта живущего на хтмл странице. Я выкинул всю гору лапши /if(e) return e;/ по всему стеку вызовов (довольно глубоких) и заменил на throw класса который хранит код ошибки (если точнее это boost::system::system_error). Чем очень облегчил себе жизнь и _уменьшил_ объем кода.
Здравствуйте, alex_public, Вы писали:
_>И при этом замечу, что если следовать ей, то на исключения выпадает совсем небольшая часть общей массы обработки ошибок.
Так и источников ошибок на самом деле не так много. А все остальное это логика работы она же управляющая логика. Обычно управляющая логика обменивается результатами сквозь 1 уровень и имеет жесткую смысловую нагрузку.
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, landerhigh, Вы писали:
L>>Впрочем, если у тебя даже при проверки валидности при всех операциях в контейнере оказываются невалидные объекты, то я умываю руки. Случай клинический.
E>Во-первых, при чём тут я?
Потому что это твои слова.
E>Во-вторых, конкретно тут я отстаиваю простой и вовсе и не мой тезис, что надёжные программы пишут так, что предполагают, что ошибки могут быть везде.
Тройной фейспалм.
E>В частности, в таких проектах принято использозвать такую библиотеку assert'ов, которая обеспечивает выполнение проверок и в продакшин сборке. При этом обработка провала assert'а состоит не в вызове terminate, а в чём-то более хитром...
Бесконечный фейспалм.
E>Но в целом ты же умыл руки? И правильно сделал, по существу-то ты так ничего и не сказал, между прочим
По существу мы как раз от тебя ничего не дождались.
E>Ты врде как сообщил тут, что в общем случае кидающего move-конструктора невозможно соблюсти базовую гарантию для вектора. При этом грозился доказать в три строчки...
E>Можешь привести доказательство, или это было так, фигурально выражаясь, так сказать?..
Сначала потрудись убедительно аргументировать, зачем тебе вообще такое понадобилось. И юз кейс, желательно. С объяснениями. Ты влез в эту тему с этой идеей, начинай уже отвечать за слова.
А то ведь на деле может оказаться, что доказательство для твоего случая будет намного короче трех строк.
Здравствуйте, Tanker, Вы писали:
T>Очень просто — в С++ не смотря на слова try catch throw нет полноценных исключений.
Есть.
T>Нет слова leave, нет слова finally
Они не нужны с RAII.
T>зато есть неприятные особенности деструкторов и раскрутки исключений.
Это да, неприятно.
T>Лично я встречал и не раз, когда деструктор вызывает какую то логику финализации и один из методов из этой логики после какого то фикса вдруг начинает бросать исключения, что даёт недокументированый Terminate.
Правда ИМХО возникновение таких неприятностей является симптомом косого подхода к генерации кода. Не встречал лично.
_>Да, я согласен что у них довольно сомнительное решение. Но хочу заметить что лично у меня такого вообще никогда не встречается. Видимо потому, что я считаю что что конструкторы объектов в любом случае не должны завершаться неудачей (т.е. ни исключений, ни двухфазных странностей). С поправкой на особый случай ситуации неудачи выделения оперативной памяти.
Объект Шредингера после вызова конструктора — это, конечно, треш и угар. Но тут и обсуждать нечего — только в переплавку.
По поводу исключений из конструктора: конструктор объекта обязан выкинуть исключение, как только возникает ситуация, делающее существование объекта бессмысленным. Это бывает далеко не так часто, но вовсе не ограничивается обломом с выделением памяти. Например — вектор без памяти никому не нужен. Класс FileLogger на машине без доступной для записи файловой системы тоже. OpenGLRenderer никому не нужен, если нет его поддержки. И так далее. Но все это — именно исключительные ситуации; полагаться исключительно на исключения для обработки таких ошибок не следует, это в некотором смысле последняя линия обороны.
Здравствуйте, Nikе, Вы писали:
T>>Очень просто — в С++ не смотря на слова try catch throw нет полноценных исключений. N>Есть.
T>>Нет слова leave, нет слова finally N>Они не нужны с RAII.
С++ это не только RAII.
T>>зато есть неприятные особенности деструкторов и раскрутки исключений. N>Это да, неприятно.
И это называется полноценные исключения ?
T>>Лично я встречал и не раз, когда деструктор вызывает какую то логику финализации и один из методов из этой логики после какого то фикса вдруг начинает бросать исключения, что даёт недокументированый Terminate.
N>Правда ИМХО возникновение таких неприятностей является симптомом косого подхода к генерации кода. Не встречал лично.
Как послушать местных плюсовиков, так все в шоколаде — код чисто RAII и пишут его люди от 10 лет и выше опытом.
Здравствуйте, Tanker, Вы писали:
T>>>Нет слова leave, нет слова finally N>>Они не нужны с RAII.
T>С++ это не только RAII.
Ты это к чему? Тезис — при использовании RAII finally не нужен. Причём тут "С++ это не только RAII"?
T>>>зато есть неприятные особенности деструкторов и раскрутки исключений. N>>Это да, неприятно.
T>И это называется полноценные исключения ?
Ну да. Есть разумое ограничение. Это не делает исключения неполноценными.
T>>>Лично я встречал и не раз, когда деструктор вызывает какую то логику финализации и один из методов из этой логики после какого то фикса вдруг начинает бросать исключения, что даёт недокументированый Terminate.
N>>Правда ИМХО возникновение таких неприятностей является симптомом косого подхода к генерации кода. Не встречал лично.
T>Как послушать местных плюсовиков, так все в шоколаде — код чисто RAII и пишут его люди от 10 лет и выше опытом.
Причём тут это? Ты хочешь пообсуждать некомпетентных разработчиков?
Здравствуйте, Nikе, Вы писали:
N>Ты это к чему? Тезис — при использовании RAII finally не нужен. Причём тут "С++ это не только RAII"?
Если речь про С++ то вполне понятно, что при чем. А если выбирать удобное подмножество типа C++ && RAII то может оказаться что и виртуальные методы не нужны.
T>>Как послушать местных плюсовиков, так все в шоколаде — код чисто RAII и пишут его люди от 10 лет и выше опытом.
N>Причём тут это? Ты хочешь пообсуждать некомпетентных разработчиков?
Здравствуйте, jazzer, Вы писали:
E>>А что делают все? Сдувают подушку? J>Именно. Сдувают предварительно надутую подушку.
Бинго! А что они делают, когда памяти не хватает во второй раз?
Чем это вообще отличается от старой доброй сишной схемы?
J>"Много чего" должно учитываться при выборе размера подушки.
Э-э-э, это не всегда просто учесть, однако таки...
Тут схема, когда отгрузку/рестарт по нехватке памяти мы прописываем явно намного прямее
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Tanker, Вы писали:
N>>Ты это к чему? Тезис — при использовании RAII finally не нужен. Причём тут "С++ это не только RAII"?
T>Если речь про С++ то вполне понятно, что при чем. А если выбирать удобное подмножество типа C++ && RAII то может оказаться что и виртуальные методы не нужны.
Здравствуйте, Tanker, Вы писали:
T>Типичный обработчик обрабатывает конкретную ошибку, а не все подряд. Во первых, если все тухло, то спасать уже нечего.
Обычно хотят спасти данные пользователя + получить адекватную отладочную инфу...
T>При чем так должен делать не только твой, но и чужой код, типа бустов, стл и тд. T>Самое главное — в итоге, когда все это приобретет законченый вид, вдруг оказывается, что код обработки ошибок делает ровно то же, что и исключения, только явно.
Почему7 В С же как-то жили? По доступу к нулю будет сегфолт, в его обработчике спасут критические данные и запишут в корку отладочную инфу...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Evgeny.Panasyuk, Вы писали:
_>>Нуу в каком-то смысле в C++ заменой finally и т.п. могут быть просто {} скобки...
EP>В каком смысле "просто {} скобки" заменяют finally?
Деструкторы обязательно отработают -> finally не нужен.
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, jazzer, Вы писали:
E>>>А что делают все? Сдувают подушку? J>>Именно. Сдувают предварительно надутую подушку. E>Бинго! А что они делают, когда памяти не хватает во второй раз?
Такого не будет. Приложение входит в режим завершения и корректно выключается.
Памяти на логирование хватит.
E>Чем это вообще отличается от старой доброй сишной схемы?
J>>"Много чего" должно учитываться при выборе размера подушки. E>Э-э-э, это не всегда просто учесть, однако таки...
На логирование хватит.
E>Тут схема, когда отгрузку/рестарт по нехватке памяти мы прописываем явно намного прямее
Куда уж прямее
Здравствуйте, landerhigh, Вы писали:
L>По существу мы как раз от тебя ничего не дождались.
ищите и обрящете...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
