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

_>Я же говорю, никаких ограничений в этом смысле...
_>Т.е. как я понял стали бы использовать, да?

Разумеется.

_>А какие преимущества (по сравнению с приведённым кодом) в данном конкретном случае вы от этого видите?

Что бы обработать CreateProfile нужно знать, как именно обрабатывать и иметь для этого все необходимые депенденсы. Соответсвенно без исключений такие вызовы надо обкладывать проверкой кода возврата и вызывать функцию обработчик ошибок.
А с исключениями этого ничего не надо, достаточно в одном единственном месте указать try-catch и в нем обработать.

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

[]

P>>2. Или ты хочешь поговорить о том, нужно ли ф-и ReadProfile кидуть исключение вместо кода возврата?

_>Естественно и вообще то это прямо и написано в том моём сообщение.

Если ограничиваться только данным куском и вводными то OnInit'y ничего другого кроме как

try
{ ReadProfile(name); }
catch (profile_error const&)
{ CreateNewProfile(name); }

не остается.
Если посмотреть на задачу немножко более подробно — все может сложиться иначе (с)

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

_>Теперь осталось только определиться, что же тогда на практике нам удобно обрабатывать через исключения?

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

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

_>>Т.е. как я понял стали бы использовать, да?
T>Разумеется.

Ну вот. А на меня тут уже несколько человек накинулось, зачем это я привёл этот пример. Вот как раз потому и привёл, что многие придерживаются вашей точки зрения. С которой лично я не согласен. Хотя это в какой-то степени дело вкуса конечно же.

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

P.S. Вот как раз существование вашей точки зрения и является для меня в какой-то степени обоснованием правильности бана некоторыми компаниями исключений вообще. Только без обид)

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

X>возможно, причину нужно искать в себе, а не в инструментах/средствах/проектах/кодах?
Ну ищи...

Я тебе ещё раз говорю, что несколько лет занимался тем, что переносил довольно боьшие проекты под разные платформы. ЧУЖИЕ проекты. И находил там просто тонны ошибок. В частности все эти гарантии безопасности при исключительных ситуациях -- филькина грамота. В реальном коде они НЕ ОБЕСПЕЧИВАЮТСЯ. Это такое вот моё эксперементальное наблюдение.
И в моём, скорее всего тоже. Это просто слишком трудно верефицируемое свойство кода, что бы можно было его гарантировать...

X>нет, я понимаю, что проще найти "виновника" вне себя. но вы должны понимать, что это временное "решение", и ухождение от решения истинной проблемы, только усугубляет ситуацию, и, как следствие, "затуманит" понимание истока проблемы.
Ой, ищи виновников чего хочешь, где придумаешь.
Я всего лишь делюсь опытом, и предлагаю тебе небольшой эксперимент.
Если ты так уж уверен в своём проекее, то в чём проблема? С чего вся эта попаболь?..

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

P>Если ограничиваться только данным куском и вводными то OnInit'y ничего другого кроме как
P>

P>try
P>{ ReadProfile(name); }
P>catch (profile_error const&)
P>{ CreateNewProfile(name); }
P>

P>не остается.
P>Если посмотреть на задачу немножко более подробно — все может сложиться иначе (с)

Так вы не уточнили какой вариант предпочли бы лично вы...

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

E>Я тебе ещё раз говорю, что несколько лет занимался тем, что переносил довольно боьшие проекты под разные платформы. ЧУЖИЕ проекты. И находил там просто тонны ошибок. В частности все эти гарантии безопасности при исключительных ситуациях -- филькина грамота. В реальном коде они НЕ ОБЕСПЕЧИВАЮТСЯ.
это просто слова.
велкам

Автор: niXman
Дата: 26.02.13

.

E>С чего вся эта попаболь?..
нет никаких переживаний. просто я люблю понимать истинные причины а не те, которые люди пытаются выдать за таковые. как правило.

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

MTD>Очевидно это те ошибки которые нельзя обработать на данном уровне и игнорирование которых делает дальнейшую работу программы бессмысленной.

Подпишусь под этой формулировкой.

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

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

X>решение несуществующих проблем мне мало интересно. но обработка С++ ошибок в Си-стиле, всегда более запутанная и "дырявая". и это факт.

А что значит "дырявая", и что значит "в С стиле"?
Я тут где-то писал как на мой взгляд стоит использовать исключения...
И как можно от них рпри этом отказаться, если это зачем-то надо...

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

P>Вполне возможно.
P>Мой поинт в том, что тот уровень обработки ошибок, который обеспечивает "сферический программист в вакууме" за которого так болеет тролльErop, с помощью исключений обеспечивается проще и приятнее.
P>Ясное дело, когда начинаются holy wars, все внезапно пишут код не иначе как для "ядерных реакторов" (tm), и начинают сыпать терминами про вилидность\верифицируемость\гарантии etc.

Совсем запутал. Так надо тартить усилия на обеспчение базового уровня гарантий безопасности ВСЕГО КОДА или нет?..
Если надо, то пофиг на то, какой уровень обработки ошибок мы там обеспечили. Проблема не в том, что мы там что-то обеспенчили или не обеспечили, чего может и не случится вовсе, а в том, что мы потратили много усилий не пойми на что. И именно эти вот доп. усилия и пессимизацию и надо сравнивать с доп. усилиями и пессимизацией в других подходах. А не мифическую производительность обработки исключений...

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

P>1. Зачем его переписывать через исключения, что було?
P>Если ты можешь обработать "ошибку" на этом уровне, ее и нужно там обработать. Для данного случая это не ошибка, это нормальная ситуация.
P>Исключением это будет если ты на этом уровне не можешь вызвать CreateNewProfile, тогда логично кинуть исключение,
P>которое поймает тот уровень который может сделать CreateNewProfile.


Это, кстати, ещё одна большая проблема исключений. Когда их начинают обрабатывать не помйми кто когда и где. Большой проект быстро превращается в абсолютно неотлаживоемое УГ..

"Неотлаживаемое" тут обозначает, что что-то гавкается, потом это как-то где-то неведомо где и как 2обрабатывается", в результате гавкается ещё что-то малопредсказуемое, и когда наконец-то мы получаем какое-то наблюдаемое поведение до исходной причины уже не добраться.
Лапша из goto времён спагети-кода просто полнейшая халява по сравнению с этой обработкой исключений "на подходящем уровне"

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

_>Ошибки выделения памяти видимо. А ещё что? )

Самое обидное, что как раз вот ошибки выделения памяти через исключения обрабатывать неудобно. Казалось бы всё хорошо, но типичный обработчик исключения в типичной программе сам чегой-то аллокирует. В логи там пишет, окошки кажет и т. д... А памяти-то нет, так что всё радостно валится дальше совершенно малопонимабельным образом...

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

T>Исключения нужны для того, что бы код обработки ошибок был в одном месте, а не везде по коду. Скажем это может быть публичный метод компонента. Глубина вызовов из этого метода может быть сколь угодно большой, это не создает никаких проблем для исключений.

Так, этот подход мне нравится намного больше. Теперь осталось разобраться ещё с гарантиями безопасности при исключениях. Так ли уж нужна базовая гарантия?

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

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

MTD>>Очевидно это те ошибки которые нельзя обработать на данном уровне и игнорирование которых делает дальнейшую работу программы бессмысленной.

_>Подпишусь под этой формулировкой.

_>И при этом замечу, что если следовать ей, то на исключения выпадает совсем небольшая часть общей массы обработки ошибок.

Правда? Это только в двухстрочных примерах все так хорошо и разницы не видно.
А на самом деле внутри твоей функции ReadProfile зовется еще 50 функций на 10 уровнях вложенности. И ни одна из них, заметь, не способна обработать ошибку на своем уровне, и ей остается лишь передать ошибку на верхний уровень, который способен принять решение "Не считалось? Ну и хрен с ним, создадим новый".
Так что твой пример с загрузкой чего-то сложного хз откуда — это как раз идеальный пример кода, в котором исключения работают просто офигительно. Потому что любая ошибка в процессе загрузки фатальна для этого самого процесса загрузки и может быть обработано лишь на самом верхнем уровне, откуда пришел приказ загружать.
А такой порядок работы можно гарантировать только исключениями.

You will always get what you always got
  If you always do  what you always did

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

_>Кстати, а как вам точка зрения этих нескольких человек выше по темке, что мол этот случай не имеет никакого отношения к исключениям и соответственно его надо обрабатывать через коды возврата?

Очень просто — в С++ не смотря на слова try catch throw нет полноценных исключений. Нет слова leave, нет слова finally, зато есть неприятные особенности деструкторов и раскрутки исключений.
Лично я встречал и не раз, когда деструктор вызывает какую то логику финализации и один из методов из этой логики после какого то фикса вдруг начинает бросать исключения, что даёт недокументированый Terminate.

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

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

_>>Ошибки выделения памяти видимо. А ещё что? )

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

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

You will always get what you always got
  If you always do  what you always did

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

J>Ну, прибегая к твоей любимой тактике ведения дискуссии, я готов поверить, что в вашей команде подходят так наивно к обработке ошибки выделения памяти и имеют из-за этого проблемы, но не надо распространять этот детский опыт на всех.
J>

А что делают все? Сдувают подушку?
Исключения они же того, ещё и стек свернут, а при этом много чего позваться может...

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

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

P>>1. Зачем его переписывать через исключения, что було?
P>>Если ты можешь обработать "ошибку" на этом уровне, ее и нужно там обработать. Для данного случая это не ошибка, это нормальная ситуация.
P>>Исключением это будет если ты на этом уровне не можешь вызвать CreateNewProfile, тогда логично кинуть исключение,
P>>которое поймает тот уровень который может сделать CreateNewProfile.


E>Это, кстати, ещё одна большая проблема исключений. Когда их начинают обрабатывать не помйми кто когда и где. Большой проект быстро превращается в абсолютно неотлаживоемое УГ..

E>"Неотлаживаемое" тут обозначает, что что-то гавкается, потом это как-то где-то неведомо где и как 2обрабатывается", в результате гавкается ещё что-то малопредсказуемое, и когда наконец-то мы получаем какое-то наблюдаемое поведение до исходной причины уже не добраться.
E>Лапша из goto времён спагети-кода просто полнейшая халява по сравнению с этой обработкой исключений "на подходящем уровне"

Мои 5 копеек — тоже много раз видел этот чудесный стиль "я кинул и я молодец". Люди не хотят думать об обработке ошибок используя вместо этого прочитанный в книжках "универсальный" подход, к тому же позволяющий избежать гемороя с продумыванием того, что делать с ошибкой. Типа там сверху виднее будет. Часто бывает так, что поймавший просто не знает что делать с ошибкой. Просто кинуть — не значит обработать.

Я часто всякую математику пишу. Есть "классная" мысль — кидать domain_error, если не попал в область определения функции (ну например корень из отрицательного числа пытаешься подсчитать). Так вот, не понятно, что с этим исключением делать на верхнем уровне после вызовов 100500 корней внизу. Но чел считает, что он ошибки обрабатывает, ведь кинул, чо. В результате — УГ и отладка за автора.

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

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

J>>Ну, прибегая к твоей любимой тактике ведения дискуссии, я готов поверить, что в вашей команде подходят так наивно к обработке ошибки выделения памяти и имеют из-за этого проблемы, но не надо распространять этот детский опыт на всех.
J>>

E>А что делают все? Сдувают подушку?
Именно. Сдувают предварительно надутую подушку.

E>Исключения они же того, ещё и стек свернут, а при этом много чего позваться может...
"Много чего" должно учитываться при выборе размера подушки.

You will always get what you always got
  If you always do  what you always did

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

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

Типичный обработчик обрабатывает конкретную ошибку, а не все подряд. Во первых, если все тухло, то спасать уже нечего. Во вторых, если чего то спасти можно, то обработчик нехватки памяти как раз ничего и не выделяет, для него пишется специальный случай и вызывать будет чз catch(OutOfMemory ex).
Представь, без исключений нужно все аллокации проверять вот так

MyClass *pInstance = new MyClass();

if(!pInstance)
{
/// И чо ? Прямо здесь, как правило, нет возможности обработать эту ошибку и надо транслировать на самый верх, то есть все функции вверх по стеку должны знать про это
/// Как правило, только на самом верху появляется возможность обработать именно OutOfMemory
}

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