Так вот Мейер в качестве одной из дисциплин обработки исключений определяет "Повторение" (Retrying), но об этом чуть ниже. SJA>Жаль, но там нет ссылки на онлайн версию... В наших магазинах я такой книги не видал.
Единственно, что Мейер об исключениях говорит со своей колокольни, поэтому мне показалось, что у Страуструпа про исключения лучше написано. Лаконичнее, практичнее и ближе к мейнстримовым языкам (C++, Java, C#).
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, reductor, Вы писали:
E>>Корректно работающий в соответствии со спецификацией код совсем не обязательно выполняет то, что предполагалось.
R>Корректно работающий в соответствии со спецификацией код, делает то, что предполагалось в спецификации с несколько большей вероятностью, чем код, который ей не соответствует. И есть формальный аппарат, позволяющий это проверить. R>Если есть данные или другой аппарат, позволяющие это оспорить и доказать, что наоборот — буду рад услышать.
К счастью, мне не приходилось вообще заниматься формальным доказательством корректности работы программы. Читали нам в универе какой-то спецкурс по этому поводу, но это было уже очень давно. Единственное, что помню, так это скептическое отношение самого преподавателя к данной теме. И еще он вспоминал какую-то программу, на одну страничку объемом, для которой на пяти страницах текста было формально доказана правильность ее работы. К сожалению, программа работала не правильно.
E>>Это эмпирический вывод, основывающийся на том, что: E>>a) спецификации так же содержат ошибки; E>>b) заказчик может не суметь четко описать свои пожелания и ожидания. E>>Доказать я его не могу.
R>А вот это уже лирика, к делу не относящаяся. Методов, чтобы определить в каком состоянии писал заказчик спецификацию и писал ли вообще, а не сгенерировал генератором матерных слов, я не знаю. Себе спецификации я стараюсь писать сам. Формальные и без противоречий (это очень просто).
Еще как относится. Поскольку платят не за то, насколько полно программа соответствует спецификации, а насколько полно делает то, что от нее требовал заказчик.
... << RSDN@Home 1.1.4 stable rev. 510>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Privalov, Вы писали:
P>Данные у нас правильные по определению, функция enroll на заблокированную базу данных нарваться не может опять же по определению. Rollback не бывает. Об остальном я, пожалуй, промолчу.
Всё учтено в процедурах: BeginTransfer, EndTransfer; а так же в процедурах-функциях: Enroll, GetMoney, AddMoney, Commit.
Здравствуйте, IT, Вы писали:
IT>А теперь добавь сюда какую-нибудь вменяемую информацию об ошибке, сделай так чтобы TransferMoney возвращала новый баланс счёта и протащи это через 4-5 вызовов.
Легко. Приведите код с exception, а я его переделаю в код без exception. Да, и еще у меня будет большая просьба: после того как я это сделаю — уже ни когда не предлагать делать это еще раз — сколько можно одно и тоже писать? Смысл-то как это делается и так уже понятен.
E>К счастью, мне не приходилось вообще заниматься формальным доказательством корректности работы программы. Читали нам в универе какой-то спецкурс по этому поводу, но это было уже очень давно. Единственное, что помню, так это скептическое отношение самого преподавателя к данной теме. И еще он вспоминал какую-то программу, на одну страничку объемом, для которой на пяти страницах текста было формально доказана правильность ее работы. К сожалению, программа работала не правильно.
Ок. Вы правы
R>>А вот это уже лирика, к делу не относящаяся. Методов, чтобы определить в каком состоянии писал заказчик спецификацию и писал ли вообще, а не сгенерировал генератором матерных слов, я не знаю. Себе спецификации я стараюсь писать сам. Формальные и без противоречий (это очень просто).
E>Еще как относится. Поскольку платят не за то, насколько полно программа соответствует спецификации, а насколько полно делает то, что от нее требовал заказчик.
Ок. Вы правы.
Во всем. Больше мне добавить или прокомментировать нечего.
Здравствуйте, vdimas, Вы писали:
V>На самом деле, применительно к доводам использования exception используется другое разделение:
На самом деле, применительно к доводам использования exception, я привёл (мою) классификацию ошибок: (1) ошибка в данных, и (2) ошибка в программе. Сказал что для обработки ошибок в данных exception не нужны, а для обработки ошибок в программе довольно ASSERT + system trap, так что опять exception не нужны. Вы против этого что-то имеете конструктивно возразить?
IT wrote:
> C>В С++ сработавший assert вызывает функцию DebugBreak, так что > поймать ее > C>сложно будет. > Not big deal.
Если постараться, то и на Луну можно слетать.
> Все asserts идут лесом.
Тогда можно написать функцию, которая будет писать в лог stacktrace, а
потом кидать исключение.
> Но дело даже не в этом. Ты собираешься на любую возможную ситуацию в > программе писать assert? Этак у тебя на 10 строчек кода должно быть 20 > asserts.
Не совсем так, но близко. Заодно помогает прояснять контракты использования.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Всё учтено в процедурах: BeginTransfer, EndTransfer; а так же в процедурах-функциях: Enroll, GetMoney, AddMoney, Commit.
Я не знаю, насколько этот код верен с точки зрения исключений. Смущает меня, однако, что функции, работающие с удаленным счетом:
1) блокируют всю работу с нашим счетом;
2) держат открытым канал связи в течение всего времени работы;
3) не дают вразумительного ответа, почему транзакция не прошла.
При переводе денег куда-нибудь в Уругвай, при таком подходе, связь будет клиенту не по карману.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Легко. Приведите код с exception, а я его переделаю в код без exception. Да, и еще у меня будет большая просьба: после того как я это сделаю — уже ни когда не предлагать делать это еще раз — сколько можно одно и тоже писать? Смысл-то как это делается и так уже понятен.
Здравствуйте, Privalov, Вы писали:
P>Я не знаю, насколько этот код верен с точки зрения исключений. Смущает меня, однако, что функции, работающие с удаленным счетом: P>1) блокируют всю работу с нашим счетом; P>2) держат открытым канал связи в течение всего времени работы; P>3) не дают вразумительного ответа, почему транзакция не прошла. P>При переводе денег куда-нибудь в Уругвай, при таком подходе, связь будет клиенту не по карману.
Эти вопросы не ко мне, а к автору кода. Я всего лишь переписал предложенный код содержащий exceptions в аналогичный мой код их не содержащий.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Легко. Приведите код с exception, а я его переделаю в код без exception. Да, и еще у меня будет большая просьба: после того как я это сделаю — уже ни когда не предлагать делать это еще раз — сколько можно одно и тоже писать? Смысл-то как это делается и так уже понятен.
Если хотите, можем оставить банковскую тему. Вот еще вопрос: Вы пишете программу, вычисляющую значения функции y=f(x) на интервале [a, b]. Программа не знает, какую функцию ей предстоит вычислять. Что она должна делать, если знаменатель (если он есть) обращается в 0? Или если в какой-нибудь точке функция не определена?
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Легко. Приведите код с exception, а я его переделаю в код без exception.
Ок. Напишите маленький кусочек кода, который инициирует перевод денег и отображает ошибку пользователю.
С исключениями:
// Информация об ошибке.class TransactionException
{
char * Description;
}
// попытаемся....try
{
transfer_money(from, to, modey);
}
catch(TransactionException &e)
{
ShowMessage("Trans error. Reason: " + e.Description);
}
При появлении ошибки в ф-иях GetMoney, AddModey ... генерируется исключение, заполняется поле Description.
Ваш ход конём! Тобиш обероном.
СГ> Да, и еще у меня будет большая просьба: после того как я это сделаю — уже ни когда не предлагать делать это еще раз — сколько можно одно и тоже писать? Смысл-то как это делается и так уже понятен.
Одно и тоже не будем. Будем "развивать" систему.
reductor,
> V> Например, в С++, опять ресурсы и коды возвратов:
> Ну если дело только в этом конкретном коде, то: >
> if (error( openRes1() )) return ERR_RESOURCE1;
> else if (error( openRes2() )) return ERR_RESOURCE2;
> else if (error( openRes3() )) return ERR_RESOURCE3;
> else return ERR_SUCCESS;
>
> формальнее некуда >
Здесь упущена существенная деталь, присутствовавшая в оригинальном варианте: освобождение ресурсов в каждом из случаев (в оригинале это делали деструкторы).
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
using (TransactionScope scope=new TransactionScope())
{
//здесь код, любой который может быть использующий данную транзакцию
.......
scope.Complete();//подтверждение транзакции.
}
public class TransactionScope:IDisposable
{
private DBTransaction _trans;
private bool _commited=false;
public TransactionScope(){_trans=new DBTransaction();};
public Complete(){_trans.Commit();_commited=true;};
public void Dispose()//для сишников - это аналог деструктора
{
if (!_commited)_trans.Rollback();
}
}
Транзакции наплевать, что было — ошибка бизнес-логики или OutOfMemory.
С уважением, Gleb.
Сергей,
> я привёл (мою) классификацию ошибок: (1) ошибка в данных, и (2) ошибка в программе. Сказал что для обработки ошибок в данных exception не нужны
И? Обоснование этого пункта будет? (С учетом последовавших реплик о проблемах с зависимостями промежуточных уровней от исключительных ситуаций, возникающих на нижних уровнях, и обрабатывающихся на верхних.)
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>И? Обоснование этого пункта будет? (С учетом последовавших реплик о проблемах с зависимостями промежуточных уровней от исключительных ситуаций, возникающих на нижних уровнях, и обрабатывающихся на верхних.)
Я так понял, что все свелось к идее протаскивания абстрактного Exception в виде возвращаемого значения, которое проверяется на каждом уровне. Как эта идея согласуется с отсутствием "синтаксического оверхеда" — я не понял
Здравствуйте, reductor, Вы писали:
R>Я? представляю, а что? R>А можно ли услышать что такое "реальные объемы"? А то может у меня какие-то они нереальные, мало ли. R>И почему даже если так, то нужно делать код менее верифицируемым, чем можно?
Кстати, сам я тоже склоняюсь к мысли, что по-возможности надо верифицировать код, а не побочные эффекты его работы. Заявление о том, что "раз программа прошла все тесты, значит она правильная" не вызывает у меня ничего, кроме скепсиса.
Однако, "реальные объемы кода" — это такие объемы в пересчете на одного разработчика, которые приняты сейчас в реальных проектах. Если С++ программист должен выдавать от 200 и до... (иногда 400-600) строк в день, то верификация таких объемов займет в разы больше времени и потребует гораздо более дорогих в почасовом плане ресурсов, чем ресурс автора целевого кода. В общем подход, основанный на полной верификации кода элементарно неприемлим для многих контор.
Однако — не беда. Разделение приложения на уровни ответственности, максимальное повторное использование и т.д. позволяют разделять код по уровню "критичности" (читай — по уровню повторного использования), и на основе подобного разделения кода строится разделение труда. Не секрет, что над каждым отдельным куском проекта работает минимально небходимый по уровню разработчик. Эта ерунда еще называется "грамотным управлением ресурсами".
Т.е. в рельной селяви присутствует совсем небольшой объем кода, который выполняют разработчики соответствующего уровня, чей код может пройти верификацию. И все-равно эту верификацию никто не делает (не знаю как у военных и космических контор), а просто "верят человеку на слово", выплачивая нехилую ЗП за его декларируемый/доказанный проффесионализм.
Далее, насчет пресловутого if-else. Разумеется, что если некое действие имеет некий эффект, то этот эффект необходимо проверить полностью (не только по if-else, возможны множественные проверки по switch-case), с этим никто не спорит.
Другое дело, что писать else после return не рекомендует даже MSDN, и я тут полностью соглашусь, ибо ответвление в else здесь происходит само "механическим" образом. Зато как бенефиты мы повышаем читабельность (меньше уровней вложенности, скобок {}, begin-end и т.д.), и кое-где говорится о повышении эффективности (слабо верится для современных компиляторов).
Сделаю акцент еще раз на том факте, что корректное поведение программы в случае использования множественного return в неожиданных местах обычно обеспечивается доп. ср-вами самого языка. В С++ это автоматический вызов деструкторов локальных объектов (что крайне удобно, т.к. эти деструкторы вызываются только для реально инициализированных локальных переменных), в Java/C# есть try-finally для анаолгичных целей (не столь элегантно, но тоже вполне можно использовать).
Таким образом, верификация даже такого кода может быть полной. Другое дело, что мы не сможем верифицировать отдельно взятый участок (вернее можем, поясню далее), т.е. необходимо больше информации, о том, что происходит "неявно" для случая С++. Однако, и здесь нас ожидают бенефиты. Мы можем построить верификацию кода иерархически, т.е. проверифицировать сначала "прочистку", а затем код, использующий ее неявный вызов. Ввиду того, что целевой код неплохо сокращается в случае множественного return (или использования exceptions как продвинутой разновидности), мы можем получить как раз больше возможностей для верификации на "реальных объемах".
-----------
Кстати, ты писал, что ничего не имеешь против exceptions. Тем более странно твое отрицание множественного return. Для меня эти возможности как бы равнозначные, с тем отличием, что exceptions — это автоматизированная разновидность обсуждаемого + возможность синтаксически обощать места кода по обработке ошибки.
Предвижу замечания, насчет того, что exceptions в первую очередь — это возможность создавать и обрабатывать ошибки на разных уровнях, однако в момент обратной раскутки стека это именно равносильно последовательному выполнению некоего return на всех вложенностях после ошибочного оператора.
