Сообщения AutoCAD: "ENTERNAL ERROR: !U:\... dbobji.cpp@5619:eNotOpenForWrite" и "Error handler re-entered. Exiting now." (Страница 2 из 4)

Хотите гнобите сколько угодно.
Кто вам не запрещает?
Но если у меня есть возможность писать то что я хочу и реализовывать это наиболе очевидным образом - то я лично от этого отказываться не собираюсь.
А отлаживать ошибки вызванные отсутвием close (а еще если работают несколько человек) вместо того чтобы проверять работу задуманого алгоритма также не собираюсь.
Все остальное сказал archimag, большое спасибо ему за это

> Сергей
Не могли ли Вы своими словами объяснить, как программировать без использования cath (особенно в .Net!!!) и почему так надо поступать?! А то, если в этой книжке действительно так написано, то мне совсем не хочется тратить на неё время
За четыре года, которые я занимаюсь программированием, благодаря рекомендациям, подчёрпнутым у таких авторов как Страуструп, Саттер, Александреску, Майерс и т.д, мне всего один раз пришлось заниматься действительно серьёзной отладкой - когда разрабатывал прогу, непосредственно управлявшую аппаратурой (классическое противостояние разработчика железа и программиста). Это может звучать как шутка, но я практически не умею пользоваться отладчиком - он мне никогда не был нужен.
А KonstantinM (при всём к нему уважению), похоже мешает его преподовательская практика. Действительно, основная масса современных студентов на удивление тупа (в чём мне пришлось недавно в очередной раз убедиться, когда мы искали ещё одного программиста). При общении с таким контингентом каких только предрасудков не наберёшься...
P.S. Книга Александреску называется не так и вряд ли вы смогли бы понять о чём она...

И еще про правило конечного автомата - ставить assert-ы, на все необрабатываемые ветки конечного автомата. ЗОЛОТОЕ ПРАВИЛО - сохраняет тонны времени, ускоряет процесс разработки, не надо думать при написании основной ветки алгоритма, что делать если что-то не так, не боятся забыть/потерять ветку конечного автомата, которую Вы сейчас не хотите реализовывать, но потом ее надо бы сделать. Короче помогает как в отладке, так и не надо делать лишнию работу.
Пример:
pObj = NULL;
МУASSERT( acdbOpenObject(..., pObj) == Acad::eOk );
МУASSERT( pObj != NULL );
Пусть pObj == NULL в силу чего-то.
Можно вернуть код ошибки... Программа обрастает кодами ошибок и все это еще надо и обработать сверху. Обычно - вернули eNotOpen и сверху забили/забыли с проверкой - типа торопимся делать основную ветку алгоритма. Ничего хорошего и куча лишней работы и проблемы с отладкой через два дня, когда вдруг прилетело eNotOpen, а оно не обработалось...
Допустим мы попотеем и кинем исключение если pObj == NULL, во-первых надо не забыть поставить сверху try catch. Т.е. получается что наша программа обрастает try catch-ами с огромной силой - и вы просто запутаетесь в огромном количестве этих обработчиков и т.п.
Второй вариант - вы впарите только лишь в одно место try catch - где-нибудь с самого верха. Типа ресурсы у Вас написаны правильно на иу и они закроются. В этом случае получаем, что если где-то полетело ваше/чужое исключение, то вы сразу попадете в catch - сверху. Теперь представьте это отлаживать... сказали F10 на функции DoVeryComplexOp() - и оказались в catch сверху. Ну просто лафа... если там не стоит бряк поинт - то программа радостно отработала и вы можете не узнать что вылетело исключение.
А ну да... люди ведь рассуждают что для этого есть LOG - файл - в каждом catch - мы поставим вывод в лог.
Теперь запускаем программу, что-то делаем. Смотрим, ой у нас в логе сообщение.
"I am in catch in mainCommand.cpp line 140 Unknown or system exception". После такого сообщения хочется плакать...
Если на все "боковые" ветки поставить assert - то если Вы работаете в дебагере, и вылетело окошко с ассертом, то кроме указания файла и сторочки и условия что не так - вы сразу можете ткнуть паузе в дебаге, посмотреть стек, посмотреть переменные и в 99% СРАЗУ понять что к этому привело и исправить ошибку или сделать корректную обработку этой ветки конечного автомата.
Типа бесплатная лекция - почему не надо строить обработку внештатных ситуаций на try - catch. try-catch - надо ставить только на перехват системных или библиотечных исключений. Если этот catch случается - то это значит баг и что-то не так. Если вы кидаете исключение чтоб быстро выйти из рекурсии(встречал такое) или вернуть код ошибки и вы пишите не библиотеку для массового использования - то, скорее всего, вы не правы.
И как резюме - самое граммотное в обработке нештатных ситуаций - это использование комбинации ASSERT - на все нештатные ветки, try catch сверху - на "не свои" исключения в идеале происходить не должен коды программа отлажена, и возвращение кодов ошибок чтобы обрабатывать нужные "запланированные" ветки конечного автомата.

> archimag
----------
Всегод один вопрос: кто и зачем придумал такую гадость, как исключения? (и почему они нашли такое широкое распространение)
тактика и стратегия использования исключений хорошо описана в литературе.
----------
Всего один ответ - "Крестянин Иван придумал Болт и ищет куда его ввернуть" - примерно так и с исключениями.
Почему Вы решили, что я ставлю знак равенства между разработкой и отладкой? Более того нежелание использовать исключения растет из тех же эгоистичных побуждений разрабатывать быстрее и проще. 1) Легче кодировать. 2) Легче отлаживать 3) С юнит тестами и ассертами проще получать надежный и оттестированный код. Что еще надо?
А относительно МНОГИХ(подавляющее большинство) приложений под акад работающих с объектами - я заметил - включаем на заморозку слои и... обычно у всех просто падает Access Violation..., у меня хотя бы летит ассерт с указанием где не так. Очень быстро найти и поправить, что было доказано на прошлой недели.

> KonstantinM
Позволю себе привести цитату ещё одного классика:
"Механизм обработки исключений предоставляет альтернативу традиционным методам в тех случаях, когда они не достаточны, не элегантны и подвержены ошибкам. Он предоставляет способ явного отделения кода обработки ошибок от «обычного кода», делая таким образом программу более читабельной и лучше подходящей для различных инструментальных средств. Механизм обработки исключений предоставляет боле регулярный способ обработки ошибок, упрощая в результате взаимодействие между отдельно написанными фрагментами кода."
(Язык программирования С++, 3-изд, Б.Страуструп, гл. 14.1)
Тот стиль программирования, который Вы пропогандируете, характерен для языка "С с классами", а не для С++.
>1) Легче кодировать.
За счёт чего??? Наоборот.
>3) С юнит тестами и ассертами проще получать
> надежный и оттестированный код
Конечно проще, но...
Во-первых, автоматически выполняемые тесты могут покрыть только очень небольшую часть проблем при программировании под Автокад.
Во-вторых, у ассертов и исключений разное предназначение. Ассерты предназначены для выявления ситуаций, которые ВООБЩЕ НИКОГДА не дожны возникать. Если срабатывает ассерт, то это свидетельствует об ошибке в логике работы программы. Помимо этого, есть большое количество ошибок, которые не могут быть устранены на этапе компиляции и которые не обязательно приводят к завершению программы. В большинстве случаев, функция в которой произошла ошибка не знает что с ней делать и должна как-то сообщить об этом на более выскокий уровень. Для этого можно возращать код ошибки или генерировать исключение. Коды ошибок часто просто очень не удобны и их проверка может удвоить размер програмы, что затрудняет разработку, усложняет отладку, сопровождение и провоцирует ошибки (нужно писать много кода, это долго и нудно).
P.S. Заморозил пару слоёв - ничего необычного не заметил

> archimag

> KonstantinM

> Сергей
"Религиозные войны - эпизод N". Как вы далеко убежали от вполне конкретного вопроса. :)

> Александр Ривилис
"Религиозные войны - эпизод N". Как вы далеко убежали от вполне конкретного вопроса. :)
Александр, :) ну что уж так сразу? Всегда получал от этого специфическое удовольствие. Возможны и мне скоро надоест этим заниматься - тем более делаю это не так часто. К тому же - когда оппоненты не спускаются к тупой полемике.
Архимаг:
Легче кодировать ПОТОМУ ЧТО:
MYASSERT( obj.open() == OK );
MYASSERT( dict->append(obj) == OK );
и т.д.
не надо думать о том, что будет если объект не откроется, если метод не выполниться, если... и т.д. - не надо писать исключения, не надо гемороится со всякими боковыми ветками, которые могут вообще никогда не случиться.
1) Просто логика программы упрощается до основной ветки, которую ты разрабатываешь. Если важно например, что объект не открылся - и надо что-то сделать корректное, то когда это случится прям при разработке, то ты это напишешь и профиксешь. В противном случае ты пишешь много кода, который обрабатывает исключения и ошибки, при этом этот код доходит до пользователя ни разу не быв исполненным и там запросто могут быть "описки" и баги.
2) Наличие кучи ассертов - это сравнимо с контрольными точками с диагностикой. Т.е. простым и дешовым способом навешиваются прямо при кодировании датчики что твой код исполняется как надо. И при работе программы если что-то пойдет не так то датчик сработает мгновенно по факту. Навешать такое кол-во исключений - это ж блин... я пытался...
3) MYASSERT - это не поганый майкрософтовский ассерт. Первое он работает и в дебаге и в релизе. Второе он показывает табличку что где-то что-то не так и дальше может кинуть то же самое исключение.
Эта вешь обсуждалась многократно - сразу отвечу на контрдоводы - 1) Критична производительность, а у Вас на каждую феньку навешан ассерт. 2) Критично что я работаю, а мне бац и вылетела табличка - все встало и ждет...
Для этих целей ассерт может быть настраиваемым. Т.е. в настройках программы можно настроить - исполнять ли CRITICALASSERT, показывать ли табличку пользователю - либо кинуть эксепшен, молча обработать его, если важна работоспособность и устойчивость программы во времени, ну и записать инфу в лог файл вместо того чтобы вывести это на экран.
Отмечу что для Автокадовских приложений пункт ни один и не два - не актуально.
И еще - Архимаг - твои мысли идентичны моим - три года назад. Поэтому я их ОЧЕНЬ хорошо понимаю. Я тоже наплевал на один ретерн из метода, когда ресурсы освобождаются в деструкторах. Сейчас в коде у меня у самого есть места где стоит по нескольку ретернов и дай бог что работает, но когда в методе появляется >=2 ретернов, то это верный знак что метод надо рефакторить.
И еще - что думают классики по каим-то вопросам я сам читал. Посему цитатами меня не напугать - у них там "наверху" споры не меньше наших. Гораздо интересней знать и видеть что думает сам человек и как это обосновывает не прибегая к банальному цитированию. Цитирование - это штамп, который вбивает в голову аксиому и человек перестает задумываться над проблематикой самостоятельно. У тебя же, архимаг, котелок неплохо варит. :) Прочитай что-нибудь по XProgramming - только осторожно, там религии тоже больше чем сути.

Неужели это так плохо как Вы говорите?
Если сравнить следующие куски кода:

if(){
    if(){
        if(){
        }
    }else
    {
    }
}

if(!) return;
if(!) return;
if(!) return
else

То как по мне второй читать намного легче первого. Где я програмирую естесвенный (оптимистически) поток событий. Все неудачи тут же прерывают этот поток и возвращают код ошибки или просто false.
получается легко и просто, а совместно с ИУ надежно. При этом заметьте - исключения не используются. Но в верхнеуровневых функциях как правило использую подобие Вашего assert работающего и в  release

> KonstantinM
Мне не понравился последний пример. А что, если я не хочу в этой функции перехватывать никаких исключений? Обычно я перехватываю их на самых верхних эшелонах, потому как, обычная функция просто не знает что с ними делать. Есть тысячи причин, по которым во время выполнения функции может возбудиться исключение: его может кинуть мой код, его может кинуть какая-нибудь библиотека (а я стараюсь активно пользоваться сторонними библиотеками). Возможен, конечно, такой вариант:

try {
    // какой-то рабочий код
}
catch (...) {
   // очистка ресурсов
   throw;
}

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

> KonstantinM
И до чего мы договорились?
Похоже, что хватит... Пожалуй, подытожу всё ещё одной цитатой
"Ничто не заменит ума, опыта и хорошего вкуса" (Б.Стауструп)

> VVV
>VVV Спасибо. В сущности, я сообщил Сергею в чем была проблема, которая вызвала подобное сообщения AutoCAD. У меня это произошло первый раз. Мне кажется, что уловить связь между выэовом чистой виртуальной функции
и незакрытым объектом, непросто. Почему бы не сообщить что какой-то объект не закрыт? Вообще Autodesk создав такую приличную библиотеку как ObjectARX, не дала инструментов для работы с ней. Почему бы не создать спец. надстройку к дибагеру, создать нечто подобное Intellsence и т.д. Инструкций по технике программирования, описание и толкование сообщений. Каждый выкручивается как может. Вся эта дискуссия, это обсуждение способов как обойти все эти проблемы всеми известными способами. У каждого свой рецепт. У всех золотые головы. А почему бы не придумать небольшую надстройку над VC? И утереть нос Autodesk?