[ещё c++] исключения

Мы считаем твой вопрос мутным и плохо сформулированным.

Смотрю на свой код и думаю: а не стоит ли добавить немного исключений?

Обычно думают о том, что бы еще убрать...

Вы хотите сделать что-то вроде питоновского EAFP (http://docs.python.org/glossary.html)?

Ой ли?

В методах assert (asID (id));

Ой ли?

Oh YES!

что-то нифига не понял.

Пост мой читали? )
eafp:

This common Python coding style assumes the existence of valid keys
or attributes and catches exceptions if the assumption proves false.
This clean and fast style is characterized by the presence of many
try and except statements.

у меня:

все, что указывается в кач-ве арг-ов, должно быть проверено выше
В main() присутствует catch(...), который в случае неуспеха выводит сообщение о неизвестной ошибке.

У меня вот так работает:
http://docs.python.org/glossary.html#term-lbyl

Look before you leap. This coding style explicitly tests for
pre-conditions before making calls or lookups. This style contrasts
with the EAFP approach and is characterized by the presence of many
if statements.

kermzyxer

Смотрю на свой код и думаю: а не стоит ли добавить немного исключений?

Не стоит добавлять что-либо по причине что «это есть в языке».

Больше исключений, хороших и разных!

Я же не просто так, я о надежности пекусь. Еще раз все просмотрел, все же ваиант после "--------------- ..." неплох.

тормозов добавить захотелось?

а не стоит ли добавить

Сейчас все работает

эээ...

тормозов добавить захотелось?

с чего тормоза?

[с++] .hpp
после этого можете делать все что угодно, там 100% говнокодер детектед

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

да, в таких делах недооценивать нельзя

Рекомендую почитать Стива Макконнелла. Хотя бы главу про обработку исключений (8.4). Я думаю, что после прочтения этой короткой главы все вопросы отпадут.

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

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

все, что указывается в кач-ве арг-ов, должно быть проверено

Проверки возможно ошибочного использования делаются внутри функций с помощью assert'ов. Смотри BOOST_ASSERT например. В debug сборке они выполняются, в release вырезаются компилятором. Исключения, они для исключительных ситуаций. Что считать исключительной ситуацией - тема отдельного холивора.

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

А чего стоят т.н. исключения в системах с поддержкой рестартов, без раскрутки стека, ммм! :3

в системах с поддержкой рестартов, без раскрутки стека

можно об этой штуке поконкретнее? :3

http://pcl.catap.ru/doku.php?id=pcl:обработкаисключений

Ещё один укурок.

Исключения могут пригодиться, например, в конструкторе.

Если ты уже обрабатываешь ошибки, какой смысл переделывать обработку ошибок?

смысл переделывать обработку ошибок?

Я об этом и не говорил.

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

Исключения могут пригодиться, например, в конструкторе.

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

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

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

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

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

а конструктор будет состоять из вызова этого отдельного метода?

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

И что он по-твоему должен делать, когда ничего не удалось?

«Он» - конструктор? Ничего, очевидно, раз он не вызывает этот метод.

И как это должно быть обработано наверху?

«Это» - фейл конструктора вызвать метод? Опять-таки никак, раз конструктор не вызывает метод.

А что предлагаешь делать, если файла нет на месте? Сообщить юзеру, и ждать, пока нажмёт на кнопочку «Повторить»? А если не гуёвое приложение.

потому что это медленно, йогурт

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

и небезопасно

Вполне безопасно, если писать эксепшон-сейф код

а зачем тогда конструктор вообще нужен, если он ничего делать не будет?

Кто сказал ничего? Он не будет делать ничего опасного.
Если я создаю объект, то я хочу быть уверен, что я всегда его могу создать.
Покажи мне пример, когда конструктору ну обязательно нужно кидать исключения.

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

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

Да со вы такое говогите

Так и скажи, что ниасилил.

catch(...) - в любом случае зло, и его следует избегать.

В общем случае, добавление исключений в legacy code может оказаться весьма нетривиальной задачей. Читай Exceptional C++ и More exceptional C++ Саттера.

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

Я предпочитаю

Мало ли что ты предпочитаешь.

Вот и поговорили.

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

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

и вы вместо исключений гоутушечки пишете небось? ))

и вы вместо исключений гоутушечки пишете небось? ))

Ифовочушечки. ^)

так неинтересно, от ифов взамен исключений вложеность блоков кода растет, а читабельность падает

Не думаю, что сильно падает читабельность. Меру конечно знать надо, на подфункции к примеру разбивать. Исключения тоже выглядят не слишком эстетично, особенно если дохрена этих try, catch. В целом исключения хорошая идея, но её реализация не всегда удачна. Когда человек видит прототип функции, он как правило видит и возвращаемое значение, на спецификацию исключений он обращает меньше внимания.

так неинтересно, от ифов взамен исключений вложеность блоков кода растет, а читабельность падает

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

p.s. «Бардак в голове» - это не к вам лично.

Будем считать, что ты слил.

Правильно сказать, что на прототип функции обращает внимание компилятор. Как там с совсем современными, сказать не могу.