onstat- White Owl
Ну если это правильно и клево, покажи мне реальную задачу решеную через исключения и чтоб это решение было удобнее чем решение через коды возврата. Вот man_555 очень любит исключения, но показать такую реальную задачу не смог. Может ты сможешь?
Как вариант:
Выход из тупиков и бесконечных циклов при обработке графов.Не годится. После натыкания на тупик надо обязательно проверить братские проходы. А значит каждый раз при шаге назад надо будет проверять был ли там тупик. А это можно с легкостью делать и на кодах возврата.

MasterZivCTResults &rs = query.getResults();

for(size_t i =0; i < rs[0].NRows(); ++i) {
const CTRow &row = rs[0] ;

// Здесь чисто теоретически могут возникать exceptopns
// если в наборе данных нет полей с названиями "name", "age" или "gender".
// Но в отлаженном коде такого быть не может. А если такое случается,
// надо вылететь на фиг и ничего не делать.

std::cout << "Name:" << row["name"] << " "
<< "Age: " << row["age"] << " "
<< "Gender:" << row["gender"] << std::endl;
} Поясни пожалуйста, что значит "вылететь на фиг и ничего не делать"? Для вылета нафиг вообще никакая обработка ошибок не нужна :)


MasterZiv> Бррр.. Ну что значит "не писать код обработки ошибок"? Ты в любом случае
> будешь писать код обработки ошибки или код обработки исключения. В чем
> разница то?
Я БУДУ ПИСАТЬ ЕГО ОДИН РАЗ !! А не в каждой функции в стеке вызовов.
В этом разница.Еще раз "бррр". А почему ты решил что я буду что-то там писать в каждой функции??? Вон в приведеном примере, когда я определяю оператор [] для резалтсета, я предпочту не бросать исключение, а возвращать указатель на пустую строку. Тогда, даже если злодей пойдет и переименует поле gender в поле sex - я все равно получу список name-age с пустотой вместо gender. А в твоем варианте обращение к row["gender"] вызовет полный аборт всей процедуры и ты не получишь вообще ничего. А я хотя бы часть данных увижу.

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

blindedС исключениями жизнь проще и веселее, чем без них. Хотя бы потому что исключение может нести в себе гораздо больше информации об ошибке, нежели просто код возврата. Контекст в котором произошла ошибка - вот чего зачастую не хватало при обработки ошибки. Если вспомнить былые времена, то сколько сил уходило на написание всяческих отладочных вызовов с записью в системные логи или самописные debug файлы, причем этими вызовами была пронизана вся программаюЭто очень убедительное утверждение, до тех пор пока не задумаешься, а кто именно и где заполняет исключение этим самым контекстом.

MasterZivПример раз :
Программа - консольное приложение, которое должно сформировать и отправить
электронное письмо. Если что-то не так, например, одно из полей отсутствует,
приложение должно завершиться с ошибкой. Бросается исключение, оно ловится
в main, выводится сообщение об ошибке, завершается приложение.Точно так же, только вместо throw используем return. Решение ничем кроме синтаксиса не отличается.

MasterZivПример два.
Программа - GUI -приложение, форма для редактирования данных. На форме есть кнопка "Расчитать", при нажатии на нее производится определенное вычисление. Если что-то не так - нет полей - вычисление производить невозможно. Значение, получаемое в ходе вычисления, неопределено. Исключение ловится во фрейме, обрамляющем обработку сообщения, обрабатывается соотв. образом (выводится сообщ. об ошибке) и программа не выполняет действия "Расчет". Приложение при этом может продолжать работать дальше в части, не касающейся этого, а после устранения проблемы - может работать нормально и здесь.Опять таки, функция расчета может делать throw, может делать return errormessage. Разница чисто синтаксическая.


MasterZiv1) Там возвращается не указатель, а ссылка.
2) Возврат специального значения в случае ошибки - плохой подход.
3) Тобой описывается другая семантика работы функции.
И такая, и такая функция могут существовать, причем вместе.
Для одной исключения не нужны, для другой - нужны.1) в данном случае это не важно
2) Почему плохой? Да, это не всегда возможно, но в большинстве случаев вполне возможно и запросто.
3) Конечно другая, мы ж о том и говорим какой из подходов удобнее :) Но вот если одновременно существуют два варианта функции: возвращающая код ошибки или бросающая исключение - вот это уже будет плохо. Запутаться будет легко.


MasterZivИ ты думаешь, что это хорошо? Я вообще не знаю, что такое "часть данных".
Вот например, есть у тебя банковский атрибут. Но без БИК. Это все
равно что его бы и не было вообще. Так что либо все, либо ничего.Да, я думаю что это хорошо. Если я знаю что без БИК запись быть не может - я во первых запрещу такие записи хранить в БД :) А во вторых, если по каким-то причинам я не могу поправить структуру БД, я могу уже на клиенте делать специальную проверку на заполненность поля "БИК" и обламывать вывод с соответствующей диагностикой.
А если речь идет о вспомогательной таблице, ну хотя бы - контактное лицо для этого банковского аттрибута - там поле gender вполне может быть а может и не быть. Но обламывать показ список всех клиентов только из-за того что какому-то из главбухов забыли указать пол? Или как я уже предполагал поле пола переименовали. Есть информация важная, есть второстепенная. Важную - ты всегда будешь специально проверять (и не по одному разу) а второстепенную можно отдать на откуп общему обработчику ошибок. Выдача пустого результата здесь на мой взгляд более подходит чем глобальный облом.


MasterZivВ общем, все, к чему ты призываешь - неправильно, нельзя так писать программы. Если ошибка есть, ее нельзя частично игнорировать. Бывают конечно исключения, но ...
В общем-то не нравятся тебе исключения - ради бога, не используй. Твои программы, тебе их потом поддерживать. Ну почемуж неправильно? Оглянись вокруг - сколько программ написано на языках не имеющих механизма исключений вообще. И ведь работают! И поддерживаются эти программы. Или вы на таких языках в принципе не пишите? :)

blindedНе всетаки есть места где гораздо удобнее с исключениямиюВот в том то и дело, что я не знаю таких мест.

blindedНу ведь согласисьНе соглашусь.
blinded const T& read(); // Ну а ежели здесь вернут ссылку на NULL объект для пустого стека, ну совсем фиПочему же "фи"? Вполне нормально. Во первых, для стека с объектами NULL это очень хороший индикатор "нет объекта", во вторых для стека с числами возвращать ноль из пустого стека это традиция овеяная десятилетиями.

roman10
// С исключениями
// Для этого вокруг всех методов пишем обертки вида:Угу... И писание оберток вокруг всех методов уменьшает количество писанины?