Здравствуйте, Павел Кузнецов, Вы писали:
>> Это потому как С++. Я в когда пишу на Шарпе throw пишу там где вижу, что некоторая ситуация не являетс штатной для данного кода.
ПК>Гм... А можно поинтересоваться, в чем разница с C++?..
Можно. Граблей рядом нет и не приходится постоянно оглядываться бросая исключения не попадет ли она на них.
>> Ну, там параметр кривой — throw. Обязательный файл не найден — throw...
ПК>Т.е. логические ошибки и исключительные ситуации в этом отношении ты не разделяешь?
Это еще почему? Логические ошибки вообще контролировать нельзя. На то они и ошбки. Если ты о незапланированных исключениях, то это данность. И боросться с ней нужно только там где без этого никак.
... << RSDN@Home 1.2.0 alpha rev. 578>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>-1. При недостаче памяти в C++ вылетает std::bad_alloc.
Да, тут я зря экстраполировал поведение фрэймворка на С++. Согласен. Но есть и исключения вроде переполнения стэка которые точно не предсказать и гарантированно не обработать.
>> Ну, да при OutOfMemoryException уже мало что можно поделать. Памяти то нет и обрабатывать исключение просто не чем.
ПК>-1. После раскрутки стека и, соответственно, освобождения некоторой памяти вполне может образоваться нужный запас.
Это уже лотерея. Хватит... не хватит... Если ты получил отлуп при заеме большого обхекта, то возможно дальше что-то и можно сделать. А если маленького?
Ну, и опять таки. Есть и примеры вроде переполнения стека. Тут уж и застраховаться от него не выйдет и обработать в большинстве случаев не выйдет. Короче приплыд. И ничего С++ тут гарантировать не может. О чем речь совственно и шала.
>> А вот NullReferenceException очень даже обрабатывается. При этом в большинстве случае C#-ные приложения продолжают работать дальше, а большинство С++-ных выпадает "в осадок".
ПК>NullReferenceException — типичная логическая ошибка.
Что называть логической, а что физической? Ты бы объяснил свою терминологию. К примеру, если я забы проинициализировать ссылочкную переменную, то это логическая ошибка или по невнимательности/опечатка?
ПК> Внешнему коду доверять странно, если он передал нулевую ссылку там, где этого делать нельзя. Соответственно, надеяться на то, что внешний код корректно "восстановится", тоже не приходится: он уже находится в каком-то невалидном состоянии, на которое не рассчитывали при его разработке.
Ой, ой, ой. Просто град из каких-то не определенных понятий. Что за "внешний код"? Что за доверять? Почему состояние стало обязательно каким-то не таким?
ПК>Попытка "восстановления" после подобной ошибки
Какой такой подобной? Что-то тебя не понять. То ли ты обощашь до нельзя, то ли наоборот говоришь о каком-то одном случае. А ситуации разные бывают.
ПК> зачастую приводит к попаданию в нормальный поток исполнения с нарушенными инвариантами, после чего приложение скорее не работает, чем работает. Т.е., в случае управляемых сред, оно при этом обычно не "падает", но это даже хуже, т.к. у пользователя создается иллюзия исправной работы, в то время, как "внутри" уже самый настоящий глюкодром.
И где на такое посмотреть? Не, я верю, что и такое бывает, но вот твое "обычно" как-то с моими наблюдениями не очень совпадает.
ПК> Это очень легко наблюдать на многих приложениях, написанных на Java и C# в случаях возникновения непредусмотренных исключительных ситуаций.
Не, не нужно брасаться пространными фразами о многих приложениях (их и в природе то нет). Ты пальцем ткни. Вот приложение... а вот "это даже хуже, т.к...". А то больно на чьито выдумки похоже.
ПК> Т.к. чтоб работать в случае нарушенных инвариантов, нужно проверять все на свете, что, очевидно, сделать невозможно.
Ну, а теперь давай отойдем от твоих обвинений управляемых сред в издевательствах над бедными пользователями и проанализируем несколько ситуаций из реальной жизни подкрепив их конкретными примерами.
Итак... Ситуация 1. Мы имеем десктоп приложение написанное на дотнете с использованием винформсов и потому во всю использующее событийную модель работы.
Все действия пользователя превращаются в некие события которые рано или поздно находят свои обработчики. Другими словами при появлении тех или иных внешних событий программа идет по разным путям выполнения. Какие-то пути вызываются часто, какие-то не очень. Но в основм все они модифицируют состояние модели или изменяют настройки представления. При этом в прграмме может оказаться несклько путей с ошибками. Если жить по приципу "все или ничего" исповедумом по умолчанию большинством С++-ных ГУИ-фрэймворков, то баг даже в самой незначительной функции приведет к выподанию в осадок всег приложения (что мы за частую и види). Обоснование этому поведению очень простое — а если баг произошел в следствии повреждения памяти? Данные модели могут быть испорчены и пользователь потеряет не только не записанные данные, но и весь документ? Логично? Почти...
ГУИ-фрэймворк дотнета — ВинФормс — придерживается другого паттерна. Если приложение запущено не под отладчиком, появлении необработанного события, он выдает диалог в котором показывает информацию об ошибке, дополнительную информацию (вроде кол-стэка) и предлагает завершить преложение или продолжить его. При выборе "продолжить" он просто продолжает разбор очереди собщений потока. Другими словами происходит прекращение обработки текущего обработчика и начинается обработка нового.
Конечно если вызванная команда критически важна для приложения или она привела в несотвествие его моедль, то тут уж ничего не попишишь и мы действительно увидим так красочно описанную тобой страшную картину апокалипсиса. Но вот твои слова "обычно" и "еще хуже" явно являются попыткой выдать желаемое за действительное. Обычно ошибки седят в далеко не самых важных частях программы и обычно же модельприложения не приходит в неопределенное состояние. Обычно как раз в таких случаях можно просто ткнуть Continue и продолжить работать дальше избегая вызова данной команды. По крайней мере после этого можно хотя бы записать не записанные данные (хотя бы и под другим именем... на всякий пожарный). Серьдечко у пользователя конечно ёкнет при этом, но инфркт не случится. Данные то ведь не потеряны. А это главное!
Вот тебе простенокий пример того как это происходит:
using System;
using System.Windows.Forms;
using System.Drawing;
public partial class Form1 : Form
{
public Form1()
{
FlowLayoutPanel layout = new FlowLayoutPanel();
Controls.Add(layout);
Button button1 = new Button();
button1.Text = "Нажми меня!";
button1.AutoSize = true;
Button button2 = new Button();
button2.Text = "Не жми меня!";
button2.Font = new Font(button2.Font, FontStyle.Bold);
button2.AutoSize = true;
layout.Controls.Add(button1);
layout.Controls.Add(button2);
button1.Click += delegate { MessageBox.Show(this, "Усё ОК!"); };
button2.Click += delegate { throw new Exception("Случилос страшное!"); };
}
[STAThread]
static void Main()
{
Application.EnableVisualStyles();
Application.Run(new Form1());
}
}
Запусти его не под отладкой и по нажимай на кнопочки.
Причем это не гипотетический пример. В Янусе я частенько наталкивался на подобные "вылеты" и был сильно рад, что мне позволили продолжить работу сохранив пару-тройку недописанных сообщений.
Другой пример — веб-приложение. Или, если быть конкретным, www.rsdn.ru. Великий и могучий ПК не делающий ошибок и потому способный писать безглючные программы не удасужился помочь в разработке сайта, по этому его пришлось делать нам смертым. Так вот временами случаются баги. И как водится баги бывают разными. Бывают такие, что весь сайт работать не может. А бывают и по проще. Ну, там в диалоге регистрации нового юзера NullReferenceException вылетит. Или там в int.Perce кто-то без проверки буковки засунит, а сайтостроители просмотрели. Так вот юзер живет в сессии. А сессия крутися в отдельном потоке. Схлопнется, естествнно именно этот поток. Причем поток благополучно уйдет в пулл и будет использован повторно. И даже самый страшный SteckOverflowException не повалит весь сайт. И как не странно таких случаев (когда ошибка локальна) встречается куда больше чем таких когд весь сайт становится не работоспособным. Опять таки объясняется это просто — ошибок больше в редко используемом коде. А он обычно не является очень важным для всего сайта.
Хуже дела обстаят с пакетными задачами. Ну, теми что чаще всего оформляются в виде утилит командной строки. Вот они зачастую не выдерживают необработанных исключений, так как в них есть только один связанный поток исполнения. Хотя и тут бывают исклчения. Бывает, что задача делится на несколько важных блоков и вылет одного из них не так критичен как вылет всех. Ести функции таких потоков обрамлять try/catch-ами, то глядишь пользователи скажут спасибо.
ПК>Вообще же, в более строгих случаях, для приложений с критическими требованиями, попытки продолжения работы после диагностирования логической ошибки традиционно недопустимы: в таком состоянии приложение должно максимально коротким путем завершить свою работу, при необходимости сохранив текущие данные. Далее, в случае серверного приложения -- задача watch dog сохранить crash dump, log файл и т.п., и перезапустить приложение.
Бывает и так. Вот только в "при необходимости сохранив текущие данные" верится с трудом. Обычно все банальнее. Максиму что сохранятется — это дамп памяти доктором ватсоном.
Вот только приложения в которых действительно будет польза от такого поведения очень не много. По крайней мере не больше чем тех что получают выгоду от продолжения работы.
А вот приложений которые выпадают в осадок и при этом теряют данные хоть дтбавляй. Я сам не раз матерился после таких случаев. И все отмазки вроде "так будет лучше..." при этом только разрдажают.
ПК>В обсуждении, на которое ссылка уже давалась, этот момент подробно рассматривается.
О! Это не та место где можно действительно услышать не предвзятое мнение. Все же небезопасность самого языка накладывает печать на мышление. Все же жить без физической порчи данных куда проще и исключения при этом уже не выглядят такими уж страшными.
ПК>В частности, приводится вполне наглядный пример диагностики в системе автоматического пилотирования отрицательной высоты. Что бы ты в этом случае предпочел, пребывая в самолете: чтоб система пыталась "восстановиться", и продолжить управление, как ни в чем не бывало, или же чтоб она все-таки завершила автопилотирование в надежде на независимые резервные системы с последующим переходом на ручное управление, буде те также откажут?
Прежде всего я думаю, что пример это надуманный для 90% посетителей сайта (возможно я перестраховывась).
Ну, и я бы предпочел, чтобы я не разбился. Если система может гарантировать, что сбой произошел в неважной части и при этом не будет испорчена память, то я бы ередпочел какоий-нить мягкий режим отключения при котором у пилотов появилась бы надпись "Произошел сбой ххх. через ууу секунд автопилот будет отключен, нежели выход самалета в штопор в следствии того, что пилот в этот момент трепался с секретаршей.
В прочем, это настолько малоизвестная мне область и на столько далекая от меня, что я даже не хочу тут серьезно задумываться. Ведь это только один случай из тысячи. И за отмазку он не канает.
... << RSDN@Home 1.2.0 alpha rev. 578>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Сборка N: ПК>
ПК>void g( I i )
ПК>{
ПК> i.f(); // И какой список здесь должен генерировать компилятор?..
ПК> // Какие сборки будут подгружены, кроме данной, и от какого класса придет I — :xz:
ПК>}
ПК>
Ты имешь в виду, что бы я хотел видеть? Мне было бы достаточно документации на методы. Причем даже достаточно просто текстовой документации. На интерфейсы даже не обязательно. Я и так смогу узнать, что за объекты мне предстоит использовать.
Я не хочу 100%-ного решения. Мне достаточно дополнительной информации.
... << RSDN@Home 1.2.0 alpha rev. 578>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Вот я и спрашиваю: раз ты предполагаешь, что компилятор в данном случае должен был посчитать, что f() ПК>имеет пустую спецификацию исключений, то по какому алгоритму он действовал?
Ну, интерфейсы и виртуальные методы в таком случае можно было бы специфицировать (как в Яве). Хотя и это мого может хватить чтобы усложнить жизнь. Но уж точно это будет проще чем прописывать все ручками.
... << RSDN@Home 1.2.0 alpha rev. 578>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
>> E>будет генерировать исключения или нет. Конечно, можно >> перестраховаться и все неизвестные функции в try/catch обрамлять >> (особенно в деструкторах). Но ведь это overhead не слабый получается. >> А зачем обрамлять то? Пропускай их и все. Если появится код которому >> по его логие потребуется обработать исключение, то он и будет знать >> что и как обрабатывать.
C>А откуда он будет это знать?
Программист скажет. Ну, вылетит программка при тестировани... программист подсмотрит тип исключения и обработает его. Или из документации прочитает. В общем, не важно откуда.
... << RSDN@Home 1.2.0 alpha rev. 578>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Движутся ли mainstream языки в сторону лиспа?
M>Кстати может кто-нибудь попытается сформулировать какое-нибудь обобшенное определение?
Ну, не очень хорошое, но все же есть в википедии http://en.wikipedia.org/wiki/Exception
M>Кстати возврашаясь к Лиспу, т.к. там при "исключении" (ну а точнее сигнале) стек может и не уничтожатся, объекты под GC не попадают, и есть возможность продолжить с того же места, так что понятие той самой ИСКЛЮЧИТЕЛЬНОЙ ситуации для него будет IMHO неприменимо.
В Лиспе многое через зданицу. Менее экстремальные языки реализуют continuation-ы явно и подобных проблем не имеют. В общем, я не знаток лиспа, но точно могу сказать, что использование исключений для управления логикой программы точно не верное решение.
... << RSDN@Home 1.2.0 alpha rev. 578>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>Смотрели, чтобы оно было обработано. Просто эти товарищи пишут 24x7 C>систему, которая должна работать как можно безглючнее.
C>У них это, кстати, получилось. За мой опыт работы с Tangasol C>Coherence'ом мне его свалить не удалось ни разу.
Намекну тебе, что ты сейчас общашся с одним из авторов этого сайта который написал львиную долю кода для этого сайта. Так вот, как близкий к слежением за работой сайта берусь утвержадать, что наш сайт работает 24 часа 7 дней в неделю и перезагружается в основном только если пришел какой-то новый апдэйт требующий перзагрузку или проинсталирован нерадивый софт. И что характиено написан он на C# в котором нет Checked exceptions. Правда это никак не мешает сайту работать годами без перезагрзки и даже модифицироваться на ходу.
... << RSDN@Home 1.2.0 alpha rev. 578>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>А как насчет прибить поврежденные данные и пересинхронизировать их с C>других узлов?
Здорово. Именно этим занимаются те тысячи исключений в Ant-е (или где еще там?)?
C>Нужно следить не столько за типами исключений, сколько за возможностью C>вылета "прикладных" исключений. То есть не логических ошибок в коде, а C>исключительных ситуаций в процессе работы.
Вот за "прикладные исключения" нужно морду бить. Причем сильно и жестоко.
... << RSDN@Home 1.2.0 alpha rev. 578>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Единственное, что в C#, действительно, мало, что изменится от того, что было выброшено OutOfMemoryException: при раскрутке стека память автоматически не освобождается, так что вся надежда на сборщик мусора. Интересно, может, он как-нибудь специально реагирует на OutOfMemoryException?
Он неплохо реагирует на:
GC.Collect();
... << RSDN@Home 1.2.0 alpha rev. 578>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Отчего же? Если памяти освободится недостаточно, при первом же запросе снова будет ПК>выброшен std::bad_alloc, и мы "вылетим" еще выше по стеку, освобождая еще больше ПК>памяти, и так, пока не освободится ее достаточное количество, или, если память заняло ПК>другое приложение, пока наше приложение не завершится в связи с недостаточностью ПК>ресурсов для работы.
Представил себе эту ситуацию. Прикольно! Такое бесзбойное приложение вылетающиее ровно столько чтобы начать хорошо работать. В таких приложениях нужно заранее в стек по больше ссылок на объекты запихать, и поглубзе влезть в процедуры... ну, чтобы вылетать действительно долго.
ПК>В C++ процесс освобождения памяти вполне детерминирован. В чем проблема-то?
В том, что это красивая сказака не имеющая ничего общего с жизнью.
A>> Это может быть совершенно произвольная ошибка.
ПК>Например?
Пример произвольной ошибки? Кррруто!
ПК>Нет, я полагаюсь на систему, которая сгенерирует аппаратное исключение в ответ на разыменование нулевого указателя, и далее в дело вступит мой обработчик данного исключения, и создаст снимок стека или дамп, чтоб я мог определить, в чем же, собственно, ошибка.
А ты для какого рынка программы то пишешь?
ПК>С точки зрения устойчивости приложения некорректно порождать исключение при обнаружении логической ошибки. Нужно обеспечивать внешние резервные средства, и исправлять ошибку, а не маскировать ее исключениями.
Действиетльно. Ну, тебе виднее. Правда дотнетные и явовские приложение которые с этой твоей точкой зрения не согласны наботают все же надежнее, но разве это что-то даказывает? И опять же это вседа можно пиаром назвать...
A>> Ни разу не сталкивался. Вон янус в настоящий момент после любых A>> необработанных исключений в процессе работы продолжает жить.
ПК>Вот на нем-то я как раз недавно и наблюдал типичный упомянутый глюкодром. Произошло ПК>как раз после исключения в ответ на разорвавшееся соединение во время синхронизации.
Паша, ты использовал Янус? А можно поглядеть на отправленные тобой сообщения?
Что-то мне не верится, в то что ты вообще его использовал. Янус как раз при проблемах со связью умудряется работать даже когда к серверу нельзя пробиться из броузера или через почту.
ПК>После этого, даже когда соединение вернулось, ни одна синхронизация не проходила, ПК>сообщая что-то о вновь возникшем исключении.
Ладно, поверим тебе. Но скажи мне, что было бы если в момент синхронизации (которая может начаться и по таймеру) ты будешь писать сообщение? Ты действительно настолько фанатично предант своей идее "что лучше честно вылететь", что будешь готов потерять все незаписанные сообещиния или все же предпочтешь реработающую синхронизацию? Ведь даже если она не работает презагрузить Янус никто ведь не мешает. Првда?
ПК>И так было, пока я не перезапустил приложение.
Беда. Надо было класть приложение. Причем лучше в плюсовом стиле. Без объявления войны. Даже диалоги разные показывать не стоит. Пусть знают наших. За то разработчики Януса получили бы возможность прочесть дамп памяти. Правда они им вряд ли бы помог, но за то как все првилнатобылобы!
ПК>В общем, положил я его в итоге обратно в каталог Install, и больше не трогал.
Да правду написал тот мужит "С++-программисты это те кто любит боль".
ПК>>> Это очень легко наблюдать на многих приложениях, написанных на Java и ПК>>> C# в случаях возникновения непредусмотренных исключительных ситуаций.
A>> Пример таких приложений можно?
ПК>См. выше.
Отмазка не удачная. Надо было Янус хотя бы попробвать.
... << RSDN@Home 1.2.0 alpha rev. 578>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, BorisKV, Вы писали:
IT>>Не пугай меня. Это называется строить логику программы на исключениях. Объектно-ориентированный longjump. Никакого отношения к надёжности программы это не имеет.
BKV>Да ладно тебе — ты сам на таком проекте работаешь и до этого работал
Знакомьтесь, Борис KV За время своей работы на посту тим. лида в IBM успел уволить с проекта двух американов и двух индусов, одного архитектора разжаловать в девелоперы, одного перевести с "повышением" в другой тим. В общем, добрейшей души человек. Вот только логику на эксепшинах и Object Oriented LongJump так и не сумел искоренить!!!
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Павел Кузнецов, Вы писали:
A>> ...янус...
ПК>Вот на нем-то я как раз недавно и наблюдал типичный упомянутый глюкодром. Произошло ПК>как раз после исключения в ответ на разорвавшееся соединение во время синхронизации. ПК>После этого, даже когда соединение вернулось, ни одна синхронизация не проходила, ПК>сообщая что-то о вновь возникшем исключении.
> ПК>void g( I i )
> ПК>{
> ПК> i.f(); // И какой список здесь должен генерировать компилятор?..
> ПК> // Какие сборки будут подгружены, кроме данной, и от какого класса придет I — :xz:
> ПК>}
> ПК>
> > Ты имешь в виду, что бы я хотел видеть? Мне было бы достаточно документации на методы. Причем даже достаточно просто текстовой документации. На интерфейсы даже не обязательно. Я и так смогу узнать, что за объекты мне предстоит использовать.
Чтоб построить список исключений, порождаемом в методе класса, нужно будет также построить список исключений, порождаемых в реализациях методов интерфейсов, которые данный класс вызывает.
> Я не хочу 100%-ного решения. Мне достаточно дополнительной информации.
Боюсь, получится 5%-ное решение, практическая польза от которого будет достаточно небольшой.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, VladD2, Вы писали:
ПК>>Т.е. логические ошибки и исключительные ситуации в этом отношении ты не разделяешь?
VD>Это еще почему? Логические ошибки вообще контролировать нельзя. На то они и ошбки. Если ты о незапланированных исключениях, то это данность. И боросться с ней нужно только там где без этого никак.
Речь скорее всего о софте, который обязан работать 24x7 в любых условиях. Например. софт для 911. Но это совершенно отдельный класс задач, который решается не обработкой всех подряд типов исключений, а, в том числе, написанием софта, который следит за работоспособностью основного софта.
А обработка всех подряд типов исключений...? Я просто не понимаю что с ними потом делать
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
VladD2,
ПК>> -1. При недостаче памяти в C++ вылетает std::bad_alloc.
V> Да, тут я зря экстраполировал поведение фрэймворка на С++. Согласен. Но V> есть и исключения вроде переполнения стэка которые точно не предсказать V> и гарантированно не обработать.
Это уже совсем другая песня. Можно также сказать, что могут выключить питание
компьютера. Речь шла об исключениях, доступных в языке.
??>>> А вот NullReferenceException очень даже обрабатывается. При этом в
??>>> большинстве случае C#-ные приложения продолжают работать дальше, а
??>>> большинство С++-ных выпадает "в осадок".
ПК>> NullReferenceException — типичная логическая ошибка.
V> Что называть логической, а что физической? Ты бы объяснил свою V> терминологию. К примеру, если я забы проинициализировать ссылочкную V> переменную, то это логическая ошибка или по невнимательности/опечатка?
Это логическая ошибка. Другими словами, ошибка программиста. Для понимания "моей"
терминологии см., например, этот учебный курс:
The first thing you have to understand is the difference between programming errors
and exceptions. Programming errors are the misuses of programming abstractions
by programmers. Programming errors are mistakes committed by the programmers
in coding, so that the resulting program code diverges from the what the program
specification allows. Such errors should be corrected before the program is deployed.
Exceptions are unusual events that may occur at runtime even if the program is coded
correctly. Although such an event disrupts the normal execution logic of a program,
they are fully anticipated. That is, exceptions are part of the correct behavior of
a program. The cause of an exception is not an error commit by the programmer. Rather,
it is an unusual runtime event caused by anticipated circumstances.
Ключевые моменты: разница между ошибками и исключительными ситуациями, корректность
программы, выражающаяся в соблюдении контрактов, понятие предусловий. Более подробно
читай о так называемом программировании по контракту.
ПК>> Внешнему коду доверять странно, если он передал нулевую ссылку там, ПК>> где этого делать нельзя. Соответственно, надеяться на то, что внешний ПК>> код корректно "восстановится", тоже не приходится: он уже находится в ПК>> каком-то невалидном состоянии, на которое не рассчитывали при его ПК>> разработке.
V> Ой, ой, ой. Просто град из каких-то не определенных понятий. Что за V> "внешний код"? Что за доверять? Почему состояние стало обязательно V> каким-то не таким?
Потому что код, вызвавший данную функцию, нарушил контракт, не выполнив предусловие.
Соответственно, он некорректен.
ПК>> Попытка "восстановления" после подобной ошибки
V> Какой такой подобной?
После ошибки программиста.
V> Ну, а теперь давай отойдем от твоих обвинений управляемых сред в V> издевательствах над бедными пользователями и проанализируем несколько V> ситуаций из реальной жизни подкрепив их конкретными V> примерами.
Да не обвиняю я управляемые среды... Среда тут ни при чем. Просто в них чаще можно
встретить использование исключений для "обработки" ошибочных ситуаций.
V> модельприложения не приходит в неопределенное состояние. Обычно V> как раз в таких случаях можно просто ткнуть Continue и продолжить V> работать дальше избегая вызова данной команды. По крайней мере после V> этого можно хотя бы записать не записанные данные (хотя бы и под другим V> именем... на всякий пожарный). Серьдечко у пользователя конечно ёкнет V> при этом, но инфркт не случится. Данные то ведь не потеряны. А это V> главное!
Продолжение работы приложения в случае диагностирования ошибочного состояния
для сохранности данных не только не помогает, но и мешает. В любом случае, для
обеспечения сохранности данных нужны более надежные средства. Например, на случай
отключения питания, аппаратного сбоя и т.п. Периодическое сохранение состояния,
журналирование и т.п.
В этом случае никаких специальных действий от пользователя не нужно. Напротив,
нужно как можно быстрее завершить исполнение программы, вышедшей из режима,
предусмотренного разработчиками, чтобы пользователь не работал в этом состоянии,
потенциально не имея возможности сохранить данные, которые он произведет после
сбоя.
V> NullReferenceException вылетит. Или там в int.Perce кто-то без проверки V> буковки засунит, а сайтостроители просмотрели. Так вот юзер живет в V> сессии. А сессия крутися в отдельном потоке. Схлопнется, V> естествнно именно этот поток. Причем поток благополучно уйдет в пулл и V> будет использован повторно. И даже самый страшный SteckOverflowException V> не повалит весь сайт. И как не странно таких случаев (когда ошибка
В случае возможности изоляции потоков исполнения и их данных вполне можно завершать
исполнение только того потока исполнения, в котором диагностировано нарушение логики.
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
eao197,
e> вопрос. Тем не менее, в результате совершенно не критических, а иногда e> даже элементарных, ошибок в do_something может быть передан нулевой e> указатель. Причем именно нулевой, т.к. 0 -- это валидное значение для e> обозначения ни на что не указывающего указателя. Например:
e> Функция find_user_grop_name() возвращает имя группы, которой принадлежит e> пользователь. Но, если пользователь не принадлежит ни одной из групп, то e> find_user_grop_name возвращает 0. В данном фрагменте проблема e> программиста в том, что он должен был написать:
e> Но программист ошибся. Он мог вообще не знать, что в каких-то условиях e> пользователь может не принадлежать ни одной группе. Более того, на e> момент написание кода этого вообще могло не быть -- такая вольность в e> отношении пользователей могла появиться уже в процессе развития системы, e> во второй или третьей версии.
Сначала я хотел бы остановиться на самой ситуации. В данном случае лучше было
тем или иным образом сделать потенциальное отсутствие возвращаемого значения
явным. Скажем, так:
в таком случае данная ошибка была бы поймана вовремя. А именно, во время
написания/модификации кода/интерфейса, т.к. пользователь физически не смог
бы пропустить факт потенциального отсутствия возвращаемого значения.
Но допустим, что интерфейс именно такой, как он обозначен ранее...
e> Итак, что в такой ситуации лучше делать? Позволить приложению время от e> времени падать с crush dump-ом или порождать исключение в надежде, что e> на каком-то уровне его смогут обработать и выполнить мягкий рестарт?
Основная проблема в такой логике заключается в том, что от "мягкого" рестарта
ничего не изменится, т.к. невалидное состояние приложения вызвана его логикой,
а не какими-то внешними данными, которые могут прийти в другое состояние.
Хуже того, т.к. мы сообщаем об ошибке средствами, предназначенными для обработки
ситуаций, предусмотренных логикой приложения, мы рискуем вообще "проглотить"
эту ошибку, и продолжить исполнение в невалидном состоянии.
Если можно быть уверенным в изоляции состояния, ассоциированного с потоком
исполнения, в котором диагностирована ошибка, то, конечно, необходимости
завершать работу всего приложения никакой нет.
Соответственно, если считать, что ошибки в каких-то фрагментах приложения
являются допустимой ситуацией для его работы, то нужно максимально изолировать
данные фрагменты.
Примерами могут служить плагины, множественные сессии исполнения в серверах
и т.п. Но я не вижу, как исключения помогают изоляции потоков исполнения за
исключением диагностики одной из ошибочных ситуаций, когда изолируемый фрагмент
выпускает исключение за свои пределы.
Но, имхо, рапортовать нарушение предусловия плагину в виде исключения совершенно
лишнее. В этом случае я бы предпочел, чтобы приложение-контейнер плагинов завершило
работу ошибочного плагина, а не играла с ним в пинг-понг исключениями.
e> Имхо, в случаях, когда возможна проверка на заведомо некорректные e> параметры (как правило, это public интерфейс какого-либо класса, e> библиотеки или модуля), лучше все-таки порождать исключения. Во-первых, e> потому, что это самая ближайшая к месту появления проблемы точка e> (все-таки гораздо понятнее, когда в исключении будет сказано, что это e> do_something и причина в нулевом значении p). А то ведь crush dump мог e> быть инициирован где-нибудь на три уровня вложенности ниже. А еще хуже, e> что он мог быть вообще не инициирован, если в текущем состоянии e> программы параметр p игнорируется.
В общем случае речь не идет об игнорировании нарушения предусловий. Напротив,
когда в этом отношении нельзя положиться на систему, лучше всего вводить
диагностику. И чем больше, тем лучше. Единственное, не стоит смешивать диагностику
ошибок с обработкой исключительных ситуаций, которые к ошибкам программиста
никакого отношения не имеют.
e> Во-вторых, потому, что это дает возможность приложению, если оно e> спроектировано на восстановление после подобных исключений, восстановиться e> на каком-то уровне.
Т.е. ты предлагаешь закладывать в поток исполнения логику, рассчитанную на
обработку ошибок программирования в этом же потоке? Имхо, это безнадежный путь.
Идя по такой дорожке мы должны в каждой точке предполагать возможность
некорректного состояния. Очевидно, что диагностировать все возможные нарушения
нереально.
Вместо этого придумали понятия инвариантов, предусловий, постусловий и т.п.
Т.е. логика программы строится на основе некоторых предположений о ее состоянии.
Когда программа приходит в непредусмотренное состояние (инварианты нарушены),
что диагностируется нарушением предусловий или постусловий, пытаться делать
предположения о том, может ли она прийти обратно в нормальное состояние
бессмысленно.
e> Ну например, e> есть многопоточное приложение сервер, обрабатывающее коммуникационные e> сессии. В рамках обработки одного из запросов одной из сессий e> диагностируется подобная ошибка. Происходит проброс исключения до самого e> верхнего уровня обработчика данной сессии. Он понимает, что все плохо, e> ни на какие из прочитанных в сессии данных надеятся нельзя. Но можно e> отослать клиенту специальный ответ (что-то типа General Failure или e> Service Unavailable) после чего просто закрыть сессию и удалить все e> связанные с ней ресурсы. Такое поведение позволяет оставить все e> остальные сессии в рабочем состоянии.
В таком случае подобная ситуация не является нарушением инвариантов сервера,
а является для него вполне предусмотренной ситуацией, хотя и исключительной.
Нарушаются инварианты некоторого контекста, ассоциированного с изолируемой
сессией. (Если, конечно, этот контекст изовлирован. Если нет, я бы не стал
полагаться на удачу, рискуя данными остальных пользователей.)
Но вот если, например, в коде, диспетчеризующем сессии, т.е. не обладающем
отделяемым контекстом, будет диагностирована подобная ситуация, очевидно, что
пытаться продолжать его исполнение, рискуя валидностью данных всех сессий,
неразумно.
При этом, возвращаясь к ситуации с некорректными сессиями, снова-таки, нет
никакой необходимости прибегать к исключениям для завершения исполнения
сессии. Напротив, намного лучше было бы использовать другой механизм,
гарантирующий, что сессия не сможет "перехватить" прерывание и продолжить
жизнь в невалидном состоянии.
e> Попробую резюмировать. Имхо, существует целый класс ошибок -- заведомо e> неверные аргументы для public-интерфейсных функций/методов. Бороться с e> такими ошибками, имхо, как раз удобнее выбрасывая исключения на самом e> раннем этапе. Поскольку есть большая вероятность, что нарушение e> предусловий (т.е. некорректность аргумента) вызвано не жесткими сбоями в e> коде (повисшие/битые указатели или что-либо подобное), а элементарными e> алгоритмическими ошибками или невнимательностью программиста.
Гм... А какая разница, какими ошибками вызвано нарушение предусловий?
Все равно нужно завершать поток исполнения, в котором диагностирована
ошибка. Согласен, что следует это делать как можно раньше, по возможности
не дожидаясь низкоуровневых/аппаратных сигналов/исключений.
e> Паша, может как раз такие вещи ты и называл в числе тех редких случаев, e> когда после ошибки в программе восстановление еще возможно?
Я подразумевал случаи, когда контекст исполнения изолирован.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Вот на нем-то я как раз недавно и наблюдал типичный упомянутый глюкодром. Произошло ПК>как раз после исключения в ответ на разорвавшееся соединение во время синхронизации. ПК>После этого, даже когда соединение вернулось, ни одна синхронизация не проходила, ПК>сообщая что-то о вновь возникшем исключении.
Твой пример скорее говорит о неотлаженности приложения, чем об устойчивости приложения.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
А можно поглядеть на отправленные тобой сообщения? 
Если нам не помогут, то мы тоже никого не пощадим.
