Здравствуйте, Alvin, Вы писали:
A>Как насчет использования bool System.Int32.TryParse(string s, out int result) в тех случаях, когда исключение не желательно?
В библиотеке .NET Framework version 1.1. такой процедуры нет. Во второй версии значит появилась? Хорошо, очень оперативно работают, молодцы.
Здравствуйте, Cyberax, Вы писали:
C>На самом деле, пример с платежами — очень хороший. Он заодно помогает проиллюстрировать понятие транзакций и их симбиоз с исключениями.
Так покажите код. Я на него посмотрю, и по образу и подобию перепишу его без exceptions. Ведь вся проблема (с моей стороны) в предметной области, а не в кодировании.
Здравствуйте, Sinclair, Вы писали:
S> механизма доставки информации об ошибке есть великое благо
Я начинаю понимать причину того почему Вы меня не понимаете.
Вы думаете, что если в языке (возьмем тот же Oberon или Component Pascal) нет встроенного (на синтаксическом уровне) транспорта доставки информации об ошибке, то этого транспорта нет вообще и в системах (возьмём тот же BlackBox). Однако, механизм доставки сообщения об ошибке есть всегда. Есть транспорт — просто он синтаксически не выражаем. (В конце-концов это просто некая архитектурная особенность процессора, а не синтаксическая особенность языка.) Вопрос лишь в том — куда доставляется эта информация? Кто ловит исключение? Её ловит сама система. Команда под BlackBox создав исключительную ситуацию (например по ASSERT, или NIL dereference, или деление на 0, и т.д.) не убивает саму систему BlackBox, а происходит лишь останов выполнения команды породившей исключение. BlackBox ловит порождённое исключение.
Программируя на языке Component Pascal в системе BlackBox я могу порождать исключительные ситуации сам. Только для этого я использую вовсе не аналог вот такого кода:
if ( ! condition) throw new Exception("error");
а вот такой код:
ASSERT(condition, err_no);
ASSERT — это служебное слово языка (ASSERT-ы Оберона отличаются от ассертов в других языках тем, что не игнорируются в релиз-версии). Порождённое таким образом исключение ловится system trap-ом которым снабжается каждая команда. Так что выполнение команды прекращается.
Короче, в Component Pascal в системе BlackBox исключения есть (равно как они есть всегда в силу архитектуры x86), просто их нет на синтаксическом уровне языка.
S> Я не могу себе представить библиотеку, способную предоставить все необходимые свойства без модификации языка. В лучшем случае это будут корявые костыли, которые лишь слегка замажут все эти наслоения.
Сергей Губанов wrote:
> CX>Вот такой вот *практический* опыт работы с исключениями, > реализованными на уровне библиотеки. > Посмотрите пожалуйста следующую статью (потрясающую воображение): > http://www.oberon2005.ru/paper/p_ex.pdf > *Zero-Overhead Exception Handling Using Metaprogramming*
И что тут необычного? Особенно если учесть, что оно не будет работать в
модульных системах.
Сергей Губанов wrote:
> C>На самом деле, пример с платежами — очень хороший. Он заодно > помогает проиллюстрировать понятие транзакций и их симбиоз с исключениями. > Так покажите код.
Вариант 1 (с транзакциями):
void transfer_money(Account *from, Account *to, Money money)
{
transaction transaction(...); //Создаем транзакцию
//Вводим объекты в контекст транзакции
LockedAccount *from_locked=from->enroll(transaction);
LockedAccount *to_locked=to->enroll(transaction);
//Перечисляем деньги
Transfer t(from_locked->get_money(money));
to_locked->add_money(t.get_money());
//Коммитим транзакцию
transaction.commit();
}
Или второй вариант, без транзакций и на Java для простоты:
void transfer_money(Account from, Account to, Money money)
{
Transfer t=from.get_money();
try
{
to.add_money(t);
t=null;
} finally
{
if (t!=null) t.cancel_transfer();
}
}
Здравствуйте, Andrei N.Sobchuck, Вы писали:
CX>>Вот такой вот практический опыт работы с исключениями, реализованными на уровне библиотеки.
ANS>Нужно добавить "... в С++". ANS>Никто и не сомневался
Да причем тут C++? Если бы это был стандартный C++, проблем бы не было. Но в том-то и беда, что это "улучшенный" C++. Вот так бывает, когда "улучшают", не подумав толком.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Посмотрите пожалуйста следующую статью (потрясающую воображение):
Ничего особенно потрясающего. Да, такую штуку можно реализовать для любого языка, который
а) поддерживает вложенные процедуры
б) поддерживает RTTI
в) разрешает библиотеке играть со стеком.
Кстати, вопрос с finally остался в статье неосвещенным, а очень зря. Дело в том, что на технике finally построено детерминистическое освобождение ресурсов (необходимое в системе без автоматических объектов).
Рассуждения по поводу таблиц и ресурсов на самом деле, мягко говоря, надуманны. Дело в том, что реализация опирается на метаданные, которые сами по себе тоже тратят место (по сравнению с чистым нативным кодом). Да, замечательно, что удалось обойтись без дублирования этих таблиц. Но сравнивать надо честно.
В целом — неплохая техника для обхода ограничения компилятора, неспособного предоставить достаточно удобный механизм.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Cyberax, Вы писали:
C>И что тут необычного?
Необычно то, что:
1) Zero-overhead;
2) не требуется вносить изменения в синтаксис языка Оберон.
C>Особенно если учесть, что оно не будет работать в модульных системах.
Так ведь уже работает:
...Our implementation was done in the Oberon System...
В первую очередь Zero-Overhead Exception Handling было реализовано как раз в модульной системе!
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Пять процентов головного мозга — это конечно шутка. Понимать надо не в биологическом смысле, а в переносном
Тогда вопрос: сколько процентов головного мозга приходится напрягать физику-теоретику в повседневной деятельности? В каком угодно смысле. Просто для сравнения.
Сергей Губанов wrote:
> C>Особенно если учесть, что оно не будет работать в модульных системах. > Так ведь уже работает: > ...Our implementation was done in the *Oberon System*... > В первую очередь Zero-Overhead Exception Handling было реализовано как > раз в модульной системе!
Нет, Rider должен видеть полный код моулей для своей работы.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Я делю ошибки на две категории: СГ>1) ошибки в данных (программа на вход получила неправильные данные); СГ>2) ошибки в программе (программист ошибся: а) просто ошибся; б) сложно ошибся — в дизайне/архитектуре).
СГ>Ошибки категори (1) легко обрабатывается без механизма exceptions, так надо проектировать просто. СГ>Ошибки категории (2) фатальные, тут программу надо завершать — в программе ошибка, т.е. программа не правильная. Использовать exception только для того чтобы правильно завершить работу программы (ну там закрыть открытые ресурсы), только для этого чтоли? Закрыть открытое можно и другими способами.
Дело в том, что при применении Вашего подходя, вызвавшего такую бурную дискуссию, разработчи сталкивается со следующим известным вопросом:
Сколько return должно быть в функции? Один или несколько ?
А этот вопрос Гораздо старей Вашего. Следовательно можно предположить что исключения полезны, как минимум, потому, что позволяет в большинстве случаев абстрагироваться от проблемы колва точек выхода из функции.
M>В процессе эксплуатации оказалось, что ХМЛ в 99% случаев приходит валидный (так как я сам его и отсылаю ). Вопрос. Нафига мне там столько if-ов? Когда документ начинает расти, код читать становится неприятно.
Дык и зачем сразу использовать исключения ????
Все гараздо проще
M>
M>void displayReservationCommand::execute()
M>{
M> QDomDocument xmlDoc;
M> xmlDoc.setContent(_params["data"]);
M>// try{
M> QDomElement el = xmlDoc.documentElement();
M> el = el.firstChild().toElement();
M> QString str;
M> QTextStream ts(str, IO_WriteOnly);
M> el.save(ts, 0);
M> QString attr = el.attribute("guid", "-1");
M> iqAdrReservationApplicationForm::displayReservation(attr, str);
/*
M> }catch(... /*на самом деле здесь надо что-нить типа XMLTagError, но мне все равно.*/){
M> return false;
M> }
M> return true;
*/
M>}
M>
И тогда все свалится в каком-то другом месте, неважно в каком потому как информация о месте и характере ошибки не важна Автору топика.
Кстати, подобный подход, исходя из предпосылок ГОРАЗДО эффективней исключений, функция без них будет работать быстрей и что немаловажно, в 98% случаев — правильно.
Здравствуйте, Privalov, Вы писали:
P>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>Пять процентов головного мозга — это конечно шутка. Понимать надо не в биологическом смысле, а в переносном
P>Тогда вопрос: сколько процентов головного мозга приходится напрягать физику-теоретику в повседневной деятельности? В каком угодно смысле. Просто для сравнения.
кандидату: 100% от нормы обычного человека, доктору: 500% — 1000% от нормы обычного человека академику, ну скажем, 20'000% от нормы....
Здравствуйте, Сергей Губанов, Вы писали:
СГ>В первую очередь Zero-Overhead Exception Handling было реализовано как раз в модульной системе!
Я бы не стал утверждать, что первая реализация zero-overhead EH была реализована в Oberon. Существуют два основных подхода к реализации исключений — "code" and "table" approaches:
В "code" подходе все структуры, связанные с обработкой исключений располагаются в стеке и непосредственно в секции кода процедур. И обработка исключений происходит небесплатно, даже при "безошибочном" выполении программы.
В "table" подходе все структуры, связанные с обработкой исключений, располагаются в специальных таблицах в read-only памяти и задействуются только при выбрасывании исключения. Насколько я понял, это и есть тот самый zero-overhead, описаный в статье. Для C++ это уже не совсем zero-overhead, поскольку этот подход требует дополнительных таблиц, иногда не маленьких. Но в Обероне этот оверхед встроен by design.
Что касается компиляторов, то vc++ использует code approach поверх платформенных исключений x86. А g++, если не ошибаюсь, использует то один, то другой подход в зависимости от целевой платформы.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Посмотрите пожалуйста следующую статью (потрясающую воображение):
For system exceptions, which are triggered automatically, the system will generate a call to the
procedure Raise as if they were user exceptions.
Не совсем понял, system это что ? Операционная стистема ? Значит ли это, что операционная система должна знать о каждой библиотечной схеме исключений, что-бы вызвать соответствующий Rise ?