Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[18.222.148.124] |
|
Страницы: (15) [1] 2 3 ... 14 15 все ( Перейти к последнему сообщению ) |
Сообщ.
#1
,
|
|
|
Вобщем тема для пользователей исключительно Цэ++
Регламент 1) Спорим обо все, что касается или должно касаться Цэ++ 2) Любые темы сводим к возможностям Цэ++ 3) Если модератор "снесет" тему из раздела Цэ++, ожидайте наплыв прогеров на васике. Лично я забью на нее. Ожидаемый профит Что и как обсуждаемое можно реализовать средствами Цэ++, что можно и нужно заменить "своими"средствами. Ньюбы, типа меня, поучаться. Профи смогут реализовать интересные идеи в жысть. Одна просьба к модерам, пресекать терки типа: - ты прогаешь на Цэ++? - нет, пока только на ассемблере - фуууу!!! как это низко ... ну естественно, если тема улетит в "корзину", внезапно пойму, возможности - такие возможности Для затравочки ... контрактное программирование В языке D это - не библиотечная часть языка. Это часть языка. Суть. Функция и метод класса могут "обещать" предсказуемое поведение на входе и выходе. В случае наследования контракты работают по принципу "или". Иными словами, если контракт базового класса не выполняется - начинает обсчитываться контракт производного класса. Из книжки Александреску: Цитата Другими словами, in-контракты комбинируются с использованием дизъюнкции в сочетании с коротким замыканием: точно один контракт должен выполниться, и контракт предка пробуется первым. Таким образом, исключается вероятность того, что контракт потомка труднее удовлетворить, чем контракт предка. С другой стороны, потомок предоставляет второй шанс пройти тест предусловия, не пройденный в первый раз. Язык Цэ++, равно как и язык D, требует "базы" - соответствия типов. Это можно считать "контрактом" высшего порядка. Далее более Ваше отношение? Будете ли вы в продакшен-коде оставлять assert-ы? Считаете ли нужным генерировать исключения а-ля ExceptionAssertIn или ExceptionAssertOut? |
Сообщ.
#2
,
|
|
|
Тема не конкретна, базара ожидается много всякого; прошу сразу двинуть сие в холивары.
|
Сообщ.
#3
,
|
|
|
Так и знал. Но надеялся
|
Сообщ.
#4
,
|
|
|
Цитата JoeUser @ Я их вообще не использую и не советую. assert() суть тяжёлое наследие детства C/C++.Будете ли вы в продакшен-коде оставлять assert-ы? M P.S. Славян, для меня желание ТС важнее, если оно не противоречит Правилам. В холивары тема переедет, если вы все в совокупности, не исключая ТС, сделаете её неудовлетворяющей Правилам. К тому же я вижу основной недостаток холиваров в том, что там не требуется тематики. JoeUser же рассчитывает на тематический спор, посему флуда попрошу воздерживаться. В целом не вижу причин не оставить пока тему здесь. |
Сообщ.
#5
,
|
|
|
Цитата Qraizer @ Понеслась! Чем вам не нравятся ассерты? Для обрабатываемых ошибок - используем исключения, для необрабатываемых - ассерты. Я их вообще не использую и не советую. assert() суть тяжёлое наследие детства C/C++. |
Сообщ.
#6
,
|
|
|
applegame, а почему для всего не использовать исключения?
Добавлено JoeUser, контракты даже предлагали включить в C++. В плане теории можно прочесть о них у Бертрана Майера, он придумал Design by contract. Но идёт все это от т.н. "троек" Хоара, чёрт знает когда описанных |
Сообщ.
#7
,
|
|
|
applegame, как бы так покороче... исключения как раз для необрабатываемых, а обрабатываемые и так обработаны.
|
Сообщ.
#8
,
|
|
|
Цитата D_KEY @ JoeUser, контракты даже предлагали включить в C++. В плане теории можно прочесть о них у Бертрана Майера, он придумал Design by contract. Но идёт все это от т.н. "троек" Хоара, чёрт знает когда описанных Пасип, бегло почитал - чуйка не подвела. По факту раздувание кода встроенными типа "тестами". Для режима отладки ниче-так, но если это все барахло останется и в продакшене, лично я строго против. Добавлено Предлагаю следующую тему "множественное наследование vs примеси" Плюсы, минусы .... |
Сообщ.
#9
,
|
|
|
Цитата Qraizer @ applegame, как бы так покороче... исключения как раз для необрабатываемых, а обрабатываемые и так обработаны. Ни разу не согласен. Для чего придумали блок кэтч? Для последующей ловли, и возможно корректной обработки исключительной ситуации, как следствие - возможного нормального исполнения программы. Ассерты же - это финиш с посмертным выбросом инфы. Так что, скорее наоборот. |
Сообщ.
#10
,
|
|
|
Цитата JoeUser @ Кто тебе мешает ассерт поймать? Ассерты же - это финиш с посмертным выбросом инфы. |
Сообщ.
#11
,
|
|
|
Цитата amk @ Цитата JoeUser @ Кто тебе мешает ассерт поймать?Ассерты же - это финиш с посмертным выбросом инфы. Это как, и главное зачем? |
Сообщ.
#12
,
|
|
|
Цитата JoeUser @ Да тем же catch'ем. Насколько помню, accept в C++ просто генерирует исключение. которое, как и любое другое можно перехватить и обработать.Это как, и главное зачем? А зачем? Так это тебе самому виднее, зачем тебе отладочную проверку перехватывать захотелось. Кстати, в релизе accept'ы не компилируются. |
Сообщ.
#13
,
|
|
|
Цитата amk @ Зачем его ловить? Ассерт следует использовать в случаях, когда возникла ошибка, которую невозможно обработать, кроме как написать предсмертную записку (в моей смерти прошу винить того-то) и совершить сепукку.Кто тебе мешает ассерт поймать? Цитата D_KEY @ Можно, конечно, и исключения использовать, но мне такой подход не нравится. Объясню на реальном примере.applegame, а почему для всего не использовать исключения? У меня в проекте с некоторой периодичностью происходит обновление неких метаданных предоставлямых третьей стороной в виде JSON-а по протоколу HTTPS. Эта третья сторона имеет дурную привычку иногда выдавать 503 ошибку или вместо JSON-а отдавать пустую страницу или внезапно в JSON-е обнаруживаются какие-то новые поля или исчезают старые. Обновление метаданных не критично, желательно, но можно и со старыми продолжать успешно работать. У меня это все завернуто в один блок try/catch, ловящий все исключения (а там их может быть несколько видов), так как мне совсем не принципиально почему обломилось обновление, то-ли HTTP-ошибки, то ли JSON-кривой или вовсе обрыв соединения. Во всех случаях информация об ошибке пишется в лог, а приложение продолжает работать как обычно. Но в том же блоке есть несколько инвариантов, которые обрабатываются именно ассертами с падением. Сначала приложение гоняется в дебаг-версии, отлавиливаются и исправляются все ассерты, после чего делаем релиз из которого уже ненужные ассерты автоматически выбрасываются. ИМХО, удобно. |
Сообщ.
#14
,
|
|
|
Ассерты нужны для тех случаев, которые в теории никогда не должны случаться, а если все-таки случились, то это 100% баг в коде и надо крэшиться с дампом. Например:
class vector { ... item& operator[](size_t index) { assert((index < m_itemCount) && "Invalid index"); return m_items[index]; } }; |
Сообщ.
#15
,
|
|
|
Цитата Pacific @ Ну совсем крэшиться, полагаю нехорошо. Надо бы перехватить, выдать вменяемое сообщение для конечного пользователя и культурно завершиться.Ассерты нужны для тех случаев, которые в теории никогда не должны случаться, а если все-таки случились, то это 100% баг в коде и надо крэшиться с дампом. Конкретно в моем случае можно крэшиться, так как конечный пользователь - это я сам |