|
|
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
Как вы относитесь к исключениям (exceptions)? С какими проблемами вы сталкивались, используя их и какие задачи с их помощью удавалось решить? В данный момент я работаю над масштабным проектом, в котором исключения запрещены идеологией. Основание для отказа от исключений - трудности с отладкой (запутывание call stack) невозможность отлова утечек памяти и т.п. Что вы думаете по этому поводу? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.02.2007, 11:43 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
selinothКак вы относитесь к исключениям (exceptions)? С какими проблемами вы сталкивались, используя их и какие задачи с их помощью удавалось решить? Исключительно положительно. Никаких проблем нет, решаемые задачи - это обработка ошибок и исключительных ситуаций. Проблемы которые могут быть - это 1) относительная медленность работы исключений (естественно только в случае throw). 2) понимание разработчиками , когда должны быть использованы исключения. А именно - когда дальнейшая работа функции НЕВОЗМОЖНА. selinoth В данный момент я работаю над масштабным проектом, в котором исключения запрещены идеологией. Основание для отказа от исключений - трудности с отладкой (запутывание call stack) невозможность отлова утечек памяти и т.п. Что вы думаете по этому поводу? Чушь собачья. Однако использование исключений в коде, который изначально не был готов к ним, может быть проблемно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.02.2007, 11:50 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
Когда то бывает удобней использовать исключения, когда то удобней обойтись без них. Всегда можно обойтись без исключений. Принципиальный отказ от исключений приводит к потенциальному не рацианальному коду. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.02.2007, 11:59 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
selinothВ данный момент я работаю над масштабным проектом, в котором исключения запрещены идеологией. Основание для отказа от исключений - трудности с отладкой (запутывание call stack) невозможность отлова утечек памяти и т.п. Что вы думаете по этому поводу? Человек, который пытается навязать такую идеологию, очевидно не компетентен в вопросах программирования С++. Постарайтесь убедить его в обратном. Опишите сложности программирования без обработки исключений вообще. Приведите статистику увеличения человеко-часов на написание кода и отладку. Желательно подкрепить эти слова конкретными цифрами (в рублях). Действует отрезвляюще. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.02.2007, 12:07 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
selinothКак вы относитесь к исключениям (exceptions)? С какими проблемами вы сталкивались, используя их и какие задачи с их помощью удавалось решить? В данный момент я работаю над масштабным проектом, в котором исключения запрещены идеологией. Основание для отказа от исключений - трудности с отладкой (запутывание call stack) невозможность отлова утечек памяти и т.п. Что вы думаете по этому поводу? Единственным достойным аргументом для запрета использования исключений является переносимость. Многие компиляторы для встроенных ОС не умеют работать с исключениями или делают это криво, например Symbian. Другим аргументом может быть "совместимость" с существующим кодом. Но и там можно писать с исключениями, главное чтобы не выпускать их в код, который их не поддерживает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.02.2007, 12:41 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
selinothОснование для отказа от исключений - трудности с отладкой (запутывание call stack) невозможность отлова утечек памяти и т.п. http://www.relisoft.com/resource/resmain.html ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.02.2007, 14:59 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
selinothКак вы относитесь к исключениям (exceptions)? С какими проблемами вы сталкивались, используя их и какие задачи с их помощью удавалось решить? В данный момент я работаю над масштабным проектом, в котором исключения запрещены идеологией. Основание для отказа от исключений - трудности с отладкой (запутывание call stack) невозможность отлова утечек памяти и т.п. Что вы думаете по этому поводу? есть такая вещь - суда...те которые ходят по рекам и морям... раньше их строили из одной большей миски ("Адльф Гитлер" вспоминаем, лежащий на дне Чёрного - возле Новороссийска)... затем стали делать корабли - секционными (дабы при катастрофе, заполнялся водой не весь корпус а только его незначитильная часть).. дык вот, ловушки исключений - именно так и можно воспринимать (как секции, увеличивающие запас плавучести Вашего кода). ОЧЕНЬ актуально, когда разработчик и клиент отделены неким НЕ нулевым расстоянием друг от друга... с уважением (круглый) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.02.2007, 15:19 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
selinothКак вы относитесь к исключениям (exceptions)? С какими проблемами вы сталкивались, используя их и какие задачи с их помощью удавалось решить? Очень положительно. По поводу задач. Если проект большой то используются везде и всегда. При наличии рекурсивных алгоритмов использую исключения даже в минимальных проектах. Используются когда на этапе разработки модуля еще не извесно будущее поведение в зависимости от ситуации. Или Если не извесно где ситуацию дешевле обрабатывать. По ходу тестирования и развития это выясняется и throw заменяется на локальный обработчик или return или пишется обработчик исклюения в нужном месте. На первом этапе разработки все потенциально убойные ситуации выбрасывают исключения. По мере формирования билда их становится все меньше и меньше. По опыту очень ускоряется процесс отладки и поиск багов и сокращается количество фич вызванных непредвиденным поведением. Если в проекте, где то уже используется assert, то использование вместо него исключений повышает удобство отладки. В классе искюлчения можно сохранить гораздо больше информации для анализа возникшей ситуации. selinoth В данный момент я работаю над масштабным проектом, в котором исключения запрещены идеологией. Основание для отказа от исключений - трудности с отладкой (запутывание call stack) невозможность отлова утечек памяти и т.п. Что вы думаете по этому поводу? По поводу стека я проблем не вижу. Он просто раскручивается до catch. По памяти и межпроцессному взамодействию, да есть, нужно внимательно подходить к вопросу дизайна. В этом есть положительный момент, при разработке дизайна тратится лишний час, зато экономится неделя при отладке. Проект дисциплинируется с самого начала. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.02.2007, 16:15 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
О! Ваня хочет сказать 1. Когда ошибку можно обработать на месте, ее нужно обрабатывать на месте. 2. Если ошибка должна обрабатываться выше, то можно из функции вернуть код ошибки или возбудить исключение. Естественно, оба способа требуют проектирования - нужно будет спроектировать иерархию исключений или прописать в документации по разработке, что означают коды ошибок. Самый явный пример - библиотека. Некоторые ошибки ее исполнения разработчики не исправляют, а возбуждают исключение или возвращают код ошибки. А прикладной программист, использующий библиотеку, дальше уже обрабатывает ошибку. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.02.2007, 17:56 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
ivan________________...прописать в документации по разработке, что означают коды ошибок... О да! Занятие, которым девелоперы себя не утруждают. Обычно вместо перечня ошибок в мануале имееи место скупая запись "...обратитесь в службу поддержки и.т.д". Впрочем, это оффтоп! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.02.2007, 18:36 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
а шо у нас со скоростью работы программ напичканых ексепшинами? Ась? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.02.2007, 19:55 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
A. Fig Leeа шо у нас со скоростью работы программ напичканых ексепшинами? Ась? А что есть проблемы со скоростью? С нынешними частотами и памятью об этом мало кто задумывается. ИХМО скорость выхода из функции по исключению приблизительно равна возврату стекового обьекта( экземпляра класса). На данном этапе развития ИТ скорость разработки, отладки и поддержки гораздо более важный критерий нежели быстродействие конечного продукта. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 10:43 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
я лично против (рабочий код всегда будет рабочим), но видел примеры, где точно не обойтись без исключений. например, есть прога, котрая пытается реализовать свою "память". причем по огранизации задачи (тз) эта память - дырявая. и сколько бы вы ни хотели. но определить по адресу, можно туда пистаь или нет нельзя. а поскольку эта память нахордиться в ОП, то при попытке записи в дыру вылетает исключение. аффтопитезь: объект либо именован, либо не существует ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 12:25 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
Aklinя лично против (рабочий код всегда будет рабочим), но видел примеры, где точно не обойтись без исключений. например, есть прога, котрая пытается реализовать свою "память". причем по огранизации задачи (тз) эта память - дырявая. и сколько бы вы ни хотели. но определить по адресу, можно туда пистаь или нет нельзя. а поскольку эта память нахордиться в ОП, то при попытке записи в дыру вылетает исключение. аффтопитезь: объект либо именован, либо не существует Если я правельно понял, про что речь, то в линухах вылетат сигнал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 12:58 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
A. Fig Leeа шо у нас со скоростью работы программ напичканых ексепшинами? Ась?ну да, есть немного. И как, заметно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 15:49 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
хотя… а что быстрее, забубенить try/catch или десять ифов для проверки возвращённого значения? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 15:50 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
maXmoхотя… а что быстрее, забубенить try/catch или десять ифов для проверки возвращённого значения? Лучше switch Который занимает 70% тела функции. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 16:38 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
maXmo A. Fig Leeа шо у нас со скоростью работы программ напичканых ексепшинами? Ась?ну да, есть немного. И как, заметно? Угу. Если писать программы для трейдинга - там каждая микросекунда на счету. Или ввобще что-нибудь реалтайм. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 18:21 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
maXmoхотя… а что быстрее, забубенить try/catch или десять ифов для проверки возвращённого значения? Ясен пень - ифы будут быстрее. Там единственное сравнение на ошибка/неошибка, потом можно и код ошибки искать, а с трай-кетч - вхождение в трай всегда будет кушать время независимо от будет ошибка или нет. Свитч особо не лучше ифа - если глянуть ассемблер. Просто выглядит приятнее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 18:24 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
Akh Aklinя лично против (рабочий код всегда будет рабочим), но видел примеры, где точно не обойтись без исключений. например, есть прога, котрая пытается реализовать свою "память". причем по огранизации задачи (тз) эта память - дырявая. и сколько бы вы ни хотели. но определить по адресу, можно туда пистаь или нет нельзя. а поскольку эта память нахордиться в ОП, то при попытке записи в дыру вылетает исключение. аффтопитезь: объект либо именован, либо не существует Если я правельно понял, про что речь, то в линухах вылетат сигнал. нет, вы поняли неправильно. я имел ввиду 1) я, собственно, против 2) есть исключительные единичные сутиации, где без исключений не обойтись. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 18:27 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
Aklinя лично против (рабочий код всегда будет рабочим), но видел примеры, где точно не обойтись без исключений. например, есть прога, котрая пытается реализовать свою "память". причем по огранизации задачи (тз) эта память - дырявая. и сколько бы вы ни хотели. но определить по адресу, можно туда пистаь или нет нельзя. а поскольку эта память нахордиться в ОП, то при попытке записи в дыру вылетает исключение. аффтопитезь: объект либо именован, либо не существует не верю. коряво написано значит. надо листы хранить выделенной памяти. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 18:37 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
А я "за", потому что когда вызывается N + 1 функция из функции N, и в N + 1 функции происходит ошибка, а обработать её хочется в самой первой, то при классическом подходе надо написать N конструкций доставляющих ошибку наверх. Используя же try/catch, это делать не придётся. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 18:46 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
man_555А я "за", потому что когда вызывается N + 1 функция из функции N, и в N + 1 функции происходит ошибка, а обработать её хочется в самой первой, то при классическом подходе надо написать N конструкций доставляющих ошибку наверх. Используя же try/catch, это делать не придётся.Да ну, глупости какие.... Во первых, большинство ошибок произошедших в функции N+1 ты будешь обрабатывать в функции N. А все необработаные просто return errorcode; и все. А во вторых, ошибки произошедшие внутри функции N+1 обычно не имеют смысла для функции N-1. Для N-1 - функция N упала с ошибкой и эта ошибка принадлежит N. Функция N-1 просто не знает о существовании функции N+1 и ее списке возможных ошибок. Есть такой принцип: инкапсуляция. К ошибкам он тоже применим. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 18:56 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
man_555а обработать её хочется в самой первой, то при классическом подходе надо написать N конструкций доставляющих ошибку наверх.точняк, передаю код ошибки из любых дебрей проги в код возврата приложения. Это надо видеть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 18:59 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
White Owl А все необработаные просто return errorcode; и все. а можно с этого места поподробнее? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 19:13 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
A. Fig Leeне верю. коряво написано значит. надо листы хранить выделенной памяти. написано нормально. новая карта памяти ложится дыряво. и там и надо. и флаги не помогут (вроде на каждуюб ячейку еще рядом флаг, читается она или нет) так, например, по тз два соседних адреса моугт быть на мегабайты друг от друга на новой карте памяти. короче, это - такое тз, где без исключений не обойтись ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 19:19 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
в дополнение: Код: plaintext 1. 2. 3. 4. 5. допустим в функции f3() происходит ошибка и она возвращает -1, а во всех остальных случаях положительное число. IMHO обработать такое классически несколько громоздко. при то же: если для получения своего значения f4() вызыает цепочку из N функций, и ошибка происходит в самой последней? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 19:33 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
Хотел высказаться, но: Ваня1. Когда ошибку можно обработать на месте, ее нужно обрабатывать на месте. 2. Если ошибка должна обрабатываться выше, то можно из функции вернуть код ошибки или возбудить исключение. Естественно, оба способа требуют проектирования - нужно будет спроектировать иерархию исключений или прописать в документации по разработке, что означают коды ошибок. Этим сказано всё. Присоединяюсь. исключения дают вам гибкость, но нужно знать где их следует применять а где нет. Бензопила удобна для валки деревьев, но по фанере выпиливать ей неудобно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 20:03 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
man_555в дополнение: Код: plaintext 1. 2. 3. man_555при то же: если для получения своего значения f4() вызыает цепочку из N функций, и ошибка происходит в самой последней?Да какая разница сколько функций в цепочке? Если я вызываю f4(), то все ошибки которые там где-то происходили и пришли ко мне - это уже ошибки исходящие из f4(). Каждая функция это "черный ящик", в него суешь параметры, из него получаешь ответ. Ошибка это тоже ответ. И в каких глубинах она произошла совершенно не важно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 20:22 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
man_555 White Owl А все необработаные просто return errorcode; и все. а можно с этого места поподробнее?А что тут объяснять? Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 20:35 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
Aklin A. Fig Leeне верю. коряво написано значит. надо листы хранить выделенной памяти. написано нормально. новая карта памяти ложится дыряво. и там и надо. и флаги не помогут (вроде на каждуюб ячейку еще рядом флаг, читается она или нет) так, например, по тз два соседних адреса моугт быть на мегабайты друг от друга на новой карте памяти. короче, это - такое тз, где без исключений не обойтись по-моему, вы говорите не о тех исключениях. То, что у Вас - ето машиной сгенерированный сигнал PageFault ну или типа того, смотря какая операционка. Ничего общего не имеет с C++ исключениями. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.02.2007, 22:48 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
A. Fig LeeУгу. Если писать программы для трейдинга - там каждая микросекунда на счету. Или ввобще что-нибудь реалтайм. Такой подход имеет место. Я-бы выделил три класса API (по целевому назначению): 1) Низкоуровневый API . Высокие требования к скорости выполнения инструкций. Инструкции - атомарны и всегда выполняются успешно. Код ошибок возвращается в специальный регистр флагов или переменную (типа errorlevel). Программист вручную проверяет результат и принимает соотв. решение. 2) Классический API . Процедуры могут прерывать своё выполнение в зависимости от состояния и возвращать результат в виде кода ошибки. Программист обязан проверить код ошибки. 3) Прикладной API . Процедуры могут прерывать выполнение и генерировать сигналы или исключения. Программист их может обрабатывать или ингорировать по усмотрению. Возможно существуют 4 и 5 уровни. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2007, 01:08 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
White Owl Спор бессмысленен, потому как это разные подходы к решению одной и той же проблемы, только exceptions всё же удобней IMHO :-) И второе, IMHO эксепшены надёжней, потому как ты никогда не можешь поручиться за чужой код. Может случиться так, что в одно пасмурное утро тебе откроется истина, и... офигеть! f4() которая до этого собственноручно была проверена на отсутствие возврата кода ошибки, теперь возвращает код ошибки, потому что за время твоего отпуска коллега X поменял её. Его часть с f4 работает, а твоя уже не совсем - как повезёт. Идем дальше. Теперь надо найти все места с f4 и воткнуть проверки. Сопровождение усложняется по-любому. Впрочем, такой стиль при написании тоже не экономит время. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2007, 10:20 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
White OwlФункция которая может вернуться с ошибкой никогда не используется в формулах. Хотя бы потому, что это бессмысленно. Батюшки! Глупости лучше говорить про себя. Попробуй вместо f4 поставить StrToFloatF из VCL или StrToInt, которая если бы не кидала эксепшн, то точно бы меняла твой результат, и париться с поиском такой ошибки я вам скажу весьма и весьма неприятно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2007, 10:25 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
mayton A. Fig LeeУгу. Если писать программы для трейдинга - там каждая микросекунда на счету. Или ввобще что-нибудь реалтайм. Такой подход имеет место. Я-бы выделил три класса API (по целевому назначению): ... Возможно существуют 4 и 5 уровни. Существуют, например <a href="http://www.objectmentor.com/resources/articles/crosscst.pdf">так</a> ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2007, 10:36 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
A. Fig Leeа шо у нас со скоростью работы программ напичканых ексепшинами? Ась? Если исключения не возникают, скорость не меняется сильно. Если исключение возникает, естественно это требует какой-то обработки. Раскрутка стека требует значительного времени : все деструкторы надо вызвать, ну и еще там много всего. Но ИСКЛЮЧЕНИЯ НЕ ВОЗНИКАЮТ ЧАСТО. Они - только для исключительных ситуаций, для ошибок. Поэтому ничего страшного нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2007, 12:25 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
Aklinнет, вы поняли неправильно. я имел ввиду 1) я, собственно, против Был один такой "против". У него 50% кода занимали обработки ошибок. Код естественно частично не работал, а часть, которая работала, достаточно серьезно замедляла работу. Тут идея в чем. lev_0 lev_1 lev_2 lev_lowest <---- error appears here. При использовании exceptions код обработки ошибок на уровнях lev_1 lev_2 чаще всего (80% ) можно выбросить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2007, 12:31 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
White Owl man_555 White Owl А все необработаные просто return errorcode; и все. а можно с этого места поподробнее?А что тут объяснять? Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. О, зашибизь код !! Были бы эксепшены, этой функции ВООБЩЕ БЫ НЕ СУЩЕСТВОВАЛО ! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2007, 12:41 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
man_555И второе, IMHO эксепшены надёжней, потому как ты никогда не можешь поручиться за чужой код. Может случиться так, что в одно пасмурное утро тебе откроется истина, и... офигеть! f4() которая до этого собственноручно была проверена на отсутствие возврата кода ошибки, теперь возвращает код ошибки, потому что за время твоего отпуска коллега X поменял её. Его часть с f4 работает, а твоя уже не совсем - как повезёт. Идем дальше. Теперь надо найти все места с f4 и воткнуть проверки.Ты считаешь что в этом случае, исключения тебя спасут? man_555Попробуй вместо f4 поставить StrToFloatF из VCL или StrToInt, которая если бы не кидала эксепшн, то точно бы меняла твой результат, и париться с поиском такой ошибки я вам скажу весьма и весьма неприятно.Какая ошибка я буду искать, простите? MasterZivО, зашибизь код !! Были бы эксепшены, этой функции ВООБЩЕ БЫ НЕ СУЩЕСТВОВАЛО !Правда? Не существовало бы? А ну-ка, откроем библию, глава 9.1.1: Угадай автора с трех попыток :)В зависимости от особой ситуации будет выполняться соответствующий обработчик. Если управление дойдет до конца операторов обработчика, следующим будет выполняться оператор, который идет после списка обработчиков: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2007, 18:07 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
White Owl man_555И второе, IMHO эксепшены надёжней, потому как ты никогда не можешь поручиться за чужой код. Может случиться так, что в одно пасмурное утро тебе откроется истина, и... офигеть! f4() которая до этого собственноручно была проверена на отсутствие возврата кода ошибки, теперь возвращает код ошибки, потому что за время твоего отпуска коллега X поменял её. Его часть с f4 работает, а твоя уже не совсем - как повезёт. Идем дальше. Теперь надо найти все места с f4 и воткнуть проверки.Ты считаешь что в этом случае, исключения тебя спасут? Считаю, что спасут. Unhandled exceptions слышал про такое? White OwlКакая ошибка я буду искать, простите? ашыбка? Какая ошибки не ищут. Напиши свою рализацию StrToInt , которая будет работать быстрей, потому что ты не пользуешься механизмом исключений. White Owl Правда? Не существовало бы? А ну-ка, откроем библию, глава 9.1.1:Угадай автора с трех попыток :) В зависимости от особой ситуации будет выполняться соответствующий обработчик. Если управление дойдет до конца операторов обработчика, следующим будет выполняться оператор, который идет после списка обработчиков: void f() { try { use_vectors(); } catch (Vector::Range) { // исправить индекс и // попробовать опять: f(); } catch (Vector::Size) { cerr << "Ошибка в конструкторе Vector::Size"; exit(99); } // сюда мы попадем, если вообще не было особых ситуаций // или после обработки особой ситуации Range } Возьми с полки пряник! Ты ни черта не понял. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2007, 22:04 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
man_555Считаю, что спасут. Unhandled exceptions слышал про такое?Слышал, слышал... Только я все равно не понимаю чем необработное исключение убежавшее за пределы твоих catch'ей и перехваченое в итоге каким-нибудь глобальным catch(AbstractException) (если не системой) лучше чем код возврата обработаный процедурой "разные другие ошибки"? man_555Напиши свою рализацию StrToInt , которая будет работать быстрей, потому что ты не пользуешься механизмом исключений.Уже написана. sscanf() называется. И она намного мощнее :) man_555Возьми с полки пряник! Ты ни черта не понял.Ну так объясни. Покажи мне два исходника один с исключениями другой без, делающие одно и тоже. И объясни почему исходник с исключениями так сильно лучше? Давай без абстракций, на конкретном реальном примере. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.02.2007, 23:12 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
White OwlНу так объясни. Покажи мне два исходника один с исключениями другой без, делающие одно и тоже. И объясни почему исходник с исключениями так сильно лучше? Давай без абстракций, на конкретном реальном примере. Думаю ты и сам в состоянии сравнить обработку ошибок, к примеру в том же StrToInt и слегка архаичном sscanf. Только возьми побольше StrToInt и столько же sscanf. White OwlТолько я все равно не понимаю чем необработное исключение убежавшее за пределы твоих catch'ей и перехваченое в итоге каким-нибудь глобальным catch(AbstractException) (если не системой) лучше чем код возврата обработаный процедурой "разные другие ошибки"? White Owl, не доверяешь электричеству? Керосин как-то привычней? Ну тогда пилите, Шура, пилите. Скажу, что в debug режиме все exceptions билдер моментально подсвечивает, в то время как ваши returns работают тихим сапом. А вообще знаешь такую игру: "испорченый телефон"? Вот например: Код: plaintext 1. 2. 3. 4. 5. Можно всё обработать в ПолучитьДанные(), но концептуально это не верно, потому как ПолучитьДанные() будет занимаеться побочным эффектом - рисованием окошка: "чувак, твой файл говно", поэтому придётся всё отдать в Отобразить(). А теперь представим, что разработчики написали, сами того не желая, испорченый телефон в попытках передать код ошибки "наверх", и Отобразить() получил совсем не тот код ошибки? Вобщем, примерно это в нескольких постах разные люди это пытались растолковать. Надеюсь теперь понятно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.02.2007, 00:30 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
man_555 White OwlНу так объясни. Покажи мне два исходника один с исключениями другой без, делающие одно и тоже. И объясни почему исходник с исключениями так сильно лучше? Давай без абстракций, на конкретном реальном примере. Думаю ты и сам в состоянии сравнить обработку ошибок, к примеру в том же StrToInt и слегка архаичном sscanf. Только возьми побольше StrToInt и столько же sscanf.То есть показать на конкретном примере преимущество исключений ты не можешь. man_555А теперь представим, что разработчики написали, сами того не желая, испорченый телефон в попытках передать код ошибки "наверх", и Отобразить() получил совсем не тот код ошибки? Вобщем, примерно это в нескольких постах разные люди это пытались растолковать. Надеюсь теперь понятно.Нет, не понятно. Да, разработчики могут написать криво и отдать наверх не тот код ошибки. Но эти же самые разработчики могут с тем же успехом написать криво и отдать наверх не то исключение. Ищи другое приемущество исключений. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.02.2007, 00:52 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
White Owl, может хватит уже? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.02.2007, 09:34 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
man_555в дополнение: Код: plaintext 1. 2. 3. 4. 5. допустим в функции f3() происходит ошибка и она возвращает -1, а во всех остальных случаях положительное число. IMHO обработать такое классически несколько громоздко. при то же: если для получения своего значения f4() вызыает цепочку из N функций, и ошибка происходит в самой последней? можно обойтись static флагом, а не строить умопомрачительные конструкции и перекладывать все на систему. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.02.2007, 13:26 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
Aklin man_555в дополнение: Код: plaintext 1. 2. 3. 4. 5. допустим в функции f3() происходит ошибка и она возвращает -1, а во всех остальных случаях положительное число. IMHO обработать такое классически несколько громоздко. при том же: если для получения своего значения f4() вызыает цепочку из N функций, и ошибка происходит в самой последней? можно обойтись static флагом, а не строить умопомрачительные конструкции и перекладывать все на систему. Ну, можно. Что дальше? Уже становится смешно, ей богу! Пора останавливать этот флейм. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.02.2007, 13:50 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
man_555White Owl, может хватит уже?Почему хватит? Ты утверждаешь что исключения это так круто, прогрессивно и замечательно. Утверждаешь что функция возвращающая код ошибки это устаревшая технология а функция прерывающая свою работу с исключением это правильная технология. Ты так считаешь? Ну так докажи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.02.2007, 17:39 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
Aklin можно обойтись static флагом, а не строить умопомрачительные конструкции и перекладывать все на систему. А если ниток больше одной? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.02.2007, 18:15 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
Изопропил Aklin можно обойтись static флагом, а не строить умопомрачительные конструкции и перекладывать все на систему. А если ниток больше одной? 1) thread local storage? 2) f(&ret); где ret - возвращаемый код ошибки ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.02.2007, 21:15 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
White Owl[quot man_555]Ты так считаешь? Ну так докажи. а попробуй доказать обратное, а? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.02.2007, 22:56 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
A. Fig Lee[quot Изопропил][quot Aklin] 2) f(&ret); где ret - возвращаемый код ошибки ? сразу видно, что человек С-шник(в хорошем смысле) - предложил указатель, а не ссылку. Теперь понятна настороженность по отношению к исключениям. Не охото менять мышление?;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.02.2007, 22:59 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
MasterZiv Раскрутка стека требует значительного времени : все деструкторы надо вызвать, ну и еще там много всего. Деструкторы работают как обычно . Я даже больше скажу, раскрутка стека на поля классов не влияет что доказывает пример: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. Или я не правильно понял, то что Вы имели ввиду. Если же исключение брошено в конструкторе , то это вообще отдельная тема , и принятие решения по поводу деструктора на компилятор возлагать тем более нельзя. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2007, 03:02 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
ИМХО, у C++ исключений есть один минус - нет стандартного механизма отлова системных ошибок (т.е. независимого от ОС). Исключения, в основном, требовались в ситуациях, когда по-другому можно было выкрутиться только через goto... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2007, 03:58 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
любитель исключений MasterZiv Раскрутка стека требует значительного времени : все деструкторы надо вызвать, ну и еще там много всего. Деструкторы работают как обычно . Я даже больше скажу, раскрутка стека на поля классов не влияет что доказывает пример: Совсем не понятно, что этим примером ты хочешь показать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2007, 09:24 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
daevaorn A. Fig Lee[quot Изопропил][quot Aklin] 2) f(&ret); где ret - возвращаемый код ошибки ? сразу видно, что человек С-шник(в хорошем смысле) - предложил указатель, а не ссылку. Теперь понятна настороженность по отношению к исключениям. Не охото менять мышление?;) Надо уметь пользоваться и тем и тем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2007, 09:44 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
daevaorn любитель исключений MasterZiv Раскрутка стека требует значительного времени : все деструкторы надо вызвать, ну и еще там много всего. Деструкторы работают как обычно . Я даже больше скажу, раскрутка стека на поля классов не влияет что доказывает пример: Совсем не понятно, что этим примером ты хочешь показать. Я хочу спросить, Где и как должен вызываться деструктор? Может не понимаю чего? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2007, 09:59 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
любитель исключенийЯ хочу спросить, Где и как должен вызываться деструктор? Может не понимаю чего? Ааа:) Вот например так: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2007, 10:08 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
daevaorn любитель исключенийЯ хочу спросить, Где и как должен вызываться деструктор? Может не понимаю чего? Ааа:) Вот например так: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. Ну так здесь он будет вызван не зависимо от того было исключение или нет. При выходе из области видимости. вот мой доработанный пример: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. Этот случай у меня сомнений не вызывал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2007, 10:18 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
любитель исключений Ну так здесь он будет вызван не зависимо от того было исключение или нет. Ну так в этом и суть, что деструктор будет вызван в любом случае. Атоматические деструкторы плюс RAII и дают ту мощь исключениям в С++, которая делает их очень удобным и полезным инструментом. Который позволяет писать более безопасный код. любитель исключений При выходе из области видимости. вот мой доработанный пример: Всё равно не понимаю суть твоего явно переусложненного примера:) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2007, 10:25 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
daevaorn любитель исключений Ну так здесь он будет вызван не зависимо от того было исключение или нет. Ну так в этом и суть, что деструктор будет вызван в любом случае. Атоматические деструкторы плюс RAII и дают ту мощь исключениям в С++, которая делает их очень удобным и полезным инструментом. Который позволяет писать более безопасный код. любитель исключений При выходе из области видимости. вот мой доработанный пример: Всё равно не понимаю суть твоего явно переусложненного примера:) Да сути небыло, просто было внезапно возникшее ночное желание, что то написать. Книги, обычно, такими примерами не балуют. Может это кому-то поможет понять как работают исключения . А может там есть какая-то фича которую я еще не могу осознать. Если кто знает , поделитесь, где могут еще быть подводные камни? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2007, 10:38 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
Akh daevaorn A. Fig Lee[quot Изопропил][quot Aklin] 2) f(&ret); где ret - возвращаемый код ошибки ? сразу видно, что человек С-шник(в хорошем смысле) - предложил указатель, а не ссылку. Теперь понятна настороженность по отношению к исключениям. Не охото менять мышление?;) Надо уметь пользоваться и тем и тем. +1 а пример из серии "все правильно сделал" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2007, 11:59 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
daevaorn A. Fig Lee[quot Изопропил][quot Aklin] 2) f(&ret); где ret - возвращаемый код ошибки ? сразу видно, что человек С-шник(в хорошем смысле) - предложил указатель, а не ссылку. Теперь понятна настороженность по отношению к исключениям. Не охото менять мышление?;) ето другое. Выработалась привычка писать, чтоб компилировалось все на как можно больше платформ, компайлеров и языков. Сейчас в основном - С, но фронт-енд - С++. До етого С++ был значительно больше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2007, 18:47 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
ErVИсключения, в основном, требовались в ситуациях, когда по-другому можно было выкрутиться только через goto... Откуда такие данные? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2007, 09:49 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
Akh ErVИсключения, в основном, требовались в ситуациях, когда по-другому можно было выкрутиться только через goto... Откуда такие данные? Сишный аналог исключений. man setjmp, sigsetjmp - save stack context for non-local goto longjmp, siglongjmp - non-local jump to a saved stack context ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2007, 10:27 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
Вспомнил еще один момент где без исключений тяжело. Если функция должна возвращить указатель, а вернуть его не может. Возвращать NULL, а потом его за каждым вызовом проверять, не лучший выход. У меня при переходе на исключения количество неприятностей связанных с возвратом указателей сократилась раз в 5. Соответственно возросла скорость отладки кода. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2007, 21:00 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
onstat-Вспомнил еще один момент где без исключений тяжело. Если функция должна возвращить указатель, а вернуть его не может. Возвращать NULL, а потом его за каждым вызовом проверять, не лучший выход.Почему??? Что может быть проще: Код: plaintext 1. 2. Код: plaintext 1. 2. 3. 4. 5. onstat-У меня при переходе на исключения количество неприятностей связанных с возвратом указателей сократилась раз в 5.Это неприятности не с возвратом указателей, а элементарный склероз. Если функция может упасть и это падение нельзя игнорировать, значит его нельзя игнорировать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2007, 22:42 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
White Owl onstat-Вспомнил еще один момент где без исключений тяжело. Если функция должна возвращить указатель, а вернуть его не может. Возвращать NULL, а потом его за каждым вызовом проверять, не лучший выход.Почему??? Что может быть проще: Код: plaintext 1. 2. Код: plaintext 1. 2. 3. 4. 5. Стоит упомянуть что , в подавляющем большенстве случаев указатель не возвращается ради указателя как такового. Следственно Код: plaintext Код: plaintext минимум на один уровень выше. Если решение можно принять на этом уровне, то понятное дело с исключениями завязываться смысла нет. White Owl onstat-У меня при переходе на исключения количество неприятностей связанных с возвратом указателей сократилась раз в 5.Это неприятности не с возвратом указателей, а элементарный склероз. Если функция может упасть и это падение нельзя игнорировать, значит его нельзя игнорировать. Конечно не без этого, люядм свойственно заблуждаться и ошибаться. Не ошибается тот кто ничего не делает. Я выводы из своих ошибок делаю постоянно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2007, 10:16 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
похоже две религии всё-таки сумели договриться? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2007, 10:40 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
onstat- пишет: > Если функция должна возвращить указатель, а вернуть его не может. Нет, не правильно. Это если функция возвращает ССЫЛКУ, а вернуть она ничего не может. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2007, 20:50 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
White Owl пишет: > Почему??? > Что может быть проще: > > if(! (some_pointer = some_function())) { > cout<< "error"; > } Оул, ты законченный ретроград. > А с исключениями ты будешь писать > > try { > some_pointer = some_function(); > } > catch(someexception e) { > cout << "error"; > } С исключениями не надо этого писать. Это надо писать один раз в главной функции, а в этом месте вообще об этом думать не надо. Это конечно если по семантике some_function() должен возвращать ссылку. > Писать с исключениями больше Меньше, ты просто не догоняешь. и код обработки ошибки находится далеко от > кода который может эту ошибку создать. Да, и это ПРАВИЛЬНО! Это - КЛЕВО!. > Это неприятности не с возвратом указателей, а элементарный склероз. Если > функция может упасть и это падение нельзя игнорировать, значит его > нельзя игнорировать. Если функция может попась в ситуацию, когда она НЕ МОЖЕТ вернуть то, что она должна вернуть согласно своей спецификации, надо кидать исключение. Это позволяет не писать код обработки ошибок, который в противном случае вообще никогда не будет работать в отлаженном и выпущенном приложении. И это правильно. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2007, 20:56 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
White Owl пишет: > if(! (some_pointer = some_function())) { > cout<< "error"; > } Кстати, ты уверен, что пользователь будет счастлив, увидев такое на экране ? Уверен, что он вообще что-то поймет ? Уверен, что тут надо выводить именно в консоль, а не например вызывать MessageBox или еще что-то ? Исключения позволяют избавиться от всех этих проблем просто и элегантно, перенося обработку ошибок в то место, где она может быть сделана должным образом. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.03.2007, 21:00 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
MasterZiv Если функция может попась в ситуацию, когда она НЕ МОЖЕТ вернуть то, что она должна вернуть согласно своей спецификации, надо кидать исключение. Это позволяет не писать код обработки ошибок, который в противном случае вообще никогда не будет работать в отлаженном и выпущенном приложении. И это правильно. Posted via ActualForum NNTP Server 1.4 Не понял, что здесь не правильно : MasterZiv автор > Если функция должна возвращить указатель, а вернуть его не может. Нет, не правильно . Это если функция возвращает ССЫЛКУ, а вернуть она ничего не может. Единственное что приходит на ум, если с указателем еще можно как то выкрутиться, то с невалидной ссылкой никак. (Хотя тоже можно, но это будет извращение на уровне сумашествия ). 2 selinoth: Попробуйте показать случай с обработкой невалидной ссылки или указателя ПМ-у и посмотрите на его реакцию. Интересно, как он предложит Вам выйти из ситуации( особенно в случае со ссылкой). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.03.2007, 10:40 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
MasterZivОул, ты законченный ретроград. Вовсе нет. Я всегда с интересом смотрю на новые принципы и если они мне нравятся начинаю использовать :) MasterZiv> Писать с исключениями больше Меньше, ты просто не догоняешь. > и код обработки ошибки находится далеко от > кода который может эту ошибку создать. Да, и это ПРАВИЛЬНО! Это - КЛЕВО!. Ну если это правильно и клево, покажи мне реальную задачу решеную через исключения и чтоб это решение было удобнее чем решение через коды возврата. Вот man_555 очень любит исключения, но показать такую реальную задачу не смог. Может ты сможешь? MasterZivЕсли функция может попась в ситуацию, когда она НЕ МОЖЕТ вернуть то, что она должна вернуть согласно своей спецификации, надо кидать исключение. Это позволяет не писать код обработки ошибок, который в противном случае вообще никогда не будет работать в отлаженном и выпущенном приложении. И это правильно.Бррр.. Ну что значит "не писать код обработки ошибок"? Ты в любом случае будешь писать код обработки ошибки или код обработки исключения. В чем разница то? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.03.2007, 17:58 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
White Owl Ну если это правильно и клево, покажи мне реальную задачу решеную через исключения и чтоб это решение было удобнее чем решение через коды возврата. Вот man_555 очень любит исключения, но показать такую реальную задачу не смог. Может ты сможешь? Как вариант: Выход из тупиков и бесконечных циклов при обработке графов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.03.2007, 20:58 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
onstat- пишет: > Единственное что приходит на ум, > если с указателем еще можно как то выкрутиться, то с невалидной ссылкой > никак. Это и имелось в виду. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.03.2007, 21:05 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
Вяло что-то, вяло обсуждаем... Надо подлить маслица в огонь: А вот что делать, ежели ошибка произошла в одном потоке, а обработать ее надо в другом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.03.2007, 21:06 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
onstat- White Owl Ну если это правильно и клево, покажи мне реальную задачу решеную через исключения и чтоб это решение было удобнее чем решение через коды возврата. Вот man_555 очень любит исключения, но показать такую реальную задачу не смог. Может ты сможешь? Как вариант: Выход из тупиков и бесконечных циклов при обработке графов.Не годится. После натыкания на тупик надо обязательно проверить братские проходы. А значит каждый раз при шаге назад надо будет проверять был ли там тупик. А это можно с легкостью делать и на кодах возврата. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.03.2007, 21:11 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
White Owl пишет: > Ну если это правильно и клево, покажи мне реальную задачу решеную через > исключения и чтоб это решение было удобнее чем решение через коды > возврата. Вот man_555 очень любит исключения, но показать такую реальную > задачу не смог. Может ты сможешь? CTResults &rs = query.getResults(); for(size_t i =0; i < rs[0].NRows(); ++i) { const CTRow &row = rs[0] ; // Здесь чисто теоретически могут возникать exceptopns // если в наборе данных нет полей с названиями "name", "age" или "gender". // Но в отлаженном коде такого быть не может. А если такое случается, // надо вылететь на фиг и ничего не делать. std::cout << "Name:" << row["name"] << " " << "Age: " << row["age"] << " " << "Gender:" << row["gender"] << std::endl; } > Бррр.. Ну что значит "не писать код обработки ошибок"? Ты в любом случае > будешь писать код обработки ошибки или код обработки исключения. В чем > разница то? Я БУДУ ПИСАТЬ ЕГО ОДИН РАЗ !! А не в каждой функции в стеке вызовов. В этом разница. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.03.2007, 21:30 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
blindedВяло что-то, вяло обсуждаем... Надо подлить маслица в огонь: А вот что делать, ежели ошибка произошла в одном потоке, а обработать ее надо в другом. У каждой инти свой стек, она его и будет раскручивать. ИМХО А обработчик исключений рапотовать другой нити стандартными средствами синхронизации. Если уж срочно нужно, то конструктор класса исключений тоже по идее может. Очень интересная тема , кстате. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.03.2007, 21:38 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
White Owl onstat- White Owl Ну если это правильно и клево, покажи мне реальную задачу решеную через исключения и чтоб это решение было удобнее чем решение через коды возврата. Вот man_555 очень любит исключения, но показать такую реальную задачу не смог. Может ты сможешь? Как вариант: Выход из тупиков и бесконечных циклов при обработке графов.Не годится. После натыкания на тупик надо обязательно проверить братские проходы. А значит каждый раз при шаге назад надо будет проверять был ли там тупик. А это можно с легкостью делать и на кодах возврата. Я знал, что Вы так ответите. С таки же успехом вы будете проходить теже пути и без исключений. Я не говорил, что исключения заменяют карту проходов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.03.2007, 21:45 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
onstat- blindedВяло что-то, вяло обсуждаем... Надо подлить маслица в огонь: А вот что делать, ежели ошибка произошла в одном потоке, а обработать ее надо в другом. У каждой инти свой стек, она его и будет раскручивать. ИМХО А обработчик исключений рапотовать другой нити стандартными средствами синхронизации. Если уж срочно нужно, то конструктор класса исключений тоже по идее может. Очень интересная тема , кстате. Ну так потому и затронул :) А что касается исключений, то тут двух мнений быть не может. С исключениями жизнь проще и веселее, чем без них. Хотя бы потому что исключение может нести в себе гораздо больше информации об ошибке, нежели просто код возврата. Контекст в котором произошла ошибка - вот чего зачастую не хватало при обработки ошибки. Если вспомнить былые времена, то сколько сил уходило на написание всяческих отладочных вызовов с записью в системные логи или самописные debug файлы, причем этими вызовами была пронизана вся программаю А что касается обработки ошибок в другом потоке, то посмотрите на паттерн Капсула, я 2 второй странице ссылочку писал. Ну что твои исключения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.03.2007, 22:35 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
MasterZivCTResults &rs = query.getResults(); for(size_t i =0; i < rs[0].NRows(); ++i) { const CTRow &row = rs[0] ; // Здесь чисто теоретически могут возникать exceptopns // если в наборе данных нет полей с названиями "name", "age" или "gender". // Но в отлаженном коде такого быть не может. А если такое случается, // надо вылететь на фиг и ничего не делать. std::cout << "Name:" << row["name"] << " " << "Age: " << row["age"] << " " << "Gender:" << row["gender"] << std::endl; } Поясни пожалуйста, что значит "вылететь на фиг и ничего не делать"? Для вылета нафиг вообще никакая обработка ошибок не нужна :) MasterZiv> Бррр.. Ну что значит "не писать код обработки ошибок"? Ты в любом случае > будешь писать код обработки ошибки или код обработки исключения. В чем > разница то? Я БУДУ ПИСАТЬ ЕГО ОДИН РАЗ !! А не в каждой функции в стеке вызовов. В этом разница.Еще раз "бррр". А почему ты решил что я буду что-то там писать в каждой функции??? Вон в приведеном примере, когда я определяю оператор [] для резалтсета, я предпочту не бросать исключение, а возвращать указатель на пустую строку. Тогда, даже если злодей пойдет и переименует поле gender в поле sex - я все равно получу список name-age с пустотой вместо gender. А в твоем варианте обращение к row["gender"] вызовет полный аборт всей процедуры и ты не получишь вообще ничего. А я хотя бы часть данных увижу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.03.2007, 23:13 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
onstat-С таки же успехом вы будете проходить теже пути и без исключений. Я не говорил, что исключения заменяют карту проходов.Конечно это можно сделать и через исключения и без них. Но спор то идет: "Исключения: за и против" blindedС исключениями жизнь проще и веселее, чем без них. Хотя бы потому что исключение может нести в себе гораздо больше информации об ошибке, нежели просто код возврата. Контекст в котором произошла ошибка - вот чего зачастую не хватало при обработки ошибки. Если вспомнить былые времена, то сколько сил уходило на написание всяческих отладочных вызовов с записью в системные логи или самописные debug файлы, причем этими вызовами была пронизана вся программаюЭто очень убедительное утверждение, до тех пор пока не задумаешься, а кто именно и где заполняет исключение этим самым контекстом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.03.2007, 23:23 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
White Owl Вон в приведеном примере, когда я определяю оператор [] для резалтсета, я предпочту не бросать исключение, а возвращать указатель на пустую строку. Тогда, даже если злодей пойдет и переименует поле gender в поле sex - я все равно получу список name-age с пустотой вместо gender. А в твоем варианте обращение к row["gender"] вызовет полный аборт всей процедуры и ты не получишь вообще ничего. А я хотя бы часть данных увижу. Если бы строители строили здания, как программисты пишут программы.... С таким подходом нужно писать на Basic, не забывая в каждой процедуре написать Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.03.2007, 23:40 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
blinded пишет: > делать, ежели ошибка произошла в одном потоке, а обработать ее надо в > другом. Использовать IPC. Ни стандартные методы обработки, ни exceptions здесь ни при чем. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2007, 00:12 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
White Owl пишет: > Поясни пожалуйста, что значит "вылететь на фиг и ничего не делать"? Для > вылета нафиг вообще никакая обработка ошибок не нужна :) Пример раз : Программа - консольное приложение, которое должно сформировать и отправить электронное письмо. Если что-то не так, например, одно из полей отсутствует, приложение должно завершиться с ошибкой. Бросается исключение, оно ловится в main, выводится сообщение об ошибке, завершается приложение. Пример два. Программа - GUI -приложение, форма для редактирования данных. На форме есть кнопка "Расчитать", при нажатии на нее производится определенное вычисление. Если что-то не так - нет полей - вычисление производить невозможно. Значение, получаемое в ходе вычисления, неопределено. Исключение ловится во фрейме, обрамляющем обработку сообщения, обрабатывается соотв. образом (выводится сообщ. об ошибке) и программа не выполняет действия "Расчет". Приложение при этом может продолжать работать дальше в части, не касающейся этого, а после устранения проблемы - может работать нормально и здесь. А почему ты решил что я буду что-то там писать в каждой > функции??? Вон в приведеном примере, когда я определяю оператор [] для > резалтсета, я предпочту не бросать исключение, а возвращать указатель на > пустую строку. 1) Там возвращается не указатель, а ссылка. 2) Возврат специального значения в случае ошибки - плохой подход. 3) Тобой описывается другая семантика работы функции. И такая, и такая функция могут существовать, причем вместе. Для одной исключения не нужны, для другой - нужны. Тогда, даже если злодей пойдет и переименует поле gender > в поле sex - я все равно получу список name-age с пустотой вместо > gender. А в твоем варианте обращение к row["gender"] вызовет полный > аборт всей процедуры и ты не получишь вообще ничего. А я хотя бы часть > данных увижу. И ты думаешь, что это хорошо? Я вообще не знаю, что такое "часть данных". Вот например, есть у тебя банковский атрибут. Но без БИК. Это все равно что его бы и не было вообще. Так что либо все, либо ничего. В общем, все, к чему ты призываешь - неправильно, нельзя так писать программы. Если ошибка есть, ее нельзя частично игнорировать. Бывают конечно исключения, но ... В общем-то не нравятся тебе исключения - ради бога, не используй. Твои программы, тебе их потом поддерживать. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2007, 00:29 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
White Owl Это очень убедительное утверждение, до тех пор пока не задумаешься, а кто именно и где заполняет исключение этим самым контекстом. Заполняется при throw. Уже не помню откуда этот очень полезный и показательный пример с SQL.RU || RSDN (Автор не я, копирайт утерян): Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. В месте перехвата вы получаете строку и файл, где оно было возбуждено. Можете отнаследоваться и в конструктор в качестве параметра передать другую дополнительную информацию. Которую потом обработаете в месте перехвата. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2007, 11:27 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
MasterZivПример раз : Программа - консольное приложение, которое должно сформировать и отправить электронное письмо. Если что-то не так, например, одно из полей отсутствует, приложение должно завершиться с ошибкой. Бросается исключение, оно ловится в main, выводится сообщение об ошибке, завершается приложение.Точно так же, только вместо throw используем return. Решение ничем кроме синтаксиса не отличается. MasterZivПример два. Программа - GUI -приложение, форма для редактирования данных. На форме есть кнопка "Расчитать", при нажатии на нее производится определенное вычисление. Если что-то не так - нет полей - вычисление производить невозможно. Значение, получаемое в ходе вычисления, неопределено. Исключение ловится во фрейме, обрамляющем обработку сообщения, обрабатывается соотв. образом (выводится сообщ. об ошибке) и программа не выполняет действия "Расчет". Приложение при этом может продолжать работать дальше в части, не касающейся этого, а после устранения проблемы - может работать нормально и здесь.Опять таки, функция расчета может делать throw, может делать return errormessage. Разница чисто синтаксическая. MasterZiv1) Там возвращается не указатель, а ссылка. 2) Возврат специального значения в случае ошибки - плохой подход. 3) Тобой описывается другая семантика работы функции. И такая, и такая функция могут существовать, причем вместе. Для одной исключения не нужны, для другой - нужны.1) в данном случае это не важно 2) Почему плохой? Да, это не всегда возможно, но в большинстве случаев вполне возможно и запросто. 3) Конечно другая, мы ж о том и говорим какой из подходов удобнее :) Но вот если одновременно существуют два варианта функции: возвращающая код ошибки или бросающая исключение - вот это уже будет плохо. Запутаться будет легко. MasterZivИ ты думаешь, что это хорошо? Я вообще не знаю, что такое "часть данных". Вот например, есть у тебя банковский атрибут. Но без БИК. Это все равно что его бы и не было вообще. Так что либо все, либо ничего.Да, я думаю что это хорошо. Если я знаю что без БИК запись быть не может - я во первых запрещу такие записи хранить в БД :) А во вторых, если по каким-то причинам я не могу поправить структуру БД, я могу уже на клиенте делать специальную проверку на заполненность поля "БИК" и обламывать вывод с соответствующей диагностикой. А если речь идет о вспомогательной таблице, ну хотя бы - контактное лицо для этого банковского аттрибута - там поле gender вполне может быть а может и не быть. Но обламывать показ список всех клиентов только из-за того что какому-то из главбухов забыли указать пол? Или как я уже предполагал поле пола переименовали. Есть информация важная, есть второстепенная. Важную - ты всегда будешь специально проверять (и не по одному разу) а второстепенную можно отдать на откуп общему обработчику ошибок. Выдача пустого результата здесь на мой взгляд более подходит чем глобальный облом. MasterZivВ общем, все, к чему ты призываешь - неправильно, нельзя так писать программы. Если ошибка есть, ее нельзя частично игнорировать. Бывают конечно исключения, но ... В общем-то не нравятся тебе исключения - ради бога, не используй. Твои программы, тебе их потом поддерживать. Ну почемуж неправильно? Оглянись вокруг - сколько программ написано на языках не имеющих механизма исключений вообще. И ведь работают! И поддерживаются эти программы. Или вы на таких языках в принципе не пишите? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2007, 19:07 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
Не всетаки есть места где гораздо удобнее с исключениямию Ну ведь согласись template< typename T> class Stack { public: ... void push(const T&); //Ну ведь гораздо симпатичнее получит exception чем возвращать int void pop(); ... const T& read(); // Ну а ежели здесь вернут ссылку на NULL объект для пустого стека, ну совсем фи }; ---- Если молния в лоб угодит, Значит просто подставлен лоб ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2007, 19:27 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
White OwlТочно так же, только вместо throw используем return. Решение ничем кроме синтаксиса не отличается. Так и есть. Одна из основных целей задействования механизма исключений и состоит в том, чтобы уменьшить количество писанины. Сравните, к примеру, код работы с неким COM-объектом: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Как видите код, бросающий исключение, выглядет проще, проще понять алгоритм работы, проще вносить изменения и т.д. White OwlНу почемуж неправильно? Оглянись вокруг - сколько программ написано на языках не имеющих механизма исключений вообще. И ведь работают! И поддерживаются эти программы. Или вы на таких языках в принципе не пишите? :) Ну если рассуждать, то можно сказать, что и ассемблер - замечательный язык для решения прикладных задач. Ведь сколько замечательных программ на нем написано! А в нем тоже нет исключений. И контроля типов нет. И автоматического управления памятью тоже нет. Да вообще ничего нет :). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2007, 19:33 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
blindedНе всетаки есть места где гораздо удобнее с исключениямиюВот в том то и дело, что я не знаю таких мест. blindedНу ведь согласисьНе соглашусь. blinded const T& read(); // Ну а ежели здесь вернут ссылку на NULL объект для пустого стека, ну совсем фиПочему же "фи"? Вполне нормально. Во первых, для стека с объектами NULL это очень хороший индикатор "нет объекта", во вторых для стека с числами возвращать ноль из пустого стека это традиция овеяная десятилетиями. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2007, 19:51 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
roman10 // С исключениями // Для этого вокруг всех методов пишем обертки вида:Угу... И писание оберток вокруг всех методов уменьшает количество писанины? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2007, 19:58 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
White OwlУгу... И писание оберток вокруг всех методов уменьшает количество писанины? Да, уменьшает. Обертки пишутся только один раз (а в отношении COM-объектов, вообще генерируются автоматически). Даже в небольших проектах, объем кода, приходящийся на обертки, будет существенно меньше объема постоянных проверок кодов возврата. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2007, 20:05 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
White Owl blindedНе всетаки есть места где гораздо удобнее с исключениямиюВот в том то и дело, что я не знаю таких мест. б.м. неудача при попытке захвата ресурса в конструкторе как раз тот случай? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2007, 20:16 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
White Owl blindedНе всетаки есть места где гораздо удобнее с исключениямиюВот в том то и дело, что я не знаю таких мест. blindedНу ведь согласисьНе соглашусь. blinded const T& read(); // Ну а ежели здесь вернут ссылку на NULL объект для пустого стека, ну совсем фиПочему же "фи"? Вполне нормально. Во первых, для стека с объектами NULL это очень хороший индикатор "нет объекта", во вторых для стека с числами возвращать ноль из пустого стека это традиция овеяная десятилетиями. Обратите внимание это НЕ указатель , а ссылка . проверять как? Код: plaintext 1. 2. 3. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2007, 21:13 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
White Owl blindedНе всетаки есть места где гораздо удобнее с исключениямиюВот в том то и дело, что я не знаю таких мест. Я тоже так думал, пока не начал писать с ними. White Owl blindedНу ведь согласисьНе соглашусь. Я не навязываюсь White Owl blinded const T& read(); // Ну а ежели здесь вернут ссылку на NULL объект для пустого стека, ну совсем фиПочему же "фи"? Вполне нормально. Во первых, для стека с объектами NULL это очень хороший индикатор "нет объекта", во вторых для стека с числами возвращать ноль из пустого стека это традиция овеяная десятилетиями. Один маленький недостаток для каждого типа T свое понятие о NULL объекте для int 0, а для какого-нибудь employee? Вот и не получится никакого обобщенного типа стека:( Нет, конено можно написать и так template <typename T> class Stack { public: ... int size() const; const T& read() const { assert(size()); return ...; } }; Жить можно, все равно при отладке вылезет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2007, 21:14 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
White Owl пишет: > Точно так же, только вместо throw используем return. Решение ничем кроме > синтаксиса не отличается. Ну ты стойкий перец! Упорно меня не хочешь понимать. Решения ОТЛИЧАЮТСЯ тем, что при RETURN тебе надо будет написать обработку ошибок НА ВСЕХ ПРОМЕЖУТОЧНЫХ УРОВНЯХ в стеке вызовов, приведших к вызову данной функции. Для того и созданы exceptions чтобы с этим бороться. Если бы была разница только в синтаксисе, никому было бы это не нужно. Но я не буду тебя далее убеждать ввиду твоей особой "стойкости" в твоих заблуждениях. > 2) Возврат специального значения в случае ошибки - плохой подход. > 2) Почему плохой? Да, это не всегда возможно, но в большинстве случаев > вполне возможно и запросто. Именно потому, что это не всегда возможно. И потому, что делая так ты уже не всегда отлицаешь нормальную ситуацию от ошибочной. > 3) Тобой описывается другая семантика работы функции. > И такая, и такая функция могут существовать, причем вместе. > Для одной исключения не нужны, для другой - нужны. > 3) Конечно другая, мы ж о том и говорим какой из подходов удобнее :) Но > вот если одновременно существуют два варианта функции: возвращающая код > ошибки или бросающая исключение - вот это уже будет плохо. Запутаться > будет легко. Ничего плохого. Одна другую дополняет. Что для одной - исключительная ситуация, для другой - нормальное поведение. > может и не быть. Но обламывать показ список всех клиентов только из-за > того что какому-то из главбухов забыли указать пол? Я не говорил про "забыли указать пол". Там вообще ПОЛЯ ТАКОГО НЕТ. > предполагал поле пола переименовали. Есть информация важная, есть > второстепенная. Важную - ты всегда будешь специально проверять (и не по > одному разу) а второстепенную можно отдать на откуп общему обработчику > ошибок. Выдача пустого результата здесь на мой взгляд более подходит чем > глобальный облом. Так это он и есть, глобальный облом. Только ты пытаешься его обработать, что безполезно, и пытаешься сделать при этом "хорошую мину". Типа - какого пола оно мы, к сожалению, не знаем, но может вы захотите вступить с ним в брак, авось вам понравится > Ну почемуж неправильно? Оглянись вокруг - сколько программ написано на > языках не имеющих механизма исключений вообще. И ведь работают! И > поддерживаются эти программы. Или вы на таких языках в принципе не О! Это- свежая струя в споре. Давай попробуем перечислить языки и понять, в каких есть исключения, в каких нет. Если тех, где нет окажется больше, значит исключения не так уж и важны. (скриптовые языки не берем) я начинаю, языки в которых есть exceptions: С++ Java (common) Lisp Python Delphi .... Теперь твой ход. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2007, 01:14 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
White Owl пишет: > возвращать ноль из пустого стека это традиция овеяная десятилетиями. В за... нафиг такие традиции. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2007, 01:16 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
Касательно исключений и COM. Как можно вот такое реализовать без исключений и goto ? Код древний и не самый качественный/удачно написанный, сейчас пишу другим стилем и т.д. НО такая задача все равно будет решаться похожим образом: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2007, 02:53 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
ErV ОДнако все равно надо будет освободить созданные интерфейсы и т.д.а если применить RAII? Тогда проблемы в ручном освобождениии не будет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2007, 07:59 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
ErVПри каждом случае, когда хоть одна процедура возвращает код неудачи, дальнейшее выполнение функции невозможно. ОДнако все равно надо будет освободить созданные интерфейсы и т.д. Бряками. :) Еслиб вайла не было, то выход через вызов функции освобождения ресурсов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2007, 09:52 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
blindedВяло что-то, вяло обсуждаем... Надо подлить маслица в огонь: А вот что делать, ежели ошибка произошла в одном потоке, а обработать ее надо в другом.Ну в сишах при асинхронном вызове делегата возникшее исключение у тебя вылетит в вызывающем потоке при вызове EndInvoke ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2007, 11:39 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
daevaorn ErV ОДнако все равно надо будет освободить созданные интерфейсы и т.д.а если применить RAII? Тогда проблемы в ручном освобождениии не будет LPDIRECTXFILEDATA - это, к сожалению, кривой Майкрософтовский макрос, за которым скрывается IDirectXFileData* - т.е. COM обьект. Все COM обьекты в примере инициализируются путем передачи в функцию значений типа IDirectXFileData**. - Т.е. указатель на указатель на интерфейс. Поэтому, по-моему, этот вариант "не катит", и не выйдет "удобно" использовать смарт поинтеры (хотя я могу ошибаться). Akh Бряками. :) Разве бряки пройдут вот тут, вне цикла?: Код: plaintext 1. 2. 3. 4. 5. 6. 7. Akh Еслиб вайла не было, то выход через вызов функции освобождения ресурсов. Расшифруйте, пожалуйста, я вас не понял. У меня слово "вайп" упорно ассоциируется с MMORPG. :-\ (переиграл чуть-чуть в свое время) ЗЫ. Майкрософтвоская программа в аналогичной ситуации использует goto... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2007, 15:10 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
ErV 1. Разве бряки пройдут вот тут, вне цикла?: 2. Akh Еслиб вайла не было, то выход через вызов функции освобождения ресурсов. Расшифруйте, пожалуйста, я вас не понял. У меня слово "вайп" упорно ассоциируется с MMORPG. :-\ (переиграл чуть-чуть в свое время) ЗЫ. Майкрософтвоская программа в аналогичной ситуации использует goto... 1. Видел. Но замолчал тему, т.к. можно закрывать учитывая только открытые. Тем более все равно можно свести ко второму случаю :) 2. Например, такое Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. Почему я такой вариант предложил, потому-что вспомнилось, что когда-то использвал такой вид: int func_close_safe(Param1 lpDXFileEnum, ..., int ret) { SAFE_RELEASE(lpDXFileEnum); SAFE_RELEASE(lpDXFileData); SAFE_RELEASE(lpDXFileApi); return ret; }; int func_work() { while (SUCCEEDED(hr)){ //ProcessTemplate(lpDXFileData); //waiting until TID_D3DRM_FRAME arrives----------------------- const GUID* lpType; hr = lpDXFileData->GetType(&lpType); //hr=E_FAIL; if (hr!=...) return func_close_safe(lpDXFileEnum, ..., error); } [/SRC] ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2007, 15:24 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
ErV 1. Разве бряки пройдут вот тут, вне цикла?: 2. Akh Еслиб вайла не было, то выход через вызов функции освобождения ресурсов. Расшифруйте, пожалуйста, я вас не понял. У меня слово "вайп" упорно ассоциируется с MMORPG. :-\ (переиграл чуть-чуть в свое время) ЗЫ. Майкрософтвоская программа в аналогичной ситуации использует goto... 1. Видел. Но замолчал тему, т.к. можно закрывать учитывая только открытые. Тем более все равно можно свести ко второму случаю :) 2. Например, такое Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. Почему я такой вариант предложил, потому-что вспомнилось, что когда-то использвал такой вид: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2007, 15:25 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
Akh[quot ErV] 2. Например, такое Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. Тут такая небольшая проблема есть. В том файле, откуда я это выдирал, подобных функций было не меньше десятка (та, что я привел, была просто наиболее простая), и работали они все немного по-разному. Далее, часть интерфейсов является локальными переменными, т.е. функция очистки не подойдет, так как вложенные функции на C++ писать нельзя. И, ИМХО, если делать для каждой такой функции класс будет немного нерационально... хотя, конечно, можно попробовать найти точки пересечения и т.д., но просто (мне кажется) код от этого не станет понятнее... И ещё. Обратите внимание на throw в блоке catch. До этой функции происходит 5и-6и уровневый вызов функции, работающих по похожему принципу, но с другими интерфейсами, которые, однако, аналогично инициализируются, и при этом инициализация может пройти неудачно... в этом случае return int можно быть коряво... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2007, 16:43 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
ErV daevaorn ErV ОДнако все равно надо будет освободить созданные интерфейсы и т.д.а если применить RAII? Тогда проблемы в ручном освобождениии не будет LPDIRECTXFILEDATA - это, к сожалению, кривой Майкрософтовский макрос, за которым скрывается IDirectXFileData* - т.е. COM обьект. Все COM обьекты в примере инициализируются путем передачи в функцию значений типа IDirectXFileData**. - Т.е. указатель на указатель на интерфейс. Поэтому, по-моему, этот вариант "не катит", и не выйдет "удобно" использовать смарт поинтеры (хотя я могу ошибаться). ну это совсем не проблема, пока правда boost::smart_com нет, но написать простой враппер для COM интерфейсов можно легко, было бы желание. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2007, 16:50 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
daevaorn ну это совсем не проблема, пока правда boost::smart_com нет, но написать простой враппер для COM интерфейсов можно легко, было бы желание. Ну, не знаю... там интерфейсы в определенном порядке освобождаться должны... и, по-моему, в ряде случаев все-таки может быть быстрее использовать исключения или даже goto... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2007, 18:01 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
Голенков Владимирб.м. неудача при попытке захвата ресурса в конструкторе как раз тот случай?Вот тут согласен. Сложный конструктор который может упасть во время собственно конструирования без исключений упасть не сможет вообще. blindedНет, конено можно написать и так template <typename T> class Stack { public: ... int size() const; const T& read() const { assert(size()); return ...; } }; Жить можно, все равно при отладке вылезетА еще, в случае работы со стеком, можно проверять не пуст ли стек перед очередным pop(). Это будет еще больше писанины, зато при дальнейшем сопровождении программы будет сразу видно что в этом месте мы сто процентно не будем читать из пустого стека и этой ошибки не появится вообще. Ты скажешь: "Ага! Каждый раз делать проверку? Это еще больше писать прийдется!" Да, верно писать прийдется больше, но это будет намного проще сопровождать. Вот представь что ты берешь чужой код сопровождать и видишь там десяток mystack.pop() разбросаных внутри функции. Ты уверен что предыдущий автор ЭТОЙ функции, убедился что автор класса стека действительно бросает исключение из pop() при пустом стеке? Не уверен? Значит ты сам пойдешь искать исходники класса стека и исследовать как там реализована проверка на пустоту стека. Вот берем например QT. Смотрим документацию: QT 4.2.2 T QStack::pop () Removes the top item from the stack and returns it. This function assumes that the stack isn't empty.Скажи мне пожалуйста упадет такой код или не упадет, а если упадет то как именно упадет? Код: plaintext 1. 2. 3. 4. 5. А теперь сравни с этим кодом: Код: plaintext 1. 2. 3. 4. 5. MasterZivНу ты стойкий перец! Упорно меня не хочешь понимать. Решения ОТЛИЧАЮТСЯ тем, что при RETURN тебе надо будет написать обработку ошибок НА ВСЕХ ПРОМЕЖУТОЧНЫХ УРОВНЯХ в стеке вызовов, приведших к вызову данной функции. Для того и созданы exceptions чтобы с этим бороться. Если бы была разница только в синтаксисе, никому было бы это не нужно.А кому нужно чтобы ошибка проходила несколько промежуточных уровней? Вот это еще один момент который меня просто убивает в идеалогии исключений. Зачем мне исключение сгенерированое драйвером железа если я пишу гуй? Ошибка произошедшая на одном уровне должна быть обработана на этом же уровне или в крайнем случае на следующем уровне. Поднимать ее выше можно, но не правильно. А то в итоге ты можешь доподниматься до того что рисуя клиента к базе данных, и в диалоге "сохранить запись, да/нет" ты будешь обрабатывать ошибки tcpip стека. Либо будешь ловить родителя всех исключений, какой-ниубдь std::exception или ему подобное и обрабатывать общую ошибку без разбора что там в действительности произошло. MasterZiv(скриптовые языки не берем)А почему это "скриптовые языки не берем"? Чуешь что счет окажется не в пользу исключений? :) На скриптовых мы пишем не меньше чем на компилируемых. А чем дальше, тем больше. Мне вообще кажется, что будущее за скриптами а не компилируемыми исходниками. Так что скриптовые тоже надо учитывать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2007, 19:19 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
ErVКасательно исключений и COM. Как можно вот такое реализовать без исключений и goto ? .... При каждом случае, когда хоть одна процедура возвращает код неудачи, дальнейшее выполнение функции невозможно. ОДнако все равно надо будет освободить созданные интерфейсы и т.д. А почему без goto? В твоем коде заменяем макрос и try/catch на: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2007, 19:32 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
Показываю как надо, чтоб не жевать сопли с обработкой ошибок по всему коду template <class T> class DirectXPrt // Ценноссть только в деструкторе { public: typedef T* Pointer; virtual ~DirextX() { if (ptr) SAFE_RELEASE(ptr); } // This garbage only for backward compatibility Pointer operator->() { assert(ptr); return ptr; } Pointer getPtr() { assert(ptr); return ptr; } operator T*() { assert(ptr); return ptr; } protected: DirectXPtr() { ptr = 0; } DirectXPtr(Pointer* p) { ptr = p; } Pointer* ptr; }; class DirectXFilePtr : public DirectXPtr<LPDIRECTXFILE> { public: DirectXFilePtr(); DirectXFileEnumPtr makeFileEnum(LPSTR s); void registerTemplates(LPVOID, size_t); // из исходника не ясен 2 параметр }; class DirectXFileEnumPtr : public DirectXPtr<LPDIRECTXFILEENUMOBJECT> { public: typedef DirectXPtr<LPDIRECTXFILEENUMOBJECT> Parent; DirectXFileDataPtr getNext(); private: friend class DirectXFilePtr; DirectXFileEnum(Pointer p) : parent(p) {} }; class DirectXFileDataPtr : public DirectXPtr<LPDIRECTXFILEDATA> { public: typedef DirectXPtr<LPDIRECTXFILEDATA> Parent; GUID getType() const { if (!id) load(); return *id; } const std::string& getString() const { if (!id) load(); return name; } private: friend class DirectXFileEnumPtr; DirectXFileDataPtr(Pointer p) : parent(p), id(0), name("") {} void load(); const GUID* id; std::string nane; } // Классы исключений сами допишите, не маленькие class DirectXFatalException : public std::exception { }; class DirectXEnumException : public std::exception { }; class DirectXDataException : public std::exeption {}; //------------------------------------------------------------------------------------------ DirectXFilePtr::DirectXFilePtr() { if (FAILED(DirectXFileCreate(&ptr)) throw DirectXFatalException(); } DirectXFileEnumPtr DirectXFilePtr::makeFileEnum(LPSTR s) { LPDIRECTXFILEENUMOBJECT p; if ( FAILED(this->CreateEnumObject((LPVOID)s, DXFILELOAD_FROMFILE, &eptr.get())) ) throw DirectXEnumException(); return DirectXFileEnumPtr(p); } void DirectXFilePtr::registerTemplates(LPVOID p, size_t sz) { if(FAILED(this->RegisterTemplates(p. sz))) throw DirectXFatalException(); } DirectXFileDataPtr DirectXFileEnumPtr::getNext() { LPDIRECTXFILEDATA p; if( FAILED(this->GetNextDataObject(&p)) ) throw DirectXEnumException() ; return DirectXFileDataPtr(p); } void DirectXFileDataPtr::load() { if ( FAILED(fileData->GetType(&id))) throw DirectXDataException(); DWORD size; if ( FAILED(lpDXFileData->GetName(0, &dwNameSize)) ) throw DirectXDataException(); char buf[128]; if ( FAILED(lpDXFileData->GetName(buf, &size))) throw DirectXDataException() name = buf; } //------------------------------------------------------------------------------------------ // Зато какая красота в прикладном коде void LoadLevelFromX(LPCSTR lpszXFile) { // Ну это не мое char szbuf[128]; char szbuf2[128]; ExtractFileName(szbuf2, lpszXFile); sprintf(szbuf, "%s%d", szbuf2, rand());//GetTickCount()); // А это уже мое, такое даже секретарша поймет DirectXFilePtr fileApi; fileApi.registerTemplates((LPVOID)D3DRM_XTEMPLATES, D3DRM_XTEMPLATE_BYTES)); DirectXFileEnumPtr fileEnum = fileApi.makeFileEnum(lpszFile); try { while(true) { DirectXFileDataPtr fileData = fileEnum.getNext(); if ( fileData.getType() == TTD__D3DMRFrame && ) { if (fileData.getName() == "SceneRoot") { _D("SceneRoot found\n"); GameLevel_LoadLevel_RootLoop(lpDXFileData); } } else _D ("Not TID_D3DRMFRAME\n"); } } catch ( DirectXEnumException e) { ; } } // А это не мое //-------- // Если молния в лоб угодит, // Значит просто подставлен лоб, // Или волосы действуют словно магнит, // Или тело похоже на столб... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2007, 21:05 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
blindedПоказываю как надо, чтоб не жевать сопли с обработкой ошибок по всему коду ... По-моему, вариант как с goto, так и с исключениями был короче. И проще. И LPDIRECTXFILEDATA это не класс, а typedef, точнее даже макрос #define LPDIRECTXFILEDATA IDirectXFileData* где IDirectXFileData - Com интерфейс. ИМХО, в этом варианте код запутался, фактически остался тем же, особых плюсов я не вижу... ИМХО, нерационально делать вокруг каждого Интерфейса обертку... ЗЫ. Склоняюсь к варианту с goto... А также к мысли найти и пристукнуть того, кто сказал, что использование goto - "плохой стиль". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2007, 22:46 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
Эта краткость обманчмва. Когда надо будет написать ну одну такую функцию обертка сыграет свою роль ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2007, 23:47 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
Не заметил - было здесь или нет, но главное, с моей точки зрения, преимущество исключений в том, что они раскручивают стек корректно. Это значит что ошибку можно безопасно передать на любой уровень. Производительность исключения не шибко роняют, если роняют вообще - желающие могут легко написать тест и сравнить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.03.2007, 00:03 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
blindedКогда надо будет написать ну одну такую функцию обертка сыграет свою роль Когда будет использоваться 50 разных интерфейсов, написание обертки для каждого замедлит работу... (у вас в примере ряд функции имеют надстройки над стандартными функциями) Опять же, это ИМХО... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.03.2007, 00:39 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
ErV blindedКогда надо будет написать ну одну такую функцию обертка сыграет свою роль Когда будет использоваться 50 разных интерфейсов, написание обертки для каждого замедлит работу... (у вас в примере ряд функции имеют надстройки над стандартными функциями) Опять же, это ИМХО... а почему нельзя написать обобщенную обертку для схожих интерфейсов? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.03.2007, 00:46 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
blindedПоказываю как надо, чтоб не жевать сопли с обработкой ошибок по всему кодуВот за такой код я и не люблю С++. В примере ErV четко видны блок инициализации, блок работы и блок деструктор. А в этом наборе темплейтов и классов найти что-либо даже с десятого взгляда не представляется возможным. Это тот самый стиль программирования "лапша" за который ругают оператор goto. Код в котором может разобраться только автор и только в течении ближайшей недели после написания. Добавляем в него исключения и уже сам черт ногу сломит разбираясь как и куда там передается управление, что за чем вызывается. Священая война против goto началась с утверждения что goto перекидывает управление далеко-далеко по коду. Исключения делают тоже самое, но не по линейному коду а по стеку вызовов. daevaornа почему нельзя написать обобщенную обертку для схожих интерфейсов?Можно. Проблема только в том, что это очень сложно. Сложно сделать удобную обертку для чего бы то ни было. Чтобы суметь ее сделать, надо на уровне эксперта разбираться в том для чего делается обертка, а в этом случае обертка уже обычно не нужна. А если ты не эксперт - ты сделашь вместо обертки уродца годного только для сиюминутной задачи. Потащишь этого уродца во второй проект - чуть-чуть облагородишь его, но изначальное уродство заложеное не знанием предмета будет оставаться очень-очень долго. С течением лет это уродство станет почти не заметным, но будет оставаться. В любом случае, чтобы сделать хорошую обертку нужно несколько лет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.03.2007, 01:22 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
White Owl daevaornа почему нельзя написать обобщенную обертку для схожих интерфейсов?]Показываю как надо, чтоб не жевать сопли с обработкой ошибок по всему кодуВот за такой код я и не люблю С++. В примере ErV четко видны блок инициализации, блок работы и блок деструктор. А в этом наборе темплейтов и классов найти что-либо даже с десятого взгляда не представляется возможным. Это тот самый стиль программирования "лапша" за который ругают оператор goto. Код в котором может разобраться только автор и только в течении ближайшей недели после написания. Добавляем в него исключения и уже сам черт ногу сломит Можно. Проблема только в том, что это очень сложно. Сложно сделать удобную обертку для чего бы то ни было. Чтобы суметь ее сделать, надо на уровне эксперта разбираться в том для чего делается обертка, а в этом случае обертка уже обычно не нужна. А если ты не эксперт - ты сделашь вместо обертки уродца годного только для сиюминутной задачи. Потащишь этого уродца во второй проект - чуть-чуть облагородишь его, но изначальное уродство заложеное не знанием предмета будет оставаться очень-очень долго. С течением лет это уродство станет почти не заметным, но будет оставаться. В любом случае, чтобы сделать хорошую обертку нужно несколько лет.[/quot] Ну я не так радикально предлагаю. Всего лишь proxy класс с "правильным" деструктором, который в случае необходимости вызовет release ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.03.2007, 01:27 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
daevaorn ErV blindedКогда надо будет написать ну одну такую функцию обертка сыграет свою роль Когда будет использоваться 50 разных интерфейсов, написание обертки для каждого замедлит работу... (у вас в примере ряд функции имеют надстройки над стандартными функциями) Опять же, это ИМХО... а почему нельзя написать обобщенную обертку для схожих интерфейсов? Наверное можно, я же не изучал эту библиотеку, да и изучать никакого желания. Все знания извлечены из приведенного автормо куска кода. Потом библиотека написана несолько в ином стиле. хотя бы одно то что производящие методы возвращают код ошибки а указатель на созданный объект записывается в переменную переданную по адресу, не дает возможности безопасно ее обернуть. Но игра стоит свеч, ежели посмотреть на "клиентский код" то можно заметить что там вообще указателей нет. Нет места для потенциальной ошибки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.03.2007, 09:10 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
White Owl blindedПоказываю как надо, чтоб не жевать сопли с обработкой ошибок по всему кодуВот за такой код я и не люблю С++. В примере ErV четко видны блок инициализации, блок работы и блок деструктор. А в этом наборе темплейтов и классов найти что-либо даже с десятого взгляда не представляется возможным. Это тот самый стиль программирования "лапша" за который ругают оператор goto. Код в котором может разобраться только автор и только в течении ближайшей недели после написания. Ну кому же чужой код-то нравится, это понятно. А вот что касается лапши - ну не согласен, категорически, каждый класс имеет свою отвественностьи все ясно и понятно, есть файл с объектами, есть перечисление по нему, элемет данных. У каждого класса свой конструктор и деструктор... И вообще это все должно быть разнесено по разным файлам и даже библиотекам... И потом на вкус и цвет ... У меня вообще один знакомый есть у него подход оценка качества ПО совсем простая - работает и ладно. White Owl Добавляем в него исключения и уже сам черт ногу сломит разбираясь как и куда там передается управление, что за чем вызывается. Священая война против goto началась с утверждения что goto перекидывает управление далеко-далеко по коду. Исключения делают тоже самое, но не по линейному коду а по стеку вызовов. Проблема есть, но совсем не в этой области. Как правило код писанный для себя очень плохо задукоментирован, и никогда не знаешь точно какого исключения ждать. White Owl daevaornа почему нельзя написать обобщенную обертку для схожих интерфейсов?Можно. Проблема только в том, что это очень сложно. Сложно сделать удобную обертку для чего бы то ни было. Чтобы суметь ее сделать, надо на уровне эксперта разбираться в том для чего делается обертка, а в этом случае обертка уже обычно не нужна. А если ты не эксперт - ты сделашь вместо обертки уродца годного только для сиюминутной задачи. Потащишь этого уродца во второй проект - чуть-чуть облагородишь его, но изначальное уродство заложеное не знанием предмета будет оставаться очень-очень долго. С течением лет это уродство станет почти не заметным, но будет оставаться. В любом случае, чтобы сделать хорошую обертку нужно несколько лет. Не, не несколько лет. Чтобы первую версию написать месяц, ну и полгодика в эксплуатации вытащат наруже большую часть недостатков. Тут вопрос такой стоит ли овчинка выделки? Если сделать и забыть, то по-видимому нет. А вот есжели придется сталкиваться с подобными задачами достаточно часто или еще того хуже придется сопровождать один проект несколько лет, тады ой. А что касается уродства сего упражнения, дык я энтой библиотеки в глаза не видел, все наваял исключительно глядя в представленный пример, да и времени то потратил - пару часов, в течении которых еще и поужинать успел. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.03.2007, 09:58 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
blinded Проблема есть, но совсем не в этой области. Как правило код писанный для себя очень плохо задукоментирован, и никогда не знаешь точно какого исключения ждать. Ну, не знаю... (далее ИМХО) на меня хорошее влияние оказала книга об XP программировании, и я стараюсь писать код так, чтобы документация к нему не требовалась, равно как и комментарии... (на документацию нужно будет дополнительное время, её все равно надо будет переписывать, и фактически, там будет дублирование кода программы в словесном виде...) Образцом "хорошего" кода для меня на данный момент является Qt. Там логичный стиль, и, в принципе, в том, что там получается, разобраться не очень сложно. К плохому коду отношу то, что творит майкрософт в своих примерах к DirectX SDK, например. Разобраться можно, но там как раз обертки очень старательно используются, и в результате, нужно сидеть довольно долго, чтобы понять логику работы оберток (на изучение работы которых уходит большая часть времени) вместо того, чтобы сразу заняться использованием изучаемого API.. А вот есжели придется сталкиваться с подобными задачами достаточно часто или еще того хуже придется сопровождать один проект несколько лет, тады ой. По-моему, тогда легче будет написать скелет-функцию или скелет-класс, в котором будут использоваться ключевые моменты, а потом плодить от него потомков. Но не оборачивать каждый интерфейс (просто не вижу в этом смысла - это и так уже готовый обьект, ИМХО, оборачивать его ещё раз будет пустой тратой времени), а воплотить в базовом классе/функции основные используемые алгоритмы... А что касается уродства сего упражнения, дык я энтой библиотеки в глаза не видел, все наваял исключительно глядя в представленный пример, да и времени то потратил - пару часов, в течении которых еще и поужинать успел. Это подраздел DirectX - DirectXFile, если вам интересно. Примеров по нему в SDK почти нет. Обертка в данном случае неудобна так как постоянно будет требоваться доступ к переменной, хранящей указатель на интерфейс (например IDirectXFile** и т.д.), который будет засунут, скорее всего, куда-нибудь в private. Сделать с этим ничего нельзя, так как это такая реализация API, исходный код которого не доступен, и которое, к тому же, является системным компонентом. ЕСЛИ бы этого не было, то обертку можно было бы легко написать. Но так как это есть, то потребуется либо куча friend'ов, либо вынести оборачиваемый класс в public либо писать кучу оборачивающих двухстрочных функций для каждого метода исходного интерфейса, а это, по-моему, не самый лучший вариант, так как все удобство обертки сведет к нулю... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.03.2007, 11:13 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
Мы несколько отклонились от темы. Вообще-то разговор шел об исключениях. И мне кажется что при правильном их использовании код значительно упрощается. Во всяком случам получившаяся LoadLevelFromХ выглядит значительно менее устрашающе чем исходный вариант, я не говорю об обертке. А что касается библиотеки DirectX я с ней не пересекаюсь, ибо живу на Unix'e. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.03.2007, 12:33 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
blindedМы несколько отклонились от темы. Вообще-то разговор шел об исключениях. И мне кажется что при правильном их использовании код значительно упрощается. Во всяком случам получившаяся LoadLevelFromХ выглядит значительно менее устрашающе чем исходный вариант, я не говорю об обертке. А что касается библиотеки DirectX я с ней не пересекаюсь, ибо живу на Unix'e. Простите, исходный вариант использовал исключения - макрос HRCHECK бросал производный мой собсвтенный класс исключения, который нес в себе информацию об имени функции, строке, и файле, где произошла ошибка... А получившийся ваш вариант (ничего личного) для меня лично выглядит "более устрашающе" по ряду причин... Пример я привел так как меня давно этот вопрос интересовал, и здесь он был "в тему" в том числе как вариант проблемы не обязательно привязанной к DirectX и Win32... Вообще, стандартному C++ , ИМХО, не хватает модели try{...}catch(){..}finally{...}... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.03.2007, 16:06 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
blindedА вот что касается лапши - ну не согласен, категорически, каждый класс имеет свою отвественностьи все ясно и понятно, есть файл с объектами, есть перечисление по нему, элемет данных. У каждого класса свой конструктор и деструктор... И вообще это все должно быть разнесено по разным файлам и даже библиотекам...А там вообще классы нужны? А темплейты? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.03.2007, 17:32 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
White Owl пишет: > это еще один момент который меня просто убивает в идеалогии исключений. > Зачем мне исключение сгенерированое драйвером железа если я пишу гуй? > Ошибка произошедшая на одном уровне должна быть обработана на этом же > уровне или в крайнем случае на следующем уровне. Поднимать ее выше > можно, но не правильно. В рамках обоих техник можно поднимать или не поднимать ошибки до любого уровня. Поднимается ошибка или нет - зависит от предметной области и правильности реализации софта. > А почему это "скриптовые языки не берем"? А потому что серьезные проекты на них не пишут. Ну ладно, фиг с ними, пусь будут. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.03.2007, 22:59 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
MasterZiv> это еще один момент который меня просто убивает в идеалогии исключений. > Зачем мне исключение сгенерированое драйвером железа если я пишу гуй? > Ошибка произошедшая на одном уровне должна быть обработана на этом же > уровне или в крайнем случае на следующем уровне. Поднимать ее выше > можно, но не правильно. В рамках обоих техник можно поднимать или не поднимать ошибки до любого уровня. Поднимается ошибка или нет - зависит от предметной области и правильности реализации софта.Да, можно поднимать или не поднимать. Но по умолчанию исключения поднимаются. Когда я из своей процедуры вызываю функцию с кодом возврата, я сам решаю игнорировать этот код или нет. Если его надо обработать - я прописываю как именно его надо обрабатывать. А с исключениями мне всегда приходится их обрабатывать или надеятся что кто-то там, вызвавший мою процедуру правильно обработает исключение брошеное функцией. > А почему это "скриптовые языки не берем"? А потому что серьезные проекты на них не пишут. Ну ладно, фиг с ними, пусь будут.[/quot]Ну да, веб-сайты уже серьезными проектами не считаются :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2007, 00:10 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
MasterZiv А потому что серьезные проекты на них не пишут. пишут ещё как! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2007, 00:11 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
White OwlЗачем мне исключение сгенерированое драйвером железа если я пишу гуй? Ошибка произошедшая на одном уровне должна быть обработана на этом же уровне или в крайнем случае на следующем уровне. Поднимать ее выше можно, но не правильно.Забавно. Как вы, к примеру обработаете на уровне железа отказ при записи на диск? Или сбой канала связи? Ни как! Единственный способ обработать фатальную ошибку, это передать ее наверх, чтобы приложение могло предупредить пользователя, что что-то пошло не так, и предоставить диагностическую информацию для передаче службе поддержки или записи в лог. Все нефатальные ошибки (т.е. которые можно разрулить без вмешательства пользователя) железом и так обрабатываются. White OwlА то в итоге ты можешь доподниматься до того что рисуя клиента к базе данных, и в диалоге "сохранить запись, да/нет" ты будешь обрабатывать ошибки tcpip стека. Либо будешь ловить родителя всех исключений, какой-ниубдь std::exception или ему подобноеИ как же вы поступите, если будете обрабатывать ошибки вручную? Вам же все равно их придется обрабатывать. Механизм исключений, по сути, не вносит никаких принципиальных изменений в стратегию обработки ошибок. Они только упрощают это дело. White Owlобрабатывать общую ошибку без разбора что там в действительности произошло.Опять таки, как вы будете разбирать, что там произошло? Ну вот вернул вам send() значение SOCKET_ERROR. И что дальше? Что тут будем разбирать? White OwlДа, можно поднимать или не поднимать. Но по умолчанию исключения поднимаются. Когда я из своей процедуры вызываю функцию с кодом возврата, я сам решаю игнорировать этот код или нет.На каком основании вы позволяете себе проигнорировать ошибку? В подавляющем большинстве случаев их игнорировать нельзя. White OwlА с исключениями мне всегда приходится их обрабатывать или надеятся что кто-то там, вызвавший мою процедуру правильно обработает исключение брошеное функцией.При ручном контроле за возвращаемыми кодами ошибок вам тоже придется их всегда обрабатывать. В случае исключений достаточно один раз написать блок catch(), иногда один на все приложение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2007, 09:59 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
White Owl пишет: > Да, можно поднимать или не поднимать. Но по умолчанию исключения > поднимаются. Кто тебе сказал это ? Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2007, 10:03 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
White Owl пишет: > Да, можно поднимать или не поднимать. Но по умолчанию исключения > поднимаются. Когда я из своей процедуры вызываю функцию с кодом > возврата, я сам решаю игнорировать этот код или нет. Если его надо > обработать - я прописываю как именно его надо обрабатывать. А с > исключениями мне всегда приходится их обрабатывать или надеятся что > кто-то там, вызвавший мою процедуру правильно обработает исключение > брошеное функцией. Так, кажется с тобой все понятно, ты просто не понимаешь идеологию исключений и как они должны работать. Так вот, с исключениями ты можешь делать ровно то же самое. Единственная проблема в том, что язык С++ не заставляет специфицировать все исключения функции (но тем не менее они могут быть указаны) и ты не видишь иногда, какие исключения тебе надо обрабатывать. Это в общем случае должно быть указано в документации на функцию (но может быть и в коде) и зависит от того, насколько хорошо поставлена технология программирования и документирования в данной конторе, которая разрабатывает код. Но самое главное не в этом, а в том, что при использовании кодов возвратов мы наблюдаем ту же самую проблему - не все коды возвратов могут быть описаны, и ты можешь запросто не знать половины из них и неправильно их обрабатывать. Так что в этом смысле ситуация ну ничем не отличается. Собственно идеология исключений и заключается в том, что функция получает еще один канал общения с окружающим ее миром, помимо возвращаемого значения и входных/выходных параметров. Причем информация, получаемая из функции по этому каналу может быть обработана ГДЕ УГОДНО, а не только в месте вызова этой функции. > Ну ладно, фиг с ними, пусь будут.[/quot] > Ну да, веб-сайты уже серьезными > проектами не считаются :) Не считаются однозначно. Причем серьезные сайты не пишут на скриптовых языках, типа перла и PHP. Ладно, не важно. Ты мне примеров языков БЕЗ исключений так и не привел. C, FORTRAN ? Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2007, 10:16 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
daevaorn пишет: > А потому что серьезные проекты на них не пишут. > пишут ещё как! Примеры давай. Проект, язык. Я в общем-то не против т.н. динамических языков, а очень даже за, я хотел отмести языки типа Perl и bash shell script. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2007, 10:19 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
roman10 пишет: О! Союзнег поивилси ! Классно ! > И как же вы поступите, если будете обрабатывать ошибки вручную? Вам же > все равно их придется обрабатывать. Механизм исключений, по сути, не > вносит никаких принципиальных изменений в стратегию обработки ошибок. > Они только упрощают это дело. Золотые слова! +1 > White Owl > Да, можно поднимать или не поднимать. Но по умолчанию исключения > поднимаются. Когда я из своей процедуры вызываю функцию с кодом > возврата, я сам решаю игнорировать этот код или нет. > > На каком основании вы позволяете себе проигнорировать ошибку? В > подавляющем большинстве случаев их игнорировать нельзя. Не, может быть можно и проигнорировать ошибку. Например, при сбое диска записать на другой. Но это зависит от приложения целиком и полностью. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2007, 10:23 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
ErV blindedМы несколько отклонились от темы. Вообще-то разговор шел об исключениях. И мне кажется что при правильном их использовании код значительно упрощается. Во всяком случам получившаяся LoadLevelFromХ выглядит значительно менее устрашающе чем исходный вариант, я не говорю об обертке. А что касается библиотеки DirectX я с ней не пересекаюсь, ибо живу на Unix'e. Простите, исходный вариант использовал исключения - макрос HRCHECK бросал производный мой собсвтенный класс исключения, который нес в себе информацию об имени функции, строке, и файле, где произошла ошибка... Да конечно, только вот функциякоторую вы привели ничего от наличия исключений не выиграла, ну разве что исключение несло информацию о строчке кода где оно было сгенерировано. ErV А получившийся ваш вариант (ничего личного) для меня лично выглядит "более устрашающе" по ряду причин... Интересно почему? Неужто такой страшный? Тут мы в прошлом годе про фабрики обсуждали, вот там действительно страшный, а здесь все понятно... ErV Пример я привел так как меня давно этот вопрос интересовал, и здесь он был "в тему" в том числе как вариант проблемы не обязательно привязанной к DirectX и Win32... Вообще, стандартному C++ , ИМХО, не хватает модели try{...}catch(){..}finally{...}... О вот тут -то выи не правы.finall нуже только при использовании сборщика мусора, если им не пользоваться то можно и без него обойтись.Время жизни объекта в С++ точно определено и освобождение ресурсов совершенно безболезненно можно связать с деструктором, что собстенно у меня и сделано. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2007, 11:20 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
White Owl blindedА вот что касается лапши - ну не согласен, категорически, каждый класс имеет свою отвественностьи все ясно и понятно, есть файл с объектами, есть перечисление по нему, элемет данных. У каждого класса свой конструктор и деструктор... И вообще это все должно быть разнесено по разным файлам и даже библиотекам...А там вообще классы нужны? А темплейты? Ну чтобы Hello world! нарисовать, классы тоже не нужны. Вопрос в контексте. Скорее всего функция вырвана из контекста и там наличие классов оберток сыграло бы свою роль. А что касается шаблонов, тоэто уж вопрос техники прграммирования, у меня во с ними хорошо, как впрочем и с классами, я их и использую. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2007, 11:28 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
blinded ErV Простите, исходный вариант использовал исключения - макрос HRCHECK бросал производный мой собсвтенный класс исключения, который нес в себе информацию об имени функции, строке, и файле, где произошла ошибка... Да конечно, только вот функциякоторую вы привели ничего от наличия исключений не выиграла, ну разве что исключение несло информацию о строчке кода где оно было сгенерировано. По-моему, вы упустили тот момент, что ошибка могла произойти на довольно глубоком уровне вызова а отлов брошенного исключения позволял нормально освободить ресурсы в функции, вызвавшей функцию, вызвавшей функцию (повторть нужное чило раз) вызвавшей то, что я привел в примере... blinded ErV А получившийся ваш вариант (ничего личного) для меня лично выглядит "более устрашающе" по ряду причин... Интересно почему? Неужто такой страшный? Тут мы в прошлом годе про фабрики обсуждали, вот там действительно страшный, а здесь все понятно... Возможно, это дело вкуса. Просто, ИМХО, написание оберток как раз в этом случае будет пустой тратой времени, так как особенной в них потребности нет. Т.е. - можно написать программу, работающую и без оберток, и выглядеть и читаться она будет нормально. Обертки (опять же, ИМХО) конкретно здесь будут только запутывать программную логику. Я не думаю, что в этом случае кто-то кроме автора в "обильно обернутом" коде сможет разобраться быстро и сразу. ООП/оборачивание каждого интерфейса, ИМХО, должно применяться к месту, и это не тот случай. В данный момент оборачивание не добовляет никакой особо важной жизненной функциональности. Я понимаю случай, когда оборачивается IDirect3DBaseTexture9 с целью предотвращение дублирования ресурсов и загрузки одной текстуры дважды. Понимаю, когда оборачивается IDirectSoundBuffer, делается базовым классом, от которого поизводятся уже классы OggSound, StreamSound, WavSound и т.д. ППонимаю, когда берется пачка интерфейсов IDirect3D9 IDirect3DDevice9 и оборачивается в систему, которая представляет собой функциональный менеджер экрана, отвечающий за корректную очистку ресурсов при потере устройства, смене разрешений экрана и т.д. и т.п. Т.е. - я понимаю оборачивание, когда добавляется функциональность, изначально в интерфейсе/интерфейсах отстутсвующая. Но в этом примере, извините, не вижу в обертке смысла. Новой функционлаьности нет, соотвтетсвнно, будет пустая трата ресурсов, чтобы в результате получить то же самое, что и было, только код будет медленнее, больше, неудобнее, кривей и непонятнее... blinded ErV Пример я привел так как меня давно этот вопрос интересовал, и здесь он был "в тему" в том числе как вариант проблемы не обязательно привязанной к DirectX и Win32... Вообще, стандартному C++ , ИМХО, не хватает модели try{...}catch(){..}finally{...}... О вот тут -то выи не правы.finall нуже только при использовании сборщика мусора, если им не пользоваться то можно и без него обойтись.Время жизни объекта в С++ точно определено и освобождение ресурсов совершенно безболезненно можно связать с деструктором, что собстенно у меня и сделано. finally удобно использовать, когда требуется блок, который 100% будет выполнен, как в том случае, когда исключение будет, так и в том, когда его не будет. В случае с использованием try{}catch(){} мне пришлось дублировать блок очистки ресурсов, а это, во-первых, некрасиво, во-вторых, это светит глюками... В случае, если бы был finally, мне этот блок очистки пришлось бы писать только один раз. Причем тут сборщик мусора? Поставить очистку после catch - тоже не вариант, так как внутри catch я вполне могу решить кинуть исключение дальше... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2007, 12:21 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
ErV По-моему, вы упустили тот момент, что ошибка могла произойти на довольно глубоком уровне вызова а отлов брошенного исключения позволял нормально освободить ресурсы в функции, вызвавшей функцию, вызвавшей функцию (повторть нужное чило раз) вызвавшей то, что я привел в примере... Да нет не упустил, я так же нормально освобождаю ресурсы.. деструкоры автоматических прееменных при генерации исключения будут отработаны, все ресурсы будут освобождены blinded ErV Возможно, это дело вкуса. Просто, ИМХО, написание оберток как раз в этом случае будет пустой тратой времени, так как особенной в них потребности нет. Т.е. - можно написать программу, работающую и без оберток, и выглядеть и читаться она будет нормально. Обертки (опять же, ИМХО) конкретно здесь будут только запутывать программную логику. Я не думаю, что в этом случае кто-то кроме автора в "обильно обернутом" коде сможет разобраться быстро и сразу. ООП/оборачивание каждого интерфейса, ИМХО, должно применяться к месту, и это не тот случай. В данный момент оборачивание не добовляет никакой особо важной жизненной функциональности. Я понимаю случай, когда оборачивается IDirect3DBaseTexture9 с целью предотвращение дублирования ресурсов и загрузки одной текстуры дважды. Понимаю, когда оборачивается IDirectSoundBuffer, делается базовым классом, от которого поизводятся уже классы OggSound, StreamSound, WavSound и т.д. ППонимаю, когда берется пачка интерфейсов IDirect3D9 IDirect3DDevice9 и оборачивается в систему, которая представляет собой функциональный менеджер экрана, отвечающий за корректную очистку ресурсов при потере устройства, смене разрешений экрана и т.д. и т.п. Т.е. - я понимаю оборачивание, когда добавляется функциональность, изначально в интерфейсе/интерфейсах отстутсвующая. Но в этом примере, извините, не вижу в обертке смысла. Новой функционлаьности нет, соотвтетсвнно, будет пустая трата ресурсов, чтобы в результате получить то же самое, что и было, только код будет медленнее, больше, неудобнее, кривей и непонятнее... В данном конкретном примере наверное все что я сделал может показать лишним. Но опять повторяю все зависит от контекста. Ежели писать Hello world то нет необходимости изобретать iosteam. Что же касается обрток то причин для их написания может быть множество: - чтобы избежать ошибок при написании кода. Пример - я считаю просто необходимо обернуть сокеты, иначе костей не соберешь - иногда необходимо завернуть сторонню библиотеку чтобы сохранить стилистику собственного кода. Ну уж если принята в коменде практика использовать исключения и RAII ну наверное будет разумным завернуть стороннюю библиотеку. Опять же я не заставляю вас это делать. Мне просто хотелось показать как можно писать с исключениями красиво и понятно. ErV Пример я привел так как меня давно этот вопрос интересовал, и здесь он был "в тему" в том числе как вариант проблемы не обязательно привязанной к DirectX и Win32... Вообще, стандартному C++ , ИМХО, не хватает модели try{...}catch(){..}finally{...}... О вот тут -то выи не правы.finall нуже только при использовании сборщика мусора, если им не пользоваться то можно и без него обойтись.Время жизни объекта в С++ точно определено и освобождение ресурсов совершенно безболезненно можно связать с деструктором, что собстенно у меня и сделано. finally удобно использовать, когда требуется блок, который 100% будет выполнен, как в том случае, когда исключение будет, так и в том, когда его не будет. В случае с использованием try{}catch(){} мне пришлось дублировать блок очистки ресурсов, а это, во-первых, некрасиво, во-вторых, это светит глюками... В случае, если бы был finally, мне этот блок очистки пришлось бы писать только один раз. Причем тут сборщик мусора? Поставить очистку после catch - тоже не вариант, так как внутри catch я вполне могу решить кинуть исключение дальше...[/quot] Я прекрасно знаю как писать с finally ибо последнее время постоянно пишу на Java. И опять повторяю что в C++ нет необходимости в этой конструкции. Более того если она вам понадобилась то скорее всего вы пишите в "неправильном стиле". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2007, 13:15 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
MasterZivТак, кажется с тобой все понятно, ты просто не понимаешь идеологию исключений и как они должны работать. Так вот, с исключениями ты можешь делать ровно то же самое. Единственная проблема в том, что язык С++ не заставляет специфицировать все исключения функции (но тем не менее они могут быть указаны) и ты не видишь иногда, какие исключения тебе надо обрабатывать. Это в общем случае должно быть указано в документации на функцию (но может быть и в коде) и зависит от того, насколько хорошо поставлена технология программирования и документирования в данной конторе, которая разрабатывает код. Но самое главное не в этом, а в том, что при использовании кодов возвратов мы наблюдаем ту же самую проблему - не все коды возвратов могут быть описаны, и ты можешь запросто не знать половины из них и неправильно их обрабатывать. Так что в этом смысле ситуация ну ничем не отличается.Есть отличие! Когда я работаю с кодами возврата, и функция выдала мне что-то неизвестное, я хотя бы всегда знаю какая именно функция сгенерировала этот неизвестный код. С исключениями мне остается только надеяться, что внутри исключения записана информация о том кто это исключение сгенерировал. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. MasterZivСобственно идеология исключений и заключается в том, что функция получает еще один канал общения с окружающим ее миром, помимо возвращаемого значения и входных/выходных параметров. Причем информация, получаемая из функции по этому каналу может быть обработана ГДЕ УГОДНО, а не только в месте вызова этой функции.Вот это самое ГДЕ УГОДНО мне в исключениях не нравится больше всего. Если у меня произошла ошибка, я хочу знать где она произошла. Я хочу видеть обработку ошибки на том же экране текстового редактора что и вызов функции эту ошибку генерирующий. Мне не нравится бегать по тексту вперед-назад и вспоминать "А кто у нас может сгенерировать это исключение? А все ли я исключения перехватил?" MasterZivТы мне примеров языков БЕЗ исключений так и не привел. C, FORTRAN ?Ой, да любой необъектный, и даже некоторые объектные как например VisualBasic и PowerBuilder. Плюс все скриптовые. Может ты их и не считаешь серьезными языками, но тем не менее, люди на них пишут очень много. Тот же shell например. Я знаю например индустриальную систему работающую на нефтеперекачивающих станциях написаную целиком на С и ksh. На С - все расчеты и драйвера датчиков, на ksh - весь операторский гуй, контроль датчиков и вся логика управления насосами. Соглашусь что это достаточно уникальная система, но влится в команду разработчиков и поддерживать ее было очень просто. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2007, 18:22 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
roman10 White OwlЗачем мне исключение сгенерированое драйвером железа если я пишу гуй? Ошибка произошедшая на одном уровне должна быть обработана на этом же уровне или в крайнем случае на следующем уровне. Поднимать ее выше можно, но не правильно.Забавно. Как вы, к примеру обработаете на уровне железа отказ при записи на диск? Или сбой канала связи? Ни как! Единственный способ обработать фатальную ошибку, это передать ее наверх, чтобы приложение могло предупредить пользователя, что что-то пошло не так, и предоставить диагностическую информацию для передаче службе поддержки или записи в лог. Все нефатальные ошибки (т.е. которые можно разрулить без вмешательства пользователя) железом и так обрабатываются.эээээ... юноша, вы что-нибудь писали для железа? Ошибку железа ты никогда не передаешь наверх. Ошибка железа это сбой при записи в конкретный сектор диска, или несовпадение контрольной суммы в пакете и или неверный заголовок, или длина пакета... А наверх всегда уходит одна единственная ошибка: "плохой пакет". Следующий уровень уже решает повторить попытку посылки пакета или сообщить выше о потере связи, что там с пакетом произошло в действительности на уровне гуя совершенно не важно. Гую надо обрабатывать только два типа ошибки - нет ошибки и обрыв связи. Но если ты сильно хочешь - можешь конечно сообщать гую о всех пакетах с неверной контрольной суммой или с потеряным хвостом :) roman10 White OwlА с исключениями мне всегда приходится их обрабатывать или надеятся что кто-то там, вызвавший мою процедуру правильно обработает исключение брошеное функцией.При ручном контроле за возвращаемыми кодами ошибок вам тоже придется их всегда обрабатывать. В случае исключений достаточно один раз написать блок catch(), иногда один на все приложение.ээээээ..... Ну с такими аргументами даже спорить сложно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2007, 18:35 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
MasterZiv> А потому что серьезные проекты на них не пишут. > пишут ещё как! Примеры давай. Проект, язык. Я в общем-то не против т.н. динамических языков, а очень даже за, я хотел отмести языки типа Perl и bash shell script.В Перле кстати, исключения есть. А вот почему они настолько редко используется что про них почти никто не знает - это уже вопрос для размышления на досуге :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2007, 18:42 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
White Owl пишет: > Ой, да любой необъектный, Конкретнее. и даже некоторые объектные как например > VisualBasic и PowerBuilder. В VB на сколько я помню есть исключения. Плюс все скриптовые. Может ты их и не > считаешь серьезными языками, Python - скриптовый язык ? Исключения там есть. Значит - не все скриптовые. Но вот уж что .sh - это язык программирования - это уж увольте. Не согласен я считать его языком программирования. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2007, 19:23 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
White OwlЕсть отличие! Когда я работаю с кодами возврата, и функция выдала мне что-то неизвестное, я хотя бы всегда знаю какая именно функция сгенерировала этот неизвестный код. С исключениями мне остается только надеяться, что внутри исключения записана информация о том кто это исключение сгенерировал. А вот тут вы передергиваете. Сами наверняка писали неоднократно Код: plaintext 1. 2. White Owl Вот это самое ГДЕ УГОДНО мне в исключениях не нравится больше всего. Если у меня произошла ошибка, я хочу знать где она произошла. Я хочу видеть обработку ошибки на том же экране текстового редактора что и вызов функции эту ошибку генерирующий. Мне не нравится бегать по тексту вперед-назад и вспоминать "А кто у нас может сгенерировать это исключение? А все ли я исключения перехватил?" [/qout] Опять заблуждение или обман. Если вы получаете исключение от стороннего вызова то так ли уж интересна его внутренняя кухня и знание что вы получили исключение от метода (функции) с именем XXX. Все равно внутрь кода вы не залезете. А если это ваш код, то кто вам иешает ввести собственнубю политику исключений? Нарисовать собственный базовый класс исключений и впередю Если желаете код пришлю и все будет нормально. [quot White Owl]Ой, да любой необъектный, и даже некоторые объектные как например VisualBasic и PowerBuilder. Плюс все скриптовые. Может ты их и не считаешь серьезными языками, но тем не менее, люди на них пишут очень много. Ну на счет всех необектных языков это вы погорячилисью Исключения совсем не изобретение родоначальников объектного подхода, кажется еще в PL1 были, и в Аде, а вот ребята из форума по Oracle (PL/SQL) без исключений тоже не могут. Кстати в нашем любимом и могучем их тоже поначалу не было, однако включили их в стандарт, а там просто так и мышь не пролезет.. А по хорошему надо уметь писать и так и так... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2007, 19:46 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
MasterZivВ VB на сколько я помню есть исключения.В VB.Net есть. В классическом VB6 уж не говоря о VBA и VBS - нету. А насчет конкретнее... Наверное вынужден согласится, но под давлением моды, сейчас расширения языка добавляющие поддержку исключений делают подо все. Уже вон и Perl и PHP сдались. MasterZivНо вот уж что .sh - это язык программирования - это уж увольте. Не согласен я считать его языком программирования.Программу на нем написать можно? Компьютер эту программу выполнит? Значит язык программирования. blindedА вот тут вы передергиваете. Сами наверняка писали неоднократно Код: plaintext 1. Я пишу обычно так: Код: plaintext 1. 2. 3. 4. blindedОпять заблуждение или обман. Если вы получаете исключение от стороннего вызова то так ли уж интересна его внутренняя кухня и знание что вы получили исключение от метода (функции) с именем XXX. Все равно внутрь кода вы не залезете.Ну как же не интересно. Вот например задача чтения резалтсета. Сделал ты "cout << rs[0] << rs[1] << rs[2]" поймал исключение FieldIsNull или FieldDoesnotExist и скажи мне теперь, какое из полей это исключение кинуло. Да в конце концов, реши задачку отлова незадокументированого исключения, пример я уже показывал. blindedА по хорошему надо уметь писать и так и так...Но вот так мы пишем с легкостью, а вот так - с отвращением :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2007, 20:33 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
White Owl MasterZivВ VB на сколько я помню есть исключения. В VB.Net есть. В классическом VB6 уж не говоря о VBA и VBS - нету. А насчет конкретнее... Наверное вынужден согласится, но под давлением моды, сейчас расширения языка добавляющие поддержку исключений делают подо все. Уже вон и Perl и PHP сдались. Так как на счет PL1 и Аda? А вот на счет Perl'a это да Perl - это вообще не язык, это буйное помешательство вобравшее в себя весь возможный набор парадигм... White Owl MasterZivНо вот уж что .sh - это язык программирования - это уж увольте. Не согласен я считать его языком программирования. Программу на нем написать можно? Компьютер эту программу выполнит? Значит язык программирования. Тут спорить не буду, ничем не хуже чем Basic White Owl blindedА вот тут вы передергиваете. Сами наверняка писали неоднократно Код: plaintext 1. Я пишу обычно так: Код: plaintext 1. 2. 3. 4. Круто, я бы повесился. А чего же префикса имени ошибки не даешь? Каждой функции свой префикс ошибки!!! White Owl blindedОпять заблуждение или обман. Если вы получаете исключение от стороннего вызова то так ли уж интересна его внутренняя кухня и знание что вы получили исключение от метода (функции) с именем XXX. Все равно внутрь кода вы не залезете. Ну как же не интересно. Вот например задача чтения резалтсета. Сделал ты "cout << rs[0] << rs[1] << rs[2]" поймал исключение FieldIsNull или FieldDoesnotExist и скажи мне теперь, какое из полей это исключение кинуло. Да в конце концов, реши задачку отлова незадокументированого исключения, пример я уже показывал. Ну в данном конкретном примере - элементарно cout<< rs[0] << flush < << rs[1] << flush << rs[2] << endl; Кстати а чем бы тебе помог код возврата? Я правда не спец в ADO или что оно там, вот только сомневаюсь, что ежели спросить у Exception what оно не скажет ничего о поле в котором произошла ошибка:) White Owl blindedА по хорошему надо уметь писать и так и так...Но вот так мы пишем с легкостью, а вот так - с отвращением :) Взаимно, вот только полюса поменяйте ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2007, 21:05 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
blinded Код: plaintext 1. 2. 3. 4. Круто, я бы повесился. А чего же префикса имени ошибки не даешь? Каждой функции свой префикс ошибки!!! [/quot] Для таких случаев в C++ есть отличная возможость все коды ошибок запихнуть в enum который можно засунуть в namespace или даже класс. И никаких префиксов по пять раз не понадобиться писать. Вообще рекомендую вам посмотреть исходники Qt как образец... Вы вот про обертки для интерфейсов писали. А что мешает вам нужные наборы функций обьединить в пространства имен или классы, в рамках которых (в области видимости) объявить коды ошибок? Обалденно от name clash'ей помогает.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2007, 22:31 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
blindedТак как на счет PL1 и Аda?Я по ним только учебники в детстве читал, а практически ничего не писал. Так что ничего конкретного насчет них сказать не смогу, извините. blindedА вот на счет Perl'a это да Perl - это вообще не язык, это буйное помешательство вобравшее в себя весь возможный набор парадигм...Ну не надо. Perl это жемчужина со всех точек зрения. Обожаю Perl. Жаль что он мне сейчас по работе почти не нужен. blinded White OwlУ каждой функции, на каждом слое свой собственный набор ошибок. Ошибка нижнего слоя наверх никогда не уходит. Вообще.Круто, я бы повесился. А чего же префикса имени ошибки не даешь? Каждой функции свой префикс ошибки!!!И префиксы даю и enum из функции возвращаю. Очень удобно получается. Смотришь исходник и с первого взгляда видно ошибки какой группы мы здесь обрабатываем. Кстати, в java еще на уровне компиляции есть замечательная штука - контроль за тем, чтобы все исключения брошеные вызваной функцией были хоть как-то обработаными. А в С++ такого контроля нету... Зато если функция возвращает enum, то вот например такой код: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. Код: plaintext 1. А представь что мы вызываем foo() из какой-нибудь чужой библиотеки, а потом однажды обновили эту самую чужую библиотеку и теперь foo() новой версии выдает больше (или вообще другие) ошибки чем в предыдущей версии. В варинте с enum в качестве кода возврата компилятор мне сразу накидает варнингов про все места где я использовал эту функцию, но не обновил работу с ней. Попробуй повторить это с исключениями. blindedНу в данном конкретном примере - элементарно cout<< rs[0] << flush < << rs[1] << flush << rs[2] << endl; Кстати а чем бы тебе помог код возврата? Я правда не спец в ADO или что оно там, вот только сомневаюсь, что ежели спросить у Exception what оно не скажет ничего о поле в котором произошла ошибка:)Ну ADO здесь ни при чем, это абстрактный резалтсет :) Читай топик, я там выше уже пытался объяснить как я предпочитаю делать оператор [] для резалтсетов. Но все таки, может мне кто-нибудь элегантно решить задачку перехвата недокументированых исключений? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2007, 23:04 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
ErV blinded WhiteOwl Код: plaintext 1. 2. 3. 4. Круто, я бы повесился. А чего же префикса имени ошибки не даешь? Каждой функции свой префикс ошибки!!! Для таких случаев в C++ есть отличная возможость все коды ошибок запихнуть в enum который можно засунуть в namespace или даже класс. И никаких префиксов по пять раз не понадобиться писать. Вообще рекомендую вам посмотреть исходники Qt как образец... Сознаюсь до этого не дошел, видимо потому что начал пользовать исключения... А QT , что QT? мне Java Swing нравится ErV Вы вот про обертки для интерфейсов писали. А что мешает вам нужные наборы функций обьединить в пространства имен или классы, в рамках которых (в области видимости) объявить коды ошибок? Обалденно от name clash'ей помогает.. Ну на вкус и цвет советчиков нет. Один любит арбуз, другой свиной хрящик. А посему мне классы ближе наборов функций. Видимо мы разные парадигмы предпочитаем ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2007, 10:54 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
blindedА QT , что QT? мне Java Swing нравится В исходниках синтаксис/стиль написания удачный. Имхо. Вот и все. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2007, 11:41 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
White Owl пишет: > И префиксы даю и enum из функции возвращаю. Очень удобно получается. > Смотришь исходник и с первого взгляда видно ошибки какой группы мы здесь > обрабатываем. Программисты делятся на две категории. Одни еще думают, что все ошибки в программе можно контролировать, другие уже понимают, что это невозможно. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2007, 12:35 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
ErV blindedА QT , что QT? мне Java Swing нравится В исходниках синтаксис/стиль написания удачный. Имхо. Вот и все. Не нравится препроцесоор, ненавижу! Только не надо агитировать или объяснять про препроцессор С. Сам писал кучу всего и на С, и на m4, и на embeded SQL и на idl. После всего осталось твердое убеждение что хороша та библиотека (пакет) которая использует только средства языка. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2007, 13:24 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
[quot White Owl blindedА вот на счет Perl'a это да Perl - это вообще не язык, это буйное помешательство вобравшее в себя весь возможный набор парадигм...Ну не надо. Perl это жемчужина со всех точек зрения. Обожаю Perl. Жаль что он мне сейчас по работе почти не нужен. [/quot] Какие мы однако разные. Но это в соседний форум. White Owl Кстати, в java еще на уровне компиляции есть замечательная штука - контроль за тем, чтобы все исключения брошеные вызваной функцией были хоть как-то обработаными. А в С++ такого контроля нету... Ну строгость законов смягчается необязательностью их исполененя. Запросто можно кинуть исключение не указав его в сигнатуре. Ну есть еще мерзкие исключения, которые вылазят наружу из самой java машины. Схватить NullPointerException или ClassNotFoundException святое дело. Ну и довольно забавно выглядит сигнатура метода у которого целый шлейф возможных исключений. Обычно после3-4 возможных исключений приходится рисовать свое собственное инкапсулирующее то, что могут сгенерировать использованные в методе вызовы.. White Owl Зато если функция возвращает enum, то вот например такой код: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. Код: plaintext 1. Здорово. Вы случаем не МехМат заканчивали? White Owl А представь что мы вызываем foo() из какой-нибудь чужой библиотеки, а потом однажды обновили эту самую чужую библиотеку и теперь foo() новой версии выдает больше (или вообще другие) ошибки чем в предыдущей версии. В варинте с enum в качестве кода возврата компилятор мне сразу накидает варнингов про все места где я использовал эту функцию, но не обновил работу с ней. Попробуй повторить это с исключениями. И не подумаю. У меня полнаяя сборка идет на Sun'e часа полтора (без тестов), потом еще неделю логи разбирать? Не могу себе позволить сие удовольствие. White Owl blindedНу в данном конкретном примере - элементарно cout<< rs[0] << flush < << rs[1] << flush << rs[2] << endl; Кстати а чем бы тебе помог код возврата? Я правда не спец в ADO или что оно там, вот только сомневаюсь, что ежели спросить у Exception what оно не скажет ничего о поле в котором произошла ошибка:)Ну ADO здесь ни при чем, это абстрактный резалтсет :) Читай топик, я там выше уже пытался объяснить как я предпочитаю делать оператор [] для резалтсетов. Прочитал и считаю что вы не правы. Null значение надо уметь выводить, а вот несуществующее поле - это извините меня - ошибка программы, несоблюдение контракта. И в такой ситуации надо аварийно завершаться. Ибо пользователь не советчик. White Owl Но все таки, может мне кто-нибудь элегантно решить задачку перехвата недокументированых исключений? Ну это примерно тоже что и поиск незадукоментированного кода возврата. В общем случае не решаемо, при наличии отладочной информации в модуле - с помощью отдачика ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2007, 15:56 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
OFFTOPIC: На shell используя kill - trap можно реализовать механизм обработки ошибок, подобный обработке исключений. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2007, 12:45 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
MasterZivНе, может быть можно и проигнорировать ошибку. Например, при сбое диска записать на другой. Ну дык этой сбой сначала нужно зафиксировать. Так что никакого игнорирования :). White OwlА наверх всегда уходит одна единственная ошибка: "плохой пакет". Следующий уровень уже решает повторить попытку посылки пакета или сообщить выше о потере связи Ну так в чем проблема? Ловим исключение и повторяем попытку. К вопросу исключения vs код возврата это уже не имеет отношение. Это во-первых. А во-вторых, принимая решение о том, кидать ли исключения или юзать код возврата, следует учитывать, насколько существеннен этот сбой для работы алгоритма. Если мы пишем текстовый редактор, и сохраняем файл на диск, нам все равно, что случилось с диском, главное - что запись невозможна. В этом случае следует кидать исключения. Если же мы пишем драйвер, то с его точки зрения сбой при записи - одна из возможных и ожидаемых ситуаций, и реакция на каждуй из них уже составляет часть реализуемого алгоритма. Поэтому в этом случае более естественно использовать код возврата. Собственно говоря, исключения и сущевтуют для того, чтобы упростить обработку ошибок по первому сценирию. Никто не говорит о том, что они должны полностью заменить коды возврата. White OwlГую надо обрабатывать только два типа ошибки - нет ошибки и обрыв связи. Почему же? Гую в праве обрабатывать любой тип ошибки, все зависит от поставленной задачи. Для этого и существует иерархия объектов исключений. Для приложений, ориентированных на "обыного" пользователя, ловим все подряд с помощью catch(exception&). Для специалистов, вводим более гранулярную обработку, с отдельным обработчиком на каждый тип. White OwlНо если ты сильно хочешь - можешь конечно сообщать гую о всех пакетах с неверной контрольной суммой или с потеряным хвостом Именно что сообщаем максимум инофрмации. Для самого пользователя или инженера техподдержки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2007, 14:12 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
blinded White OwlА представь что мы вызываем foo() из какой-нибудь чужой библиотеки, а потом однажды обновили эту самую чужую библиотеку и теперь foo() новой версии выдает больше (или вообще другие) ошибки чем в предыдущей версии. В варинте с enum в качестве кода возврата компилятор мне сразу накидает варнингов про все места где я использовал эту функцию, но не обновил работу с ней. Попробуй повторить это с исключениями. И не подумаю. У меня полнаяя сборка идет на Sun'e часа полтора (без тестов), потом еще неделю логи разбирать? Не могу себе позволить сие удовольствие. ээээ... А что, инкрементальную компиляцию уже отменили? Откуда неделя на разбор логов компилятора? make clean & make all И получаешь лог ошибок одного модуля. Исправил - make all получаешь ошибки другого модуля. А иначе тебе остается только надеятся на то, что там в библиотеке ничего серьезного не поменялось и она полностью совместима снизу-вверх. blinded White OwlНо все таки, может мне кто-нибудь элегантно решить задачку перехвата недокументированых исключений? Ну это примерно тоже что и поиск незадукоментированного кода возврата. В общем случае не решаемо, при наличии отладочной информации в модуле - с помощью отдачикаНеверно. В общем случае оно как раз решаемо. Я уже показывал как решается задача отлова недокументированого кода возврата, можно повторить синтаксис решения одни-в-один (обернуть каждую функцию в свой собственный try/catch блок) и точно так же ловить известные и неизвестные исключения, но это уже не будет работа в стиле исключений. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2007, 17:08 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
Беда в том еще, что исключения нужно обрабатывать всегда. А код возврата - нет. Поэтому мы и встречаем каждый день злобные сообщения "Unhandled exception...." ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2007, 12:30 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
вообще-то, если ошибка возникает и не обрабатывается – это ахтунг ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2007, 13:04 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
White Owl ээээ... А что, инкрементальную компиляцию уже отменили? Откуда неделя на разбор логов компилятора? make clean & make all И получаешь лог ошибок одного модуля. Исправил - make all получаешь ошибки другого модуля. А иначе тебе остается только надеятся на то, что там в библиотеке ничего серьезного не поменялось и она полностью совместима снизу-вверх. Нет конечно не отменили.Только это возможно в идеальном варианте. Когда изначально код доводился до блеска, а у меня чужого добра навалом, да и сам не святой. В такой ситуации на warning и не смотришь. Да и живем на нескольких компиляторах, что для одного в порядке вещей, для другого warning. Да и объем кода достаточно большой, а времени нет, все новые доработки требуют...:( blinded White OwlНо все таки, может мне кто-нибудь элегантно решить задачку перехвата недокументированых исключений? Ну это примерно тоже что и поиск незадукоментированного кода возврата. В общем случае не решаемо, при наличии отладочной информации в модуле - с помощью отдачикаНеверно. В общем случае оно как раз решаемо. Я уже показывал как решается задача отлова недокументированого кода возврата, можно повторить синтаксис решения одни-в-один (обернуть каждую функцию в свой собственный try/catch блок) и точно так же ловить известные и неизвестные исключения, но это уже не будет работа в стиле исключений.[/quot] Ну хорошо перехватили мы какое-то исключение, что с ним делать? Все равно программе предстоит падать, если исключение неизвестно мы не знаем тяжести его последствий и продолжать работу опасно... Теперь начинаем разборку 1) исключение сгенерировано кодом написаным нашей командой, ну тогда оно должно наследоваться от одного класса и содержать информацю для локализации места в котором его сгенерили. имя файла, строка кода. А кто сгенерирует что-то иное получит штраф к з/п 2) исключение сгенерировано сторонним кодом. Единственное что можно, если отнаследовано от std:exception попросить у него what() может чего и скажет и перейти к п 3 3) Смоделировать ситуацию и методом половинного деления найти причину. Отметим что вы по всей видимости имеете дело с открытым кодом, где проблему можно решить копанием в исходниках. У меняже ситуация хуже - используются коммерческие библиотеки. Все равно чтобы доказать неправоту автора придется делать тестовый пример... У нас уже набор всяческих тестов накопился. Приходит тебе новая версия, берешь и запускаешь... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2007, 14:28 |
|
||
|
Исключения: за и против
|
|||
|---|---|---|---|
|
#18+
blindedа у меня чужого добра навалом, да и сам не святой. В такой ситуации на warning и не смотришь. Да и живем на нескольких компиляторах, что для одного в порядке вещей, для другого warning.Фи! А я иногда специально прогоняю код через несколько разных компиляторов чтобы увидеть все возможные варнинги и исправить их. Кстати, по моим наблюдениями гнусь самая тщательная с этой точки зрения :) blindedНу хорошо перехватили мы какое-то исключение, что с ним делать? Все равно программе предстоит падать, если исключение неизвестно мы не знаем тяжести его последствий и продолжать работу опасно...Да, но падать можно красиво, а можно с грохотом :) blinded2) исключение сгенерировано сторонним кодом. Единственное что можно, если отнаследовано от std:exception попросить у него what() может чего и скажет и перейти к п 3В том то и дело что "может чего и скажет". А если не скажет? Тогда копаться, копаться и копаться. А коды возврата локализованы по определению. Если поймал что-то - уже с самого начала видишь место где ошибка была и сразу переходишь к пункту три. blindedОтметим что вы по всей видимости имеете дело с открытым кодом, где проблему можно решить копанием в исходниках. У меняже ситуация хуже - используются коммерческие библиотеки. Все равно чтобы доказать неправоту автора придется делать тестовый пример...В данном случае это неважно. В любом случае чтобы доказать неправоту автора надо делать тестовый пример. В открытой библиотеке это чуть проще сделать, но не намного. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2007, 17:19 |
|
||
|
|

start [/forum/topic.php?all=1&fid=57&tid=2029270]: |
0ms |
get settings: |
7ms |
get forum list: |
23ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
191ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
177ms |
get tp. blocked users: |
1ms |
| others: | 204ms |
| total: | 623ms |

| 0 / 0 |
