Например у меня есть класс в котором хранятся числа в каком-то диапазоне. И в случае если кто-то попытается записать число вне диапазона, я хочу кинуть исключение. Как обычно принято делать: создать свой класс-исключение или кидать какое-нибудь стандартное, например out_of_range? 

Dray, ну ты можешь просто кинуть исключение throw "Error", можешь не создавать класс. Но если тебе ничего не нужно, кроме надписи "Error", то класс не создавай. Если же нужно передать нечто большее, тогда создавай класс. 
PS. Блин, бред написал - исправляю 

Это сообщение отредактировал(а) XenonSk - 5.7.2006, 20:39

Dray
Если хочешь мнение, то я бы не стал возвращать в твоем случае false, 0, NULL, минимум - вернул бы enum ErrType{...}; Исключение вообще не стал бы кидать. Просто заведи в классе тот же enum ErrType{NO_ERROR=0,OUT_OF_RANGE=-100}; В каждом методе возьми за привычку(если это не void) возвращать ErrType и получишь практически "бесплатный" расширяемый класс(можешь кроме OUT_OF_RANGE и ещё что-нибудь добавить). Ибо исключение - это всё же дорогое удовольствие, может так получиться, что некий(знаю парочку   ) компилятор их не держит и тогда придется адаптировать, кроить, перепроектировать... не только код метода, но и код юзающий метод.

Добавлено @ 18:53 
Кстати, кто-нибуль тестировал на скорость обработку(+перхват) исключения и сравнивания значений двух переменных ? Что-то мне подсказывает, что второе явно быстрее.   

Это сообщение отредактировал(а) En_t_end - 5.7.2006, 18:54

En_t_end, с таким подходом проще всего писать все на чистом Си (спасибо, что не на ассемблере).


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

Void, 

Если бы в чистых Сях была бы поддержка ООП, да шаблоны, то я бы писал именно на них. Но тогда это были бы не Cи   


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

или:

Меня пугает множество фигурных скобок.
ЗЫ Скобки, скобки, скобки... вложенности, много вложенностей, они, они,идут за мной(после Макконелла я не люблю вложенности, скобки и всё что с ними связанно).

Добавлено @ 20:46 
Void, 
А вот умеет у тебя механизм отлова исключений действовать так ? 
 

Это сообщение отредактировал(а) En_t_end - 5.7.2006, 20:49

En_t_end, Но зато, если нормально продумать ... Надо будет тебе, допустим, изменить сообщение об ошибки - меняешь только в catch блоке и все. И централизация. 

XenonSk, 
что-то я не пойму, где децентрализация, при использовании перечеслений ?

Добавлено @ 20:56 
XenonSk, 
Надо мне будет изменить сообщение об ошибке я прежде всего изменю его в константных полях, а если надо заюзать новое сообщение, то изменю одну или две строчки в case блоке. 

En_t_end, ну просто, допустим, у тебя 8 методов, в которых может произойти одна и таже ошибка. По-мойму проще будет изменить в catch Одну сторку, чем там в каждом методе менять.
А централизациия - в смысле обработка ошибок в одном месте ... 

С каких пор исключения стали непереносимыми?

Не надо учить других своей ненависти к исключениям 

и тем самым заставить каждый раз при вызове метода класса проверять, что вернули????!!!!! Очень интересно. А если я забуду проверить? А если после меня кто-то будет этот код сопровождать?

Хорошо, проверил я и вижу, что мне вернули ошибку. Дальше что? Самому по этапу передавать наверх? А там проверят и дальше ошибку возвратят? Так вся программа превратится в сплошной if-else.
Исключение нужно для обработки ошибки не там, где она возникла, а там, где ее можно и нужно обработать.  
En_t_end,

ты это серьезно?
 
причем самый главный витамин в том, что throw RangeError(); совсем не обязательно кидался в class_obj.Metod(), а где-нибудь в глубинах кода, вызываемого в ней и не надо без конца проверять где и что вернулось.

XenonSk, 

это неправильно. Никогда не надо так делать даже если это работает. Всегда нужно создавать объект исключения.  

Так все таки лучше свой? 

эта моя фраза относится в первую очередь к throw "Error", а свое или нет
это от ситуации зависит. если не надо информацию передавать, а только сигнализировать, то сойдет и пустой класс


сдругой стороны учитывай как и где исключения будут обрабатываться. Если обработка для разных эксепшенов одинаковая, то может быть нет смысла для каждой ошибки генерить отдельное исключение, а использовать какое-то одно. 
Если ты хочешь в объекте исключения передавать какие-то данные и несколько, то здесь без своего класса трудно обойтись.
А бывают ситуации когда идет какая-то обработка данных и при ошибках надо просто прервать работу сообщив что где не так , тут и std::runtime_error вполне сгодится и писать что-то свое совсем не обязательно   

Fazil6, 

Ептс... конечно... видимо воображение у меня слабова-то 

Я не уверен, но в бизнес-проектах, насколько мне известно, документируют каждый метод от сих до сих. К тому же не увидеть, что  метод возвращает ErrType или тому подобную вещь, с приставкой Err - просто невозможно, бросается в глаза.
И к тому же я не говорю о том, чтобы использовать перечесление, как способ сигнализации об ошибке только в одном методе. Когда ты примешь эту концепцию во всём классе, библиотеке классов, то никаких проблем с вижу-не вижу,отлавливаю-не отлавливаю ИМХО быть не должно.
Далее... почему ты думаешь, что с исключениями дела обстоят лучше ? Человек также может не заметить, что метод может бросать некое исключение и не сделать вокруг него try{}catch()catch(...) - ТАК что тут у исключений и перечеслений одинаковые шансы на нерадивого программиста.

Они наоборот СТАЛИ переносимыми только с некоторых пор. 

в данный момент я согласен с  En_t_end, потому что считаю удобным сделать вообще в енуме NotError = 0, и когда функция выполняется делать так: 

Если же у нас исключение, то надо эту функцию обрамлять в трай сатч, что не всегда удобно.

Добавлено @ 08:31 
да, кстати, чуть не забыл:  нам ведь вообще не всегда надо обрабатывать ошибку! А если это так, то генерация исключения дороже просто ничего не делания   

En_t_end, 

у меня такое чувство, что ты слабо себе представляешь о чем дискутируешь. Кто тебе сказал, что каждую функцию, бросающую исключения обязательно надо обрамлять в try ? 
try ставится там, где будет обрабатываться ошибка, а не там где вызывается функция бросающая исключение и по объекту исключения определяется что произошло, где и как на это реагировать.

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

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

Не вижу ничего неудобного. В случае try/catch мы сразу видим, что внутри порождается исключение, а в твоём случае непонятно что возвращается. Да и кроме того, что если функции надо возвращать какие-то значения?


Не намного то и дороже.


Полностью согласен. 

это вообще детский сад какой-то. Главное удобство состоит не в том, что надо писать try (а его можно не писать здесь) а в том, что эксепшен не заставляет нас обрабатывать ошибку здесь, а код возврата заставляет именно здесь. Как наверх передать, что функция не отработала? Эксепшеном? так почему было сразу не кинуть throw? Вернуть отсюда опять код ошибки и там обработать? а там вернут опять код ошибки и опять будут проверять и возвращать?

А если твоя Func() вызывает функции, которые вызывают другие функции, которые вызывают еще функции, а те вызывают еще функции и т.д. и каждая может неотработать и вернуть ошибку? Каждый вызов проверять что вернули? Это дешевле? То, что Func возвращает 0 ничего не говорит о том, что произошло и где и как на это реагировать. Для того чтобы это обеспечить нужно возвращать разные коды, а это превратит твой if в мало понятный и уродливый if - else - if - .... или switch . Я как представлю, брр...

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

Эксепшены - вещь хорошая тут спорить несчем. Насчет выбора исключения я все понял, спасибо всем. 

Fazil6
Я думаю это вопрос религии. И да, действительно, я не знаю о чем говорю, потому что ни разу не встречался с более менее сложной структурно задачей. Но в мелких проектах у меня есть и перечисления и исключения, поэтому всё же я могу сравнить. Я предпочитаю перечисления("В г%вне, да не в обиде"(с))
 

Fazil6, логично говоришь... и я с тобой во многом согласен, но почему в виндовс повсюду используется GetLastError()?. А возвращает она несколько тысяч разных вариантов, наверное "неудобно" обрабатывать несколько тысяч исключений? А так ::AfxMessageBox("%d",номер ошибки);- можешь ассоциировать строку с номером. И считай все рассказал, почему и зачем ошибка.
Все надо делать в меру. 

Добавлено @ 18:03 
Fazil6, 
 ну не все здесь асы как некоторые, многие вообще здесь учатся, а потом с благодарностью также с другими начинающими делятся знанием. Да и вообще, каждый имеет право на свое мнение. Вопрос был задан, значит ответа у человека не было, после поста он обогатился усточиой позицией. Если нет противоречий - откуда ему свою позицию получить?
Как сказал 
En_t_end, и фраза хороша:   

потому как писалась она на простом C.
причем мнногие ее за эту "удобность" жутко ненавидят.


так и ты в коде вряд ли все возвращаемые значения обрабатываеш -- хорошо если десяток... 

Потому что WinAPI никакого отношения к C++ не имеет и бросать C++-исключения тоже не умеет. 

ОФФТОП...

Я думаю, если бы даже винда умела это делать, это превратилось бы в очередной бардак. 

Еще по исключениям...они кстати имеют goto-начало(Уолтер Савитч "Программирование С++")... я ещё пристально не смотрел дизассемблером, но мне кажется, если сравнить goto и try-catch в ассемблерном листинге, то можно найти много общего. И вообще, кого я читал, все пишут, что с исключениями надо обращаться внимательно и кидать их направо и налево не стоит. Вообще, как тут уже говорили - исключения, исключительно для исключительных операций, и хоть не обязательно, но программа после выброса должна завершиться.... ибо я себе просто не представляю, как после нескольких десятков(наверное в крупном проекте их будет и больше) goto-подобных переходов,программа может нормально функционировать. 

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

En_t_end, скажем так, и goto и исключения являются разновидностями continuations.

А у if и goto в ассемблерном листинге меньше общего? Тем более механизмы реализаций исключений зависят от компилятора. MSVC так вообще пользуется сервисами ОС для этого. 

если хотите, идемте в холивары. Модеры вполне могут перенести тему.

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

я скажу еще категоричнее  это совершенно другой язык программирования

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

Попробуйте подходить к разработке программы не с позиции обеспечения в первую очередь устойчивой работы, а с позиции когда программа чуть что - бросает исключение и ложится набок с криком "ошибка такая-то в такой-то строке, потому, что индекс масива меньше нуля". Как не дико это выглядит для некоторых, но после буквально первой компиляции и запуска вашей программы Вы отловите столько багов за 30 минут тестирония!!!! причем иногда в таких местах, где вам и в голову не могло прити проверить или где дебагером проблематично проверить. Это иногда называют  самотестируемое ПО. 
А теперь представьте приходит письмо от заказчика "классная программа все зае..сь, но какая-то хрень. На прошлой неделе по программе Петров отработал 2 часа, а он клянется на полный рот казявок, что 8 отработал. В прошлом месяце такаяже хрень была с Сидоровым и Ивановым. Мы их конечно послали подальше, но вчера она так насчитала генеральному тов. Л.Трубецкому. Разберитесь в чем дело. Мы же за программу Вам 100 баксов заплатили." Вот Вам прелести сопровождения...

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

Ах да! Каюсь. Грешен. Как же я мог забыть!!!!!! Ведь для отлова исключения надо писать try, а это не всегда удобно...
Про эфективность еще вспомнили... Эксепшены - это дорого. Не дороже проверок, зато надежнее 

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

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

Согласен, но выпускать такое ПО к заказчику нельзя.

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

Добавлено @ 06:58 

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

Никто не спорит, но вот само прыгания из любого места программы вызывает опасения.
 

Любая программа может и должна работать устойчиво к исключениям. И нет тут ничего эзотерического. Скажем, нужно открыть файл. Идем в меню, Open, выбираем файл, а файл... не тот. Скажем, какой-то умник переименовал tif в bmp ... Или просто в двоичном редакторе пошалил... или система упала в момент записи... И что, аварийно завершаться? Даже не смешно. Приличная программа должна сказать "вас здесь не стояло" и нормально продолжаться. 
И это относится к чему угодно: запустили проверку, ну не знаю, правописания, в набитом тексте. Что-то там не сошлось (34 буква алфавита обнаружилась, или язык внезапно стал албанским, или просто памяти не хватило, или...). Очевидно, что завершиться должна только эта конкретная функция, да так, чтобы остальная часть программы не пострадала, и можно было продолжать работу. С помощью исключений это реализовать несложно - нужно только придерживаться определенной дисциплины. А насчет использования кучи - так на то есть техника "Выделение ресурса есть инициализация", уже давно с бородой. 

       

En_t_end, 

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

En_t_end, 

как раз с исключениями проще всего

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

Какое нельзя? Тщательно протестированное? 

boost::shared_ptr
tr1::shared_ptr
std::auto_ptr

Earnest, 

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

попробую объясеить кодом.
все, наверное, знают такую "замечательную" библиотеку как WinInet
и работа с ней просто "замечательная":



а были бы в ней исключения -- все было бы просто замечательно:
 

Великолепный пример! Много раз с таким встречался и ругался на всю эту проверку ифами. В том же Direct X такая ерунда. ИМХО эксепшены конечно удобней!
За такой пример плюс. 

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