Преветствую

Идея возникла когда нужно было получить информацию из глубины дерева объектов. Информация была не типичной и в проекте не была запланирована. Переделовать код было очень обломно. Попробовал передать инфу через механизм исключений. Чесно скажу методика мне понравилась, можно без особых напрягов передавать результирующие данные даже используя те наработанные методы в которых данная операция не заложена, и самое гланое не нужно знать как, где и каким образом результирующие данные получены

// псевдокод
try{
     запрос_данных();
} catch(данные& d)
{
    обработка(d);
}
return NULL;

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

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

_>Кто как к этому относится? обсудим?

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

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

Попробуйте поиском воспользоваться.
Уже было обсуждение возвращаемых значений против исключений.

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

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

_>>Кто как к этому относится? обсудим?

SDB>Механизм исключений должен использоваться только для того, для чего он предназначен — для обработки ошибок... (с) доктор Страуструп

абсолютно согласен!!!

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

A>абсолютно согласен!!!

Э-э-э... там справа есть такая штука — "согласен". Это я не к тому, что оценку надо поставить, а к тому, что можно проще, коллега.

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

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

_>>Кто как к этому относится? обсудим?

SDB>Механизм исключений должен использоваться только для того, для чего он предназначен — для обработки ошибок... (с) доктор Страуструп
Что считать ошибкой вопрос чисто филосовский. Что считать ошибкой: когда программа прошла весь цикл и ненашла правильного ответа или в процесе поиска было внезапно найдено решение. В данном случае принимается что внезапное решение есть ошибка единствено сложновато потом отличить где настоящая ошибка а где надуманная.

NN>Попробуйте поиском воспользоваться.
NN>Уже было обсуждение возвращаемых значений против исключений.

Искал, неполучилось — незнаю волшебных слов ...

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

_>Кто как к этому относится? обсудим?
ИМХО весьма сомнительное занятие. Да еще и как я понимаю на багланд дебилдере пишешь? Если да то учти что он и на ровном месте либит глючить, а тут исключения для обработки логики

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

_>Кто как к этому относится? обсудим?


Подумай еще о других. Такой код будет сложнее понимать другим.
Уж если хочешь быстро заткнуть дыру в проекте,
то лучше заведи какой-нибудь глобальный объект,
сделай их него сингелтон и работай с ним.
Потом, будет время, сделаешь redesign и все встанет на свои места.

У меня есть опыт работы с кодом, где как раз вполне нормальная
информация о состоянии физического девайса передавалась с помощью исключений.
В этом коде были и нормальные исключения.
Поддерживать такой код было занятием не очень приятным.

В общем не стоит настольными часами колоть орехи.
Для этого есть специальные щипцы...

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

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

_>>Кто как к этому относится? обсудим?


B>Подумай еще о других. Такой код будет сложнее понимать другим.
B>Уж если хочешь быстро заткнуть дыру в проекте,
B>то лучше заведи какой-нибудь глобальный объект,
B>сделай их него сингелтон и работай с ним.
B>Потом, будет время, сделаешь redesign и все встанет на свои места.

B>У меня есть опыт работы с кодом, где как раз вполне нормальная
B>информация о состоянии физического девайса передавалась с помощью исключений.
B>В этом коде были и нормальные исключения.
B>Поддерживать такой код было занятием не очень приятным.

B>В общем не стоит настольными часами колоть орехи.
B>Для этого есть специальные щипцы...
Против опыта не попрешь. Будем колоть орехи щипцами

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

По сути (и для компилятора в частности) мало разницы между

throw result;
и
return result;

Только первое приеняется для `выхода` из try-catch блока, второе — из функции.
Но у каждого подхода уже есть своё предназначение.

Предложение использовать throw для возвращения результата равносильно предложению использовать return для выталкивания исключительной ситуации.
Хотя, на мой взгляд, возможны ситуации, когда такой подход (throw result) — будет удобен. Ведь отличие `исключения` от `результата работы` — существует только в понимании программера...

тьфу Это надо в "Философия программирования" отправить

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

C>...отличие `исключения` от `результата работы` — существует только в понимании программера...

Согласен.
И именно по этой причине не надо использовать throw для передачи данных.
Иначе дополнительные проблемы с пониманием обеспечены.

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

_>

_>// псевдокод
_>try{
_>     запрос_данных();
_>} catch(данные& d)
_>{
_>    обработка(d);
_>}
_>return NULL;
_>

_>Единственно гложет сомнение, насколько все будет устойчиво работь, исключения обычно вызываются в исключительных ситуациях , что будет если они станут регулярным явлением. Единственый минус который пока нашел — можно ппопасть во вложенное исключение.


если говорить о win32, то
_EXCEPTION_RECORD содержит указатель (ExceptionRecord) на _EXCEPTION_RECORD другого необработанного исключения, это как раз для случая вложенных исключений.

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

_>Преветствую

_>Идея возникла когда нужно было получить информацию из глубины дерева объектов. Информация была не типичной и в проекте не была запланирована. Переделовать код было очень обломно. Попробовал передать инфу через механизм исключений. Чесно скажу методика мне понравилась, можно без особых напрягов передавать результирующие данные даже используя те наработанные методы в которых данная операция не заложена, и самое гланое не нужно знать как, где и каким образом результирующие данные получены

_>

_>// псевдокод
_>try{
_>     запрос_данных();
_>} catch(данные& d)
_>{
_>    обработка(d);
_>}
_>return NULL;
_>

_>Единственно гложет сомнение, насколько все будет устойчиво работь, исключения обычно вызываются в исключительных ситуациях , что будет если они станут регулярным явлением. Единственый минус который пока нашел — можно ппопасть во вложенное исключение.
_>Кто как к этому относится? обсудим?
++++++++++++!!!!!!!!!!!!!!!!!!!!!!!!
Мне аналогичная идея пришла о конечном автомате: состояния — это секции-ловушки, а throw — это функция перехода. Вообще обработка исключений — это более широкое понятие — программирование на основе событий. Так что не слушай никого — можно и таким образом прекрасно использовать механизм исключений. Естественно, надо отследить эффективность, но если не критично — тогда why not?
Еще что надо отследить вызовы деструкторов — тут надо подходить тщательнЕе, как говорил Жванецкий.

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

SDB>>Механизм исключений должен использоваться только для того, для чего он предназначен — для обработки ошибок... (с) доктор Страуструп

A>абсолютно согласен!!!
Абсолютно не согласен! Если б так рассуждали о шаблонах, обощенное программирование было бы до сих пор неизвестно! Механизм исключений можно понимать в более широком смысле — как механизм обработки событий!

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

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

C>>...отличие `исключения` от `результата работы` — существует только в понимании программера...

B>Согласен.
B>И именно по этой причине не надо использовать throw для передачи данных.
B>Иначе дополнительные проблемы с пониманием обеспечены.
Ну почему? Можно ведь вместо понятия" исключение" пользоваться понятием "событие". Тогда с пониманием все в порядке: throw — генерация события, а секции-ловущки — реакция на события.

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

LVV>Мне аналогичная идея пришла о конечном автомате: состояния — это секции-ловушки, а throw — это функция перехода. Вообще обработка исключений — это более широкое понятие — программирование на основе событий. Так что не слушай никого — можно и таким образом прекрасно использовать механизм исключений. Естественно, надо отследить эффективность, но если не критично — тогда why not?
LVV>Еще что надо отследить вызовы деструкторов — тут надо подходить тщательнЕе, как говорил Жванецкий.

Ну ну...
Искреннее желаю вам поработать на одном проекте с таким вот "новатором"
Чем стандартная реализация автомата не устраивает?

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

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

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

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

C>>>...отличие `исключения` от `результата работы` — существует только в понимании программера...

B>>Согласен.
B>>И именно по этой причине не надо использовать throw для передачи данных.
B>>Иначе дополнительные проблемы с пониманием обеспечены.
LVV>Ну почему? Можно ведь вместо понятия" исключение" пользоваться понятием "событие". Тогда с пониманием все в порядке: throw — генерация события, а секции-ловущки — реакция на события.

Дак я не спорю, что так технически можно сделать.
Просто зачем, если есть тот же паттерн "Observer"...

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

_>Кто как к этому относится? обсудим?

Я работал с программой, в которой нормальный цикл выполнения был построен на исключениях, их много они происходят постоянно, но в подавляющей случае это не ошибки, а просто способ нелокальной передачи управления на несколько уровней вверх по стеку. Такую программу было очень сложно отлаживать. Скорость работы программы оставляет желать лучшего, есть предположение, что одна из причин это постоянное использование исключений. В некоторых компилятора есть достаточно существенные ошибки с обработкой исключений, так что портируемость программы не очень высока. Хотя в случае когда нужно постоянно возвращать управление на несколько уровней вверх иногда приходиться идти на использование для этой цели исключений несмотря на недостатки.

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

Модератор почикал мое сообщение ввиду его резкости... Но по причине возобновления осуждения решил его повторить (тока помягче).

Так вот давелось мне работать над проектом где использовались исключения для логики вместо условных операций. Отлаживать это приложение было очень (мягко выражаясь) сложно. Работало оно черт знает как, т.к. вместе с "предусмотренными" исключениями происходили и другие. По причине отсутсвия их обработки проявлялись они незнамо где, а могли и вообще не проявляться. Чтобы понять из-за чего происходит сбой нужно было раскрутить все приложение! А приложение было не маленькое. Плюс ко всему данный подход приводил к резкому замедлению работы приложения (но написано оно было на паскале).
В конечном итоге после долги мучений я пришел к одназначному выводу: У приложения есть фатальный недостаток и гораздо проще все переписать

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

S>Так вот давелось мне работать над проектом где использовались исключения для логики вместо условных операций. Отлаживать это приложение было очень (мягко выражаясь) сложно. Работало оно черт знает как, т.к. вместе с "предусмотренными" исключениями происходили и другие. По причине отсутсвия их обработки проявлялись они незнамо где, а могли и вообще не проявляться. Чтобы понять из-за чего происходит сбой нужно было раскрутить все приложение! А приложение было не маленькое. Плюс ко всему данный подход приводил к резкому замедлению работы приложения (но написано оно было на паскале).
S>В конечном итоге после долги мучений я пришел к одназначному выводу: У приложения есть фатальный недостаток и гораздо проще все переписать

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