Exceptions considered harmful ?

← →
guav © (2008-01-25 16:39) [0]

Странное мнение об исключениях высказано в MSDN:

Because of the nature of exception handling and the extra overhead involved, exceptions should be used only to signal the occurrence of unusual or unanticipated program events. Exception handlers should not be used to redirect the program"s normal flow of control. For example, an exception should not be thrown in cases of potential logic or user input errors, such as the overflow of an array boundary. In these cases, simply returning an error code may be simpler and more concise. Judicious use of exception handling constructs makes your program easier to maintain and your code more readable.

http://msdn2.microsoft.com/en-us/library/c0hwkhwe.aspx

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

← →
Игорь Шевченко © (2008-01-25 16:44) [1]

Правильно пишут. Exception - оно как goto. Ход выполнения программы становится неясным.

А что касается Delphi, так и вовсе неудобно, когда программная логика кодируется через Exceptions. Мало того, что среда останавливается на них, так еще и не поймешь программу сразу.

← →
clickmaker © (2008-01-25 16:48) [2]

в отдельных случаях -- очень напрягает.
Например, есть в .NET у объекта DataTableReader метод GetOrdinal.
Возвращает индекс колонки по имени.
Что он должен возвращать, если не нашел поле?
Вот и подумал сперва, что -1
Так ведь нет! Он кидает ArgumentException
нахрена...

← →
DiamondShark © (2008-01-25 16:49) [3]

Действительно странно приводить overflow of an array boundary как пример potential logic.

← →
DiamondShark © (2008-01-25 16:53) [4]

> Так ведь нет! Он кидает ArgumentException
> нахрена...

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

Встречный вопрос: нахрена пытаться интерпретировать как имя колонки непойми какую левую строку?

← →
DiamondShark © (2008-01-25 16:57) [5]

> Exception - оно как goto. Ход выполнения программы становится
> неясным.

С гото и рядом не лежало.

← →
clickmaker © (2008-01-25 17:01) [6]

> [4] DiamondShark © (25.01.08 16:53)

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

← →
DiamondShark © (2008-01-25 17:20) [7]

> раз Get, значит, мы что-то от него должны получить по-любому

Давай продолжим твою логику.
Раз GetOrdinal, значит получить мы должны именно индекс колонки. Иначе чего это написано GetOrdinal, а не GetAnyStinkyInteger?
А раз именно индекс, то мы смело можем использовать его, скажем, в Items[].
Ну и далее, конечно. Items[GetOrdinal("@#$%@#$")] должен пуп порвать, но вернуть итем, который, конечно же, должен преспокойно отнестись к Items[GetOrdinal("@#$%@#$")].Value = 123

Скажешь: "Не доходи до маразма"?
Полностью согласен. Маразм начинается в тот момент, когда смешивают две разные сущности: "Индекс итема" и "Код завершения метода".

← →
Семеныч (2008-01-25 17:31) [8]

Объявляю класс EUserInputException и при неправильном вводе спокойно его возбуждаю. Все вполне прозрачно и удобно.

← →
clickmaker © (2008-01-25 17:41) [9]

> [7] DiamondShark © (25.01.08 17:20)

ок. А почему тогда DataColumnCollection.IndexOf возвращает -1 при неудаче?
ведь по логике - методы равнозначны

← →
DiamondShark © (2008-01-25 18:15) [10]

> clickmaker © (25.01.08 17:41) [9]
>
> ок. А почему тогда DataColumnCollection.IndexOf возвращает
> -1 при неудаче?

Потому что есть соглашения об абстрактной коллекции, где сказано возвращать -1, если объекта нет. Почему в абстракной коллекции сделано так, я не знаю. Честно. Тем более, что есть bool Contains().
Могу только предположить, что по соображениям эффективности. Конструкция вида:
if (collection.Contains(item))
{
i = collection.IndexOf(item);
...
}
приведёт к двойному просмотру коллекции.
А может, всё теже соображения о potential logic. Всё-таки, для абстрактной коллекции поиск неизвестно каких объектов более вероятный сценарий, чем поиск колонок по отбалды сформированным именам.

← →
Галинка © (2008-01-25 18:36) [11]

Читала статью Реймонда Чена на этй тему. Интересно.

← →
ketmar © (2008-01-25 18:53) [12]

чуть-чуть оффтоп:
я так радовался, что в Component Pascal нет исключений… а писать иногда приходится на OO2C, где исключения есть. и если бы они просто были… нет, их стандартная библиотека, зараза, использует.

← →
Kolan © (2008-01-25 19:29) [13]

> Правильно пишут.

Что скажите по поводу рефакторинга Replace Error Code with Exception?

← →
ketmar © (2008-01-25 19:43) [14]

>[13] Kolan©(25.01.08 19:29)
а что тут говорить? меняем шило на мыло. всё применимо, если с умом. хотя я бы не стал так менять. лучше пусть все низкоуровневики возвращают код ошибки, а над ними навёрнут предметный слой, который уже может кидаться исключениями.

← →
Черный Шаман (2008-01-25 19:49) [15]

> guav © (25.01.08 16:39)
>
> Странное мнение об исключениях высказано в MSDN:
>
> Because of the nature of exception handling and the extra
> overhead involved, exceptions should be used only to signal
> the occurrence of unusual or unanticipated program events.
> Exception handlers should not be used to redirect the program"s
> normal flow of control. For example, an exception should
> not be thrown in cases of potential logic or user input
> errors, such as the overflow of an array boundary. In these
> cases, simply returning an error code may be simpler and
> more concise. Judicious use of exception handling constructs
> makes your program easier to maintain and your code more
> readable.
>
> http://msdn2.microsoft.com/en-us/library/c0hwkhwe.aspx
>
> У меня противоположное мнение. Исключения - наиболее удачная
> защита от выходов за диапазоны массива и неверного ввода.
>
> Интересно мнение других. Считаете ли вы эту рекомендацию
> неправильной или правильной (для большинства случаев) ?

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

← →
Kolan © (2008-01-25 19:51) [16]

Есть еще такой подход, когда слои должны заменять эксепшены ниже стоящих слоев на свои&#133
Имхо, Exceptions can not be considered to be harmful&#133

← →
Kolan © (2008-01-25 19:53) [17]

Кроме того Exception  это объект, что гораздо универсальнее кода ошибки. В него и строку можно поместить и код и что угодно&#133

← →
Черный Шаман (2008-01-25 19:55) [18]

>
> guav © (25.01.08 16:39)

Хлтя если бы сделали несколько уровней исключений(256 уровней хватит), то можно было бы указывать отладки исключения какого уровня ловить. А пока только можно или полностью отключить перехват исключений отладчиком или включить.

← →
Kolan © (2008-01-25 19:58) [19]

>
> Хлтя если бы сделали несколько уровней исключений(256 уровней
> хватит),

Непонял, а наследование не спасет отца русской демократии?

← →
Черный Шаман (2008-01-25 20:02) [20]

> Kolan © (25.01.08 19:58) [19]
>
> >
> > Хлтя если бы сделали несколько уровней исключений(256
> уровней
> > хватит),
>
> Непонял, а наследование не спасет отца русской демократии?

И как в Delphi можно задать остановку программы при отладке только по затребованным типам исключений(и их наследников)? Пока можно только задавать игнорируемые исключения. Тоесть явное неудобство.

Или баг сети(нет доступа к серверу в Indy) это баг программы?

← →
DiamondShark © (2008-01-25 20:03) [21]

> А пока только можно или полностью отключить перехват исключений
> отладчиком или включить.

Они, вообще-то, по классам отключаются. Что гораздо удобнее, чем уровни: можно целыми ветками иерархии оперировать. Хочешь -- отфильтровал исключения ввода-вывода, хочешь -- исключения БД.

← →
DiamondShark © (2008-01-25 20:06) [22]

А вообще, чего только не considered harmful.
И наследование объявляли, и ООП вообще, и гото, и циклы...

← →
Kolan © (2008-01-25 20:14) [23]

> Или баг сети(нет доступа к серверу в Indy) это баг программы?

Что за сравнение баг = эксепшен?

← →
ketmar © (2008-01-25 20:20) [24]

>[23] Kolan©(25.01.08 20:14)
>Что за сравнение баг = эксепшен?
а разве не так? что коды ошибок не обрабатывают, что исключения. фиг ли разницы.

← →
Черный Шаман (2008-01-25 20:21) [25]

> Kolan © (25.01.08 20:14) [23]
>
> > Или баг сети(нет доступа к серверу в Indy) это баг программы?
>
> Что за сравнение баг = эксепшен?

Екзепшен должен кидаться только при наличии бага.

← →
DiamondShark © (2008-01-25 20:22) [26]

> Что за сравнение баг = эксепшен?

Так до сих пор полно людей, которые уверены, что исключения -- это такой удобный способ для подавления Access Violation.
Серьёзно.
Я даже в какой-то книжке по дельфи то-ли 2, то-ли 3 видел рассуждения, что механизм исключений -- замечательная находка разработчиков дельфи, позволяющая существенно повысить живучесть программы, дескать, раньше, случись чего, программа просто падала выдав страшное ругательство, а теперь такие неожиданности можно просто тихо удушить подушкой.

← →
Черный Шаман (2008-01-25 20:26) [27]

> Kolan © (25.01.08 20:14) [23]
>
> > Или баг сети(нет доступа к серверу в Indy) это баг программы?
>
>
> Что за сравнение баг = эксепшен?

И с другой стороны написать
if функция()
begin
...
end
else
logger.log(....)

или
try
функция()
...
except on E:Exception do
logger.log(...)
end;

Когда мне фиолетово что там произошло, но главное что в данном месте ошибка. Хотя второй случай удобнее, но зачем же отладчике останавливаться. Особенно если оно станет в обработчике нити, то часто Delphi приходится снимать по ресету, так как к TM оно не пустит.

← →
Kolan © (2008-01-25 20:26) [28]

> Екзепшен должен кидаться только при наличии бага.

Послание эксепшена это нормальная реакция программы.

← →
ketmar © (2008-01-25 20:26) [29]

>[27] Черный Шаман (25.01.08 20:26)
за «второй случай» надо медленно сажать на кол.

← →
ketmar © (2008-01-25 20:27) [30]

>[28] Kolan©(25.01.08 20:26)
>Послание эксепшена это нормальная реакция программы.
охренеть. сегодня не просто утро, сегодня целый день «вокруг смеха» идёт.

← →
Черный Шаман (2008-01-25 20:29) [31]

> ketmar © (25.01.08 20:26) [29]
>
> >[27] Черный Шаман (25.01.08 20:26)
> за «второй случай» надо медленно сажать на кол.

Хорошо, если нет сети, то программа должна принудительно выдавать кучу сообщений и принудительно перезагружать компьютер?

← →
Kolan © (2008-01-25 20:32) [32]

> [27] Черный Шаман (25.01.08 20:26)

Мда&#133

А если у тебя миллион функций? Будешь миллион раз писать else logger.log(&#133)?

А при работе с исключениями, можно воспользоваться OnException TApplication.

> Хотя второй случай удобнее, но зачем же отладчике останавливаться.

Ну не останавливайся.

> Особенно если оно станет в обработчике нити

Это да, тут глюк Delphi побороть можно(нормально) только логом.

> но главное что в данном месте ошибка

Главное пойми что эксепшены это не ошибки, наоборот это значит что все идет по плану. Эксепшены надо обрабатывать(в большинстве случиев), а не тупо логировать&#133

← →
Черный Шаман (2008-01-25 20:32) [33]

> ketmar © (25.01.08 20:26) [29]
>
> >[27] Черный Шаман (25.01.08 20:26)
> за «второй случай» надо медленно сажать на кол.

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

← →
Kolan © (2008-01-25 20:34) [34]

> охренеть. сегодня не просто утро, сегодня целый день «вокруг
> смеха» идёт.

Ты мне хочешь сказать, что написав
raise Exception.Create("Превед ketmar я не ошибко");
Я сделал в программе ошибку(баг)?

Действительно смешно&#133

← →
Черный Шаман (2008-01-25 20:36) [35]

> Kolan © (25.01.08 20:32) [32]
>
> > [27] Черный Шаман (25.01.08 20:26)
>
> Мда…
>
> А если у тебя миллион функций? Будешь миллион раз писать
> else logger.log(…)?

Знаешь, мне не лень, это просто code стандарт принятый у нас, который избавляет от многих бессонных ночей потом в отслеживании ошибки у конкретного пользователя. Кстати, у нас в программе есть даже 3 случая использования goto.

← →
Kolan © (2008-01-25 20:38) [36]

> это просто code стандарт принятый у нас

Только эксепшены в этом не виноваты.

> Кстати, у нас в программе есть даже 3 случая использования
> goto.

Зачет :)

← →
Черный Шаман (2008-01-25 20:38) [37]

> Ты мне хочешь сказать, что написав
> raise Exception.Create("Превед ketmar я не ошибко");

За такое нужно трахать в жопу всем отделом. Если уже кидаешь, то хоть свой наследник класс порождай.

← →
Kolan © (2008-01-25 20:47) [38]

>
> За такое нужно трахать в жопу всем отделом.

Не понял меня, да?

← →
Черный Шаман (2008-01-25 20:52) [39]

> Kolan © (25.01.08 20:47) [38]
>
> >
> > За такое нужно трахать в жопу всем отделом.
>
> Не понял меня, да?

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

Екзепшены это порочная практика, применимая в нескольких случаях, так же как и goto.

← →
ketmar © (2008-01-25 20:57) [40]

>[33] Черный Шаман (25.01.08 20:32)
думай дальше. то-то ваш код рушится.

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

>[34] Kolan©(25.01.08 20:34)
да. баг из DNA просочился в софт.

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

>[36] Kolan©(25.01.08 20:38)
вполне. если goto применён разумно. я в Си, например, частенько готой пользуюсь, и ничего. никаких проблем.

← →
Черный Шаман (2008-01-25 21:07) [41]

> ketmar © (25.01.08 20:57) [40]

Если бы вы не знали как сложно разработать программу нормально функционирующую от NT до Vista, причём 64-битной с 32-битным кодом, то редкие глюки бы вас не волновали.

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

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

← →
Игорь Шевченко © (2008-01-25 21:26) [42]

Kolan © (25.01.08 19:29) [13]

> Что скажите по поводу рефакторинга Replace Error Code with
> Exception?

Марксизм не догма, а руководство к действию.

> Послание эксепшена это нормальная реакция программы.

Чтоб тебе всю оставшуюся жизнь отлаживать чужую программу в миллион строк, написанную с этой позиции.

← →
Kolan © (2008-01-25 21:29) [43]

> помедитируй в свободное время над словами «исключительная
> ситуация».

А ты над словом баг. И тем, что «исключительная» уже значит, что ты об ней думал.

> да. баг из DNA просочился в софт.

Ага, а если убрал, то и бага нет, да? Сколько же в VCL багов, нодо все эксепшены стереть и багов не будет&#133 Моё то ДНК в порядке, а твоё?

← →
Игорь Шевченко © (2008-01-25 21:46) [44]

ketmar © (25.01.08 20:57) [40]

> если goto применён разумно. я в Си, например, частенько
> готой пользуюсь, и ничего. никаких проблем.

Всякий овощ приносит пользу, будучи употреблен надлежащим образом в надлежащее время :)

← →
Kerk © (2008-01-25 22:29) [45]

Для кетмара :)

begin select Field1 into Var1 from Table where Field2 = Var2 exception when no_data_found then Var1 := 123; end;

Тут есть эксепшн, но нет бага. Помедитируй :)

← →
Игорь Шевченко © (2008-01-25 22:58) [46]

Kerk © (25.01.08 22:29) [45]

select nvl(max(Field1),123) into var1 from table where Field2 = Var2;

? :)

← →
Kerk © (2008-01-25 23:01) [47]

> Игорь Шевченко © (25.01.08 22:58) [46]

Ага. Меня на работе заставляют использовать этот вариант
Но он мне противен, ибо поглощает ошибку too_many_rows

← →
guav © (2008-01-25 23:13) [48]

> [1] Игорь Шевченко © (25.01.08 16:44)

Я понимаю, что

> Exception handlers should not be used to redirect the program"s
> normal flow of control.

Т.е. нормальная работа - последовательное выполнение операторов. Но если файл не открылся, пользователь не ввёл данные, или ещё что-то не так, то требуется прервать нормальное выполнение программы.
"overflow of an array boundary" - это вообще ошибка в самой программе. В Delphi используются исключения в подобных случаях. Вот я и не понял какие это "unusual or unanticipated program events", если даже "overflow of an array boundary" туда не попадает.

Остановку отладчика на исключениях можно и отключить.

> [12] ketmar © (25.01.08 18:53)
> нет, их стандартная библиотека, зараза, использует.

Ну так... главное преимущество искючений перед HRESULT: "An exception cannot be ignored".

> [15] Черный Шаман (25.01.08 19:49)

> Простое правило если тебе в функцию передали запрос на объект
> массива то проверь на диапазон.

см. [7] DiamondShark © (25.01.08 17:20)
Допустим, для какого-то случая правило оказалось приемлемо, вставили проверку.
Что должна функция вернуть, если данные не проходят проверку ?
Если эта функция вызывается другой функцией (которая тоже именно функция), должна ли вызывающая функция проверять результат на значение-при-ошибке-диапазона, и что должна возвращать она тогда, другое "значение-при-ошибке-диапазона" ?
Да, конечно, если функции будут "не совсем функциями", а будут принимать var параметр, можно воспользоватся кодом типа HRESULT. но тогда "функции будут не совсем функциями".

> вставить лог для отслеживания

Для отслеживания действительно надо использовать лог. вопрос в том, как обработать ошибку.

> [22] DiamondShark © (25.01.08 20:06)
> А вообще, чего только не considered harmful.
> И наследование объявляли, и ООП вообще, и гото, и циклы...

Я понимаю, что всё названное considered harmful, но сейчас меня больше беспокоят исключения.

← →
oxffff © (2008-01-25 23:26) [49]

> guav © (25.01.08 16:39)

А чего не понятно?

-Because of the nature of exception handling and the extra overhead involved, exceptions should be used only to signal the occurrence of unusual or unanticipated program events.
-exception should not be thrown in cases of potential logic or user input errors

С чем не согласен?
Не следует злоупотреблять исключениями, но и без них нельзя обойтись.
Где написано что исключение - ЗЛО?

← →
Труп Васи Доброго © (2008-01-25 23:36) [50]

Читаю и поражаюсь - какие все умные!!!! Правда, я завидую! Какие слова вы знаете!!!
ИМХО это очередной холивар. Кому нравится - используют, кому не нравятся - не используют. Я в своих поделках стараюсь никогда не употреблять слово exception, ибо оно говорит мне что я не учёл какой то вариант развития событий, а для меня сие в раздражение.

← →
b z (2008-01-25 23:54) [51]

> clickmaker © (25.01.08 16:48) [2]
> Так ведь нет! Он кидает ArgumentException
> нахрена...

Есть предположение, что Ordinal = -1 в случае, когда сама колонка отвязана от таблицы. А вот IndexOf работает в "подвязанной" к таблице колекции. Наверное можно былобы не смотреть на это, но разработчики решии так, я так думаю.

← →
guav © (2008-01-25 23:56) [52]

> [49] oxffff © (25.01.08 23:26)

"extra overhead involved" обычно не повод для беспокойства, тем более если кидать их при "potential logic or user input errors".

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

> С чем не согласен?

С "exception should not be thrown in cases of potential logic or user input errors".

> без них нельзя обойтись.

Ну это преувеличение.
Обойтись можно и без исключений, и без наследования, и без ООП, и без goto.

← →
oxffff © (2008-01-26 00:02) [53]

> Ну это преувеличение.
> Обойтись можно и без исключений, и без наследования, и без
> ООП, и без goto.

Приведи код в студию как собираешься обходить следующие исключения
(не обращай внимания что это исключения процессора).

0 Divide Error
1 Debug Exception
2 NMI Interrupt
3 Breakpoint
4 INTO-detected Overflow
5 BOUND Range Exceeded
6 Invalid Opcode
7 Device Not Available
8 Double Fault
9 CoProcessor Segment Overrun (reserved)
10 Invalid Task State Segment
11 Segment Not Present
12 Stack Fault
13 General Protection
14 Page Fault
15 (Intel reserved. Do not use.)
16 Floating-Point Error
17 Alignment Check
18 Machine Check*
19-31 (Intel reserved. Do not use.)
32-255 Maskable Interrupts

← →
Игорь Шевченко © (2008-01-26 00:03) [54]

Kerk © (25.01.08 23:01) [47]

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

Мне лично вариант, который с NVL(MAX(...)) совершенно не читаем и неочевиден, но...короче, зараза, по строчкам :)

guav © (25.01.08 23:13) [48]

> Т.е. нормальная работа - последовательное выполнение операторов.
> Но если файл не открылся, пользователь не ввёл данные,
> или ещё что-то не так, то требуется прервать нормальное
> выполнение программы.

Безусловно, последовательное выполнение операторов. В том числе и условных. Это намек такой.

То есть, если файл не открылся, и предусмотрен набор действий по его неоткрытию, вполне подходит условный оператор.
Нормальное выполнение программы может прерываться в случае непредусмотренных алогритмом ситуаций.
Я так думаю (с)

> Остановку отладчика на исключениях можно и отключить.

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

← →
oxffff © (2008-01-26 00:07) [55]

> > С чем не согласен?
>
> С "exception should not be thrown in cases of potential
> logic or user input errors".

Генерировать исключения не следует в случаях гарантированной возможности детерминировано установить потенциальную ошибку.
И вернуть ее в качестве информативного fail результата.

← →
oxffff © (2008-01-26 00:14) [56]

> oxffff © (26.01.08 00:07) [55]
>
> > > С чем не согласен?
> >
> > С "exception should not be thrown in cases of potential
>
> > logic or user input errors".
>
>
> Генерировать исключения не следует в случаях гарантированной
> возможности детерминировано установить потенциальную ошибку.
>
> И вернуть ее в качестве информативного fail результата.

Однако никто не запрещает игнорировать это правило.
И генерировать псевдо исключения (изменяющие рабочий поток инструкций) в качестве способа передачи управления.
Однако такой способ приводит к extra overhead.

← →
guav © (2008-01-26 00:31) [57]

> [53] oxffff © (26.01.08 00:02)

Причём тут прерывание процессора ? Если речь идёт о том, что они мапятся в SEH Windows, так есть программы которые их не обрабатывают. Никак. Просто если SEH исключение из Windows попало в программу, и программа этого не ожидала, то в програме ошибка, хоть заворачивай это AV в EAccessViolation, хоть сразу падай.
А ты считаешь что при, например Invalid Opcode ты можешь предпринять разумные действия ?
Деление на нуль просто можно не допускать. Page Fault может быть допустимым, но тогда его обрабатывает система, и в своём коде я ничего не делаю.
Короче, в С без плюсов без исключений вполне неплохо обходятся.

← →
guav © (2008-01-26 00:37) [58]

> [55] oxffff © (26.01.08 00:07)

Вот кстати. Предлагается при out of bound массива вернуть fail результат.
А что если быть в этом послеовательным, и обрабатывать чтение по адресу меньше 0x10000 возвратом fail результата ?
Думаю это сильно бы увеличило время отладки программ, когда вместо AV код продолжает выполнение.

← →
guav © (2008-01-26 00:45) [59]

> [54] Игорь Шевченко © (26.01.08 00:03)

Неправильный ввод обычно означает, что запрос не может быть обработан.
Если файл не открывается, обычно это означает, что делать больше нечего.
Т.е. следует прервать выполнение кода.
При этом в процитированном в [0] предлагается вместо исключений вернуть код ошибки.
Вот я и спрашиваю, если в таких ситуациях не рекомендуются исключения то когда их применять ?
Только когда ошибка в программе ?

← →
oxffff © (2008-01-26 00:45) [60]

> ты можешь предпринять разумные действия ?

Invalid Opcode?
Floating-Point Error?

Исключение дает направление куда рыть программисту, чтобы его программа работала 24/7.

>Page Fault может быть допустимым, но тогда его обрабатывает система, и в >своём коде я ничего не делаю.

Оно не дойдет до твоего кода.

← →
oxffff © (2008-01-26 00:48) [61]

> Только когда ошибка в программе ?

Когда ты не можеть [55]. Но программа должна работать

← →
guav © (2008-01-26 00:58) [62]

> [60] oxffff © (26.01.08 00:45)

Диагностика ?
Дамп лучше делать в своём UnhandledExceptionFilter, а не в __except.

> Floating-Point Error?

Можно не допускать.
Можно отключить через Coprocessor Control Word.

> Оно не дойдет до твоего кода.

Именно.

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

И вообще это не по теме. Речь не о прерываниях процессора. а об исключениях-классах.

← →
Игорь Шевченко © (2008-01-26 01:06) [63]

guav © (26.01.08 00:45) [59]

> Неправильный ввод обычно означает, что запрос не может быть
> обработан.

И что из этого следует ?

> Если файл не открывается, обычно это означает, что делать
> больше нечего.

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

← →
Игорь Шевченко © (2008-01-26 01:09) [64]

> Вот я и спрашиваю, если в таких ситуациях не рекомендуются
> исключения то когда их применять ?

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

← →
sdts (2008-01-26 01:30) [65]

> Очевидно в исключительных ситуациях, разве нет ?

Еси смореть с позиции "С без плюсов"[57], то откуда они взялись? :)

← →
oxffff © (2008-01-26 01:41) [66]

> guav © (26.01.08 00:58) [62]
> > [60] oxffff © (26.01.08 00:45)
>
> Диагностика ?
> Дамп лучше делать в своём UnhandledExceptionFilter, а не
> в __except.
>
>
> > Floating-Point Error?
>
> Можно не допускать.
> Можно отключить через Coprocessor Control Word.
>
>
> > Оно не дойдет до твоего кода.
>
> Именно.
>
> То есть, названым исключениям в программе может быть просто
> не место.
>
> И вообще это не по теме. Речь не о прерываниях процессора.
> а об исключениях-классах.

Ну начинается.
UnhandledExceptionFilter?
Он что тебе точное место укажет, ах да адрес исключения.
Ну уж знаете более информативно перехватывать в негарантированно корректных местах. Это знаете как то более наглядно.

>отключить через Coprocessor Control Word.

То есть мы не ищем бажные места.
А зачем не подскажите?

> И вообще это не по теме. Речь не о прерываниях процессора.
> а об исключениях-классах.

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

const
ExceptMap: array[Ord(reDivByZero)..Ord(High(TRuntimeError))] of TExceptRec

И GetExceptionObject(P: PExceptionRecord): Exception;

← →
guav © (2008-01-26 02:09) [67]

> Он что тебе точное место укажет, ах да адрес исключения.

Адрес, регистры, колл стэк. Всё что надо получить можно. И по полученному дампу можно узнать гораздо больше, чем по информации из EAccessViolation.

> А вы простите что думаете классы исключения на ровном месте
> рождается.

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

← →
Черный Шаман (2008-01-26 02:19) [68]

> oxffff © (26.01.08 00:45) [60]
>
>
> > ты можешь предпринять разумные действия ?
>
>
> Invalid Opcode?
> Floating-Point Error?
>
> Исключение дает направление куда рыть программисту, чтобы
> его программа работала 24/7.

Правильно, но ИСКЛЮЧЕНИЕ = НЕУСТРАНИМЫЙ БАГ. Если исключение все же можно обработать и отреагировать, то исключение стоит заменить кодом возврата.

← →
Kerk © (2008-01-26 02:25) [69]

Исключение - это когда выполнение операции невозможно. И багу в общем случае это не равно.

← →
Kolan © (2008-01-26 08:01) [70]

> ИСКЛЮЧЕНИЕ = НЕУСТРАНИМЫЙ БАГ

Вот это баг:

function GetItem(Index: Integer): TObject; brgin Result := Items[Index]; end;

А вот это эксепшен то есть исключительная, но продуманная реакция:

function GetItem(Index: Integer): TObject; brgin if (Index >= 0) and (Index <= Count-1) then Result := Items[Index] else raise E<НужныйТип,ЧтобыШаманНеПридерался>.Create("Out of bounds."); end;

← →
Kolan © (2008-01-26 09:17) [71]

> Да. Например, тихо завершить работу, спросить, а не открыть
> ли другой файл, отформатировать диск, так как раз нет нужного
> файла  нафига такой диск сдался.
> Но это все детерминированная реакция и вполне может быть
> представлена условным оператором.

А если я пишу компонент, или еще что-то что будет использоваться где-то, то что тогда? Тоже предлагать отформатировать Це:\?

← →
Kolan © (2008-01-26 09:20) [72]

И что мне ненравится во всех этих обсуждениях, так это то, что оши все сводятся к тому, что ве решают что:
«Всякий овощ приносит пользу, будучи употреблен надлежащим образом в надлежащее время :)» © Игорь Шевченко

А это и так все знают&#133 В итоге эффекта от таких веток 0.

ЗЫ
А эта закончится чем-то вроде «Эксепшены надо применять с умом»&#133

← →
Loginov Dmitry © (2008-01-26 09:27) [73]

> А это и так все знают… В итоге эффекта от таких веток 0.

С самого начала было понятно, что ветка бестолковая.

← →
Riply © (2008-01-26 09:40) [74]

> [72] Kolan © (26.01.08 09:20)
> И что мне ненравится во всех этих обсуждениях, так это то,
> что оши все сводятся к тому, что ве решают что:
> «Всякий овощ приносит пользу, будучи употреблен надлежащим
> образом в надлежащее время :)» © Игорь Шевченко
> А это и так все знают… В итоге эффекта от таких веток 0.

> [73] Loginov Dmitry © (26.01.08 09:27)
> С самого начала было понятно, что ветка бестолковая.

Информацию можно получать не только от "резюме" сообщества,
но и из хода рассуждений и приведенных(используемых) аргументов.
Поэтому, IMHO, не стоит сразу записывать ветки в "ненужные" :)

← →
isasa © (2008-01-26 11:04) [75]

ketmar © (25.01.08 20:57) [40]

по какому праву ты ловишь ВСЕ исключения, и никому больше их не отдаёшь?

:)

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

← →
Kolan © (2008-01-26 12:00) [76]

Удалено модератором

← →
Sandman25 (2008-01-26 12:34) [77]

Мои 5 копеек.
1. Exception обязателен там, где есть необходимость прервать выполнение чего-либо (не путать с выходом из цикла). Например, если веб-сервис должен вернуть результат на основе данных из БД, а БД в дауне, то необходимо бросать Exception, а не возвращать специальный объект с особым смыслом. То есть getIndexOf(Object) вполне может вернуть -1, потому что прекращать тут нечего: задача была найти индекс, она была успешно решена. А вот getObjectWithIndex(Index) должен бросать Exception, потому что задачей было найти объект с указанным индексом, но из-за неправильного индекса пришлось выполнение задачи прекратить (например, макс. и мин. индексы хранятся в переменных, а сами данные - в БД, тогда до обращения к БД дело даже не дошло).

2. Exception обязателен там, где необходимо заставить программиста принять решение, что делать в исключительной ситуации. Но в Delphi это невозможно , а вот в java мне очень нравится, что например, если я конвертирую строку в число, я должен явно указать, что делать, если в строке не число, а не получить RuntimeException при выполнении программы.

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

4. Очень помогает вложенность Exception, то есть я могу получить от сервера один Exception, внутри которого находится другой, внутри него третий и т.д. Например, невозможно получить данные, потому что не найден объект, потому что произошла ошибка БД, потому что неверно указано наименование таблицы.

5. Exception, который содержит стек выполнения, очень полезен при разработке. То есть легче анализировать стек, чем бегать с отладчиком и смотреть, а где же был получен спец.код который указывает на ошибку.

← →
isasa © (2008-01-26 12:41) [78]

Kolan © (26.01.08 12:00) [76]
Самокритика? :)

:)
Если сам себя не похвалишь, то кто еще?

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

← →
isasa © (2008-01-26 12:47) [79]

Sandman25 (26.01.08 12:34) [77]

А может надо быть проше и люди потянутся ... :)

У тебя есть механизм. Что с ним делать, решается в данном конкретном случае, руководствуясь принятыми правилами для данного случая, местности, времени ...

Вообще - это значит никак ...

← →
isasa © (2008-01-26 12:48) [80]

ЗЫ. Я хотел сказать, что в рамках проекта желательно иметь однообразие. Но не более. Вот и все.

← →
Kolan © (2008-01-26 13:05) [81]

> У тебя есть механизм. Что с ним делать, решается в данном
> конкретном случае, руководствуясь принятыми правилами для
> данного случая, местности, времени &#133

То есть
«Всякий овощ приносит пользу, будучи употреблен надлежащим образом в надлежащее время :)» © Игорь Шевченко

:)

← →
Sandman25 (2008-01-26 13:24) [82]

isasa © (26.01.08 12:47) [79]

В Java генерируемые исключения описываются в сигнатуре метода. Если хочешь, чтобы кто-то что-то обрабатывал, так и пишешь в сигнатуре. И без обработки соответствующего исключения никто ничего даже не вызовет. а не как в Delphi: вызвал, код забыл проанализировать и пошел использовать неверные данные. Может, поэтому access violation в Java нету? :)

← →
Kolan © (2008-01-26 13:34) [83]

> 4. Очень помогает вложенность Exception, то есть я могу
> получить от сервера один Exception, внутри которого находится
> другой, внутри него третий и т.д. Например, невозможно получить
> данные, потому что не найден объект, потому что произошла
> ошибка БД, потому что неверно указано наименование таблицы.

А как это? Я незнал. Где прочесть?

← →
Sandman25 (2008-01-26 13:58) [84]

Kolan © (26.01.08 13:34) [83]

Если речь про Delphi, то нужно самому реализовывать: добавить класс TNestingException, у которого будет поле nestedException: TNestingException, а уже от этого класса наследоваться

Sandman25 (26.01.08 13:58) [84]

Не совсем понял, зачем такое ? Вот например есть Exception EDBEngineError, внутре которого находится вполне себе подробная информация о том, какая именно задница стряслась. Я к тому, что никто не мешает создать наследник класса Exception с необходимыми подробностями.

Или я чего-то не понял ?

> то нужно самому реализовывать

А, я подумал есть стандартное что-то, хелп читать стал.

Ветка не совсем бестолковая. Я убедился, что мнения сильно отличаются, и есть согласные с тем, что при potential logic or user input errors, such as the overflow of an array boundary не следует кидать исключения. Поэтому решил последовать рекомендациям не использовать исклюение для необычной, но ожидаемой ситуации.

← →
Sandman25 (2008-01-26 14:20) [88]

Игорь Шевченко © (26.01.08 14:04) [85]

Композиция позволяет решить "проблему" отсутствия множетсвенного наследования. Например, причиной отказа распределенной транзакции может быть ошибка сервера приложений, ошибка авторизации, ошибка БД и т.д. Эти классы не наследуются один от другого, поэтому и нельзя использовать наследников.

> [85] Игорь Шевченко © (26.01.08 14:04)
> Или я чего-то не понял ?

Видимо, речь идёт о Java подходе, где если TStream.Read может бросать только EReadError, то наследник TStream, читающий из БД, может кинуть только EReadError, но в этот EReadError может быть вложен и EDBEngineError.

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

Хорошо, есть свойство FileName и операция DoSmth.

procedure DoSmth; begin if FileExists(FFileName) then &#133 else raise ERequiredFileNotFoundException.Create(); end;

Как поступишь?

А. Если пишешь програму.
Б. Если пишешь компонент.

← →
Sandman25 (2008-01-26 14:39) [91]

Kolan © (26.01.08 14:34) [90]

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

Sandman25 (26.01.08 14:20) [88]

Не совсем понимаю, причем тут множественное наследование. Или перечисленные тобой ситуации должны представлять именно отдельные классы, а не, скажем, значение поля reason в классе EDistrinuteTransactionException ?

← →
Sandman25 (2008-01-26 14:50) [94]

Игорь Шевченко © (26.01.08 14:39) [92]

Как потом по этому reason узнать, что явилось причиной причины?

А множественное наследование при том, что если наследовать EDistrinuteTransactionException от EDBEngineError, то непонятно, что делать в случае ESocketError

> Я не советую писать такой компонент. Это неверно в общем
> случае.

А программу?

> [90] Kolan © (26.01.08 14:34)
> if FileExists(FFileName) then

Ну так я не делаю. В if файл может существовать, в then уже нет, это пример race condition в многозадачной среде. Можно, конечно, считать что такое редко бывает, но не в моём случае.
Если файл надо открыть, то сразу его и открыват.
Т.е.
выбор между
TFileStream.Create(FFileName, ...)
и
Handle := CreateFile(FFileName, ...)
if Handle = INVAID_HANDLE_VALUE
TFileStream.Create(Handle)

Пишу программу.

> 96] guav © (26.01.08 14:56)

Ладно, не спорю, а где код ошибки или как ты о ошибке уведомляешь(о чем собссно и ветка)?

Sandman25 (26.01.08 14:50) [94]

> Как потом по этому reason узнать, что явилось причиной причины?

Это как ?

Причина - возбуждение исключения EDistributedTransactionException, причина его возбуждения - значение поля Reason.

Какие еще причины причин нужны ?

← →
Sandman25 (2008-01-26 15:33) [99]

Игорь Шевченко © (26.01.08 15:27) [98]

То есть Вы ограничиваетесь 1 уровнем вложенности. А если я захочу узнать, в чем причина причины?

EDistributedTransactionException имел причиной EAuthorizationError, а тот имел причиной EDBEngineError. Грубо говоря - при попытке проведения транзакции не удалось проверить доступ, потому что не удалось подключиться к БД.
Парадигма простая - у любого Exception может быть причина. А может и не быть :)

Sandman25 (26.01.08 15:33) [99]

> А если я захочу узнать, в чем причина причины?

А какой в этом смысл ? Нарушается принцип объектно-ориентированного программирования: от устройства объекта не должно зависеть поведение более высоких уровней. В твоем случае у класса EDistributedTransactionException должен быть метод get_Reason, который уже сам обрабатывает всю внутреннюю кухню, но в интерфейсе этого класса тебе доступен только этот метод.

← →
Sandman25 (2008-01-26 15:55) [101]

Игорь Шевченко © (26.01.08 15:47) [100]

А я и не призываю это правило нарушать.

Есть контракт, его нельзя изменять. Не должны бросаться исключения, специфичные для реализации класса. Грубо говоря, клиенту не должны бросаться EDBEngineError , потому что завтра мы начнем хранить данные в файлах и у нас вместо EDBEngineError будут бросаться EFileNotFoundError. Этого можно добиться, заворачивая низкоуровневые исключения в высокоуровневые. То есть и клиента не надо переписывать, и никакая специфическая информация не потеряна.

Sandman25 (26.01.08 15:55) [101]

Не знаю, как в Java, но в Delphi вполне себе возможно выстроить иерархию классов исключений :) При этом клиент и не узнает, что на самом деле он обрабатывает исключение EStupidUserError, а будет обрабатывать Exception и пользоваться его методами. И знать о том, что именно EStupidUserError он может обрабатывать, ему вовсе необязательно. Все в рамках контракта.

← →
Sandman25 (2008-01-26 16:11) [103]

Игорь Шевченко © (26.01.08 16:05) [102]

В Java тоже никто не мешает объявить в контракте throws Exception и работать как в Delphi :) Но это редко будет хорошей идеей.

> [97] Kolan © (26.01.08 15:04)
> а где код ошибки или как ты о ошибке уведомляешь(о чем собссно
> и ветка)?

в случае, когда без исключения - он в GetLastError(), если он действительно интересует и от него зависит обработка, он может быть обработан в case, при этом для неожиданных кодов можно и кинуть исключение. В случае с исключением он в самом исключении.

Кстати, почему мне не нравится кидать исключения из GetLastError() кодов:
Допустим мы действительно хотим программно обработать некоторые коды, алгоритм предусматривает это.
Например, при ERROR_MORE_DATA мы удваиваем буфер и повторяем попытку, ну и допустим при ERROR_NO_ACCESS мы пытаемся получить этот самый Access.
вот код без исключений

IoCallSucceeded := DeviceIoControl(... );
if not IoCallSucceeded then
case GetLaseError() of
ERROR_MORE_DATA:
begin
...
end;
ERROR_NO_ACCESS:
begin
...
end;
else
RaiseLastOSError();
end;
end;

с исключениями вроде бы логично ему выглядеть так:
try
Win32Check(DeviceIoControl(... ));
except
on EMoreData do
begin
...
end;
on EAccessDenied do
begin
...
end;
end;

но на самом деле коды ошибки всё равно предстоит обработать:
try
Win32Check(DeviceIoControl(... ));
except
on E: EOSError do
case E.ErrorCode of
ERROR_MORE_DATA:
begin
...
end;
ERROR_NO_ACCESS:
begin
...
end;
else
raise;
end;
end;

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

>[75] isasa ©(26.01.08 11:04)
а ты и вовсе не о том говоришь.
а за ловлю всех исключений надо кастрировать тупой пилой.

>[82] Sandman25 (26.01.08 13:24)
нет. AV там нет потому, что нет указателей. а вот падение жабового софта с воплем «unhandled exception» — ситуация вполне частонаблюдаемая.

guav © (26.01.08 17:17) [104]

> с исключениями вроде бы логично ему выглядеть так:
> try
> Win32Check(DeviceIoControl(... ));
> except
> on EMoreData do
> begin
> ...
> end;
> on EAccessDenied do
> begin
> ...
> end;
> end;

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

> Именно что-то подобное я и имел в виду

Такой еод и мне ненравится&#133

> Чем и почему ?

Нечитается. Однако в коде с оброботкой кодов, эксепшен все равно есть&#133

← →
Черный Шаман (2008-01-26 22:27) [110]

> ketmar © (26.01.08 21:16) [105]
>
> >[75] isasa ©(26.01.08 11:04)
> а ты и вовсе не о том говоришь.
> а за ловлю всех исключений надо кастрировать тупой пилой.

Если ты пишеш программу, то стоит ловить все исключения на верхнем уровне и логировать.

>[110] Черный Шаман (26.01.08 22:27)
если я пишу программу, то обычно до «верхнего уровня» никто не доползает, ибо ловится там, где полагается. а если что-то доползло — делается post mortem дамп и всё схлопывается. ибо это fatal error.

← →
Черный Шаман (2008-01-27 17:46) [112]

> ketmar © (26.01.08 23:25) [111]
>
> >[110] Черный Шаман (26.01.08 22:27)
> если я пишу программу, то обычно до «верхнего уровня» никто
> не доползает, ибо ловится там, где полагается. а если что-
> то доползло — делается post mortem дамп и всё схлопывается.
> ибо это fatal error.

Если бы все так писали, то до сих пор сидели бы на DOS 10.х, но зато вылизанном и стабильном.

PS
Узнайте как часто в устройствах используется watch dog - при зависании устройства(отсутствии обращения к устройству х секунд) микросхема просто перегружает устройство.

PS2
Представим что вы пищете программу для ядерной энергетики, но тут ваш напарник в коде прописал исключение
if time then raise Exception.create("Пасхальное яйцо");
Программа упала при вытянутых стержнях - реактор рванул, вместо того чтобы залогировать ошибку и продолжить работу, пусть хоть и в аварийном режиме.

> Представим что вы пищете программу для ядерной энергетики,
> но тут ваш напарник в коде прописал исключение
> if time then raise Exception.create("Пасхальное яйцо");
> Программа упала при вытянутых стержнях - реактор рванул,
> вместо того чтобы залогировать ошибку и продолжить работу,
> пусть хоть и в аварийном режиме.

А если напарник сделает
if time then TerminateProcess(DWORD(-1), 0)
тоже будешь пытаться залоггировать? ))

> вот код без исключений
>
> IoCallSucceeded := DeviceIoControl(... );
> if not IoCallSucceeded then
> case GetLaseError() of
> ERROR_MORE_DATA:
> begin
> ...
> end;
> ERROR_NO_ACCESS:
> begin
> ...
> end;
> else
> RaiseLastOSError();
> end;
> end;

Который катастрофически некорректный.

>[112] Черный Шаман (27.01.08 17:46)
>Если бы все так писали
мне плевать, как пишут «все». многие «все» восхищаются сишарпом и вротнетом, например. я, что ли, этих недоучек наплодил?

>Узнайте как часто в устройствах используется watch dog
узнай, что мой подход никак не отменяет возможности использовать watchdog — в отличие от твоего. при этом у меня есть вся информация, чтобы разобраться, отчего оно рухнуло, а у тебя — куцый лог, по которому можно отпределить только среднюю температуру по больнице.

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

> guav © (28.01.08 09:30) [116]
> > [114] DiamondShark © (27.01.08 21:32)
> > Который катастрофически некорректный.
>
> Где ошибка ?

В ДНК.
Каков результат RaiseLastOSError после вызова GetLastError?

> [117] DiamondShark © (28.01.08 11:41)

Не вижу проблемы, даже в некоторых примерах MSDN GetLastError() опрашиваентся несколько раз.

Exceptions considered harmful ? Найти похожие ветки