Здравствуйте, Cyberax, Вы писали:

C>Является ли выброс исключения для индикации ошибки — управлением потоком?

Смотря что считать ошибкой и, что считать индикацией. Одна и та же функция может одновременно использоваться по разному. Возьмем, к примеру, int.Parse. Если я использую его там где в строке просто обязана лежать цифра, то несомненно генерация исключения будет разумной реакцией на то, что в строке лижет не число. Например, я читаю данные из ХМЛ и первожу их в целые. По структуре ХМЛ в поле обязано лежать число в строковой форме. При этом наличие там не числа является исключительной ситуацией.

Другой вариант... Я читаю строку из поля ввода. При этом совершенно нормальной ситуацией бывает ошибочный ввод пользователя. При этом логикой программы должна быть предусмотрена процедура проверки кооректности ввода и выдачи пользователю сообщения об ошибке. К сожалению, во фрэймворке 1.х небыло функции позволяющей нормално решать данную проблему. int.Parse() всегда генерировал исключение. Код при этом становился громоздким и неудобным.

Во втором фрэймворке появился int.TryParse и все встало на свои места.

Здравствуйте, Cyberax, Вы писали:

>> C>А RSDN.NNTP не ты писал, случайно?
>> Не я. А что?

C>Так и быть, лопату дарить не буду.

И правильно сделаешь. Потому как кто к нам счем прийдет от того и помрет.

А что, кстати, с ним не так?

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Видимо, у нас, все-таки, жизнь разная...

ПК>>>...нулевого указателя, и далее в дело вступит
ПК>>> мой обработчик данного исключения, и создаст снимок стека или дамп,
ПК>>> чтоб я мог определить, в чем же, собственно, ошибка.

V>> А ты для какого рынка программы то пишешь?

ПК>Сейчас -- работаю в команде, пишущей движки для клиент-серверных бизнес-
ПК>приложений (свой orb, свой application server, аналог win fs, свой движок
ПК>форм и т.п.)

Ясно. Тогда твое мировозрение как становится уже даже не смешным, а совсем грусным. Это именно тот список задач которые не стоит "класть", чтобы ты узнал в чем совбственно ошибка.

ПК>Надежнее, чем что?

Чем аналогичные С++-ные написанные в таких вот традициях "чтобы я мог узнать...".

ПК> Если, чем C++ (делая догадки по остальным сообщениям
ПК>в данной теме), то это просто неверно: они по определению не могут работать
ПК>надежнее, чем их виртуальные машины, которые как раз на C++ и написаны.

На С++ во фрэймворке написано не так много кода. В основном ядро и еще процедуры оптимизации. Все они протестированы по 100 раз и продолжают тестироваться миллионами пользователей по всему миру. Прикладные же приложения этим похвастаться подобым не могут. Так что не нужно их даже сравнивать.

ПК>Вряд ли. Я периодически скачиваю новую версию, немного играюсь, в очередной
ПК>раз разочаровываюсь, и деинсталлирую. Т.е. прогресс, безусловно, наблюдается,
ПК>но как-то пока не торкает... А жаль. В него можно было бы вставить репликацию,
ПК>которой мне в News-клиентах не хватает.

И за все время даже ни одного тестового сообщения не отпавил? И чем же ты разочаровывашся?

ПК>Пробовал, пробовал. Если бы у него был лог-файл, я бы привел соответствующий
ПК>фрагмент.

Ты будешь удевлен, но лог у него есть.

ПК>В общем, пока не пробраузил кнопочкой "Обзор", ему не полегчало...

Внимание, вопрос! И чем же провенились исключения? Возможно ошибка там в логике какая и есть. Но что было бы толку если бы Янус вылетил без объяснения причин?

ПК>Все зависит от того, что произошло. Если нарушение предусловия (ошибка
ПК>программиста),

А чьи еще ошибки бывают в программах? Аппоратные? И как ты на них собирашся реагировать.

ПК> то я предпочту аварийное завершение,

Ясно. В общем, там дальше кирпич весит за которым овраг, но вам можно. (с)

Здравствуйте, vdimas, Вы писали:

V>Разве это стателесс?

Если вы не сохраняете эти данные сразу в базе, а храните в памяти сервера, то нет, конечно. А в чём проблема была хранить набиваемые данные на клиенте?

Здравствуйте, Геннадий Васильев, Вы писали:

IT>>Смотрим контекст. Я не о методе сервера SaveWhatever, а о хранении введённых данных пока этот вызов не завершиться успешно.

ГВ>Я и говорю, что это спорный вопрос. Никто не мешает, и ИМХО, это полезно: хранить промежуточные, возможно невалидные данные в специальных таблицах/файлах и т.п., которые никак не упоминаются в "основных" таблицах до выполнения валидации. Короче говоря — хранить сеанс пользователя.

Да ради бога, особенно если есть такие non functional requirements. Но у тебя тогда будет более чем один метод Save, не так ли?

Здравствуйте, IT, Вы писали:

IT>Но у тебя тогда будет более чем один метод Save, не так ли?

Да, естественно. А при чём здесь количество методов Save?

Здравствуйте, IT, Вы писали:

IT>Но у тебя тогда будет более чем один метод Save, не так ли?

Хотя... может так статься, что всё удастся упаковать и в один метод Save. Например, это может быть метод сохранения данных сеанса вкупе с идентификатором сеанса. Тогда при отлёте валидации (а равно и исключении) данные сеанса перейдут в какое-нибудь "draft" и будут сохранены отдельно.

VladD2 wrote:

>>> C>А RSDN.NNTP не ты писал, случайно?
>>> Не я. А что?
> C>Так и быть, лопату дарить не буду.
> И правильно сделаешь. Потому как кто к нам счем прийдет от того и помрет.
> А что, кстати, с ним не так?

Куча мелких багов/недоработок, да вдобавок еще и тормозит . Сообщения в
Thunderbird'е открываются намного дольше, чем через web-интерфейс.

Ну и падает часто.

--
С уважением,
Alex Besogonov (alexy@izh.com)

VladD2 wrote:

> C>Является ли выброс исключения для индикации ошибки — управлением
> потоком?
> Смотря что считать ошибкой и, что считать индикацией. Одна и та же
> функция может одновременно использоваться по разному. Возьмем, к
> примеру, int.Parse. Если я использую его там где в строке просто
> обязана лежать цифра, то несомненно генерация исключения будет
> разумной реакцией на то, что в строке лижет не число. Например, я
> читаю данные из ХМЛ и первожу их в целые. По структуре ХМЛ в поле
> *обязано *лежать число в строковой форме. При этом наличие там не
> числа является исключительной ситуацией.

Логично.

> Другой вариант... Я читаю строку из поля ввода. При этом совершенно
> нормальной ситуацией бывает ошибочный ввод пользователя. При этом
> логикой программы должна быть предусмотрена процедура проверки
> кооректности ввода и выдачи пользователю сообщения об ошибке. К
> сожалению, во фрэймворке 1.х небыло функции позволяющей нормално
> решать данную проблему. int.Parse() всегда генерировал исключение. Код
> при этом становился громоздким и неудобным.
> Во втором фрэймворке появился int.TryParse и все встало на свои места.

Возьмем более сложный случай: есть два метода загрузки документа —
быстрый и медленный. Сначала делается попытка использовать быстрый
метод. Но в определенный момент загрузки может случится ситуация такая,
что быстрый метод оказывается неприемлим, и нужно переключиться на
медленный режим и перепарсить весь документ. Ситуация _не_ ошибочная, и
встречается достаточно часто.

У меня в этом случае кидается format_mismatch_exception. То есть
используется управление потоком с помощью исключений.

Это плохо?

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Хотя... может так статься, что всё удастся упаковать и в один метод Save. Например, это может быть метод сохранения данных сеанса вкупе с идентификатором сеанса. Тогда при отлёте валидации (а равно и исключении) данные сеанса перейдут в какое-нибудь "draft" и будут сохранены отдельно.
DoEverything, на входе xml, на выходе xml

VladD2,

> ПК>Сейчас -- работаю в команде, пишущей движки для клиент-серверных бизнес-приложений (свой orb, свой application server, аналог win fs, свой движок форм и т.п.)

> Ясно. Тогда твое мировозрение как становится уже даже не смешным, а совсем грусным. Это именно тот список задач которые не стоит "класть", чтобы ты узнал в чем совбственно ошибка.

В этих задачах следует ошибки отлавливать "до того", а если в ходе работы произошла ситуация, грозящая нарушением инвариантов, лучше перезапуститься. Но первый вариант намного лучше.

> ПК> Надежнее, чем что?

> Чем аналогичные С++-ные написанные в таких вот традициях "чтобы я мог узнать...".

В этих традициях написана VM того же .Net: посмотри, как там с помощью _ASSERTE проверяются предусловия и постусловия. В случае их нарушения никаких исключений не будет. Все просто "тихо" упадет. При этом проверки в критических местах уже присутствуют. Вопрос: почему их в release версии не превращают в исключения? Ответ на этот вопрос поможет понять позицию, которую я в этой теме озвучивал.

> На С++ во фрэймворке написано не так много кода. В основном ядро и еще процедуры оптимизации. Все они протестированы по 100 раз и продолжают тестироваться миллионами пользователей по всему миру. Прикладные же приложения этим похвастаться подобым не могут. Так что не нужно их даже сравнивать.

Тестирование миллионами пользователей здесь вообще ни при чем, т.к. ошибки из разряда "вылетов" виртуальной машины пользователи рапортовать просто не должны. Их нужно отлавливать "до того", на этапе разработки и внутреннего тестирования. То же самое верно и для прикладных приложений.

> ПК> Вряд ли. Я периодически скачиваю новую версию, немного играюсь, в очередной раз разочаровываюсь, и деинсталлирую.

> И за все время даже ни одного тестового сообщения не отпавил?

Мне в Опере редактировать удобнее. Да, в общем, и все остальное тоже... Спасибо за идею с USB-диском. Я попробую ее к Опере применить. Только нужно диск достаточно большого объема, но небольшого размера, найти: у меня почтовая база в Опере уже больше 4 гигабайт занимает...

> ПК> Пробовал, пробовал. Если бы у него был лог-файл, я бы привел соответствующий фрагмент.

> Ты будешь удевлен, но лог у него есть.

Я не нашел. Но, боюсь, если лог в базе теперь уже поздно, т.к. ее я в ходе попыток воспроизвести ошибку удалил

> ПК>Все зависит от того, что произошло. Если нарушение предусловия (ошибка программиста),

> А чьи еще ошибки бывают в программах? Аппоратные? И как ты на них собирашся реагировать.

Бывают исключительные ситуации, которые программа и должна обрабатывать: нехватка ресурсов для текущей операции, какие-то нарушения в окружении, неверные данные и т.п. К ошибкам программирования это все не относится.

Здравствуйте, Cyberax, Вы писали:

C>Возьмем более сложный случай: есть два метода загрузки документа —
C>быстрый и медленный. Сначала делается попытка использовать быстрый
C>метод. Но в определенный момент загрузки может случится ситуация такая,
C>что быстрый метод оказывается неприемлим, и нужно переключиться на
C>медленный режим и перепарсить весь документ. Ситуация _не_ ошибочная, и
C>встречается достаточно часто.

C>У меня в этом случае кидается format_mismatch_exception. То есть
C>используется управление потоком с помощью исключений.

C>Это плохо?

Несомненн, плохо. Это именно использование исключений в целях управления логикой приложения.

Хотя странна и сама ситуация. Чем отличаются эти методы?

Здравствуйте, Cyberax, Вы писали:

C>Куча мелких багов/недоработок,

Ну, ты бы на сапорт написал. А то вот ПК пользуется и доволен.

C>да вдобавок еще и тормозит . Сообщения в
C>Thunderbird'е открываются намного дольше, чем через web-интерфейс.

Тебе не кажется, что тормоза связаны с общей загрузкой сайта? В часы пик и через веб-интерфейс пробиться не просто. Кстати, Янус в этом аспекте показывает себя просто замечательно. Обработка ведь пакетная.

C>Ну и падает часто.

Где? Я вроде не замечал. Хотя я им и не пользуюсь.

Здравствуйте, Павел Кузнецов, Вы писали:

V>> Но
V>> есть и исключения вроде переполнения стэка которые точно не предсказать
V>> и гарантированно не обработать.

ПК>Это уже совсем другая песня. Можно также сказать, что могут выключить питание
ПК>компьютера. Речь шла об исключениях, доступных в языке.

Нет. Переполнение стека, особенно на дотнете — это ошибка программиста. А питание аппаратная проблема. К тому же легко решаемая (UPS спасет отца русской демократии...).

ПК>Это логическая ошибка. Другими словами, ошибка программиста. Для понимания "моей"
ПК>терминологии см., например, этот учебный курс:

Мне не нужно ссылок на английские сайты да еще и с явной бредятиной. Ты просто ответь. Что в твоем понимании ошибка не логическая и приведи несколько примеров.

ПК>Ключевые моменты: разница между ошибками и исключительными ситуациями, корректность
ПК>программы, выражающаяся в соблюдении контрактов, понятие предусловий. Более подробно
ПК>читай о так называемом программировании по контракту.

Извини, но это является бредом для ООЯ. Нарушение того самого контракта по-твоему является шататной ситуацией? И как на нее реагировать? Выпадать в осадок?

Я предпочитаю пользоваться общепринятыми определениями http://en.wikipedia.org/wiki/Exception. Хотя честно говоря оно и не самого лучшего качества.

ПК>Потому что код, вызвавший данную функцию, нарушил контракт, не выполнив предусловие.
ПК>Соответственно, он некорректен.

И что? Почему при этом состояние всей программы обязательно стало некорректным?

ПК>После ошибки программиста.

Да все исключения кроме аппоратных яывляются ошибками программистов. Тогда уж лучше использовать термины аппаратные исключения и исключения программные.

В любом случае более чем странно слышать о том, что нельзя постановиться после программного исключения. Примеров тебе было приведено море. Более того ты постоянно пользушся софтом который восстанавливаетя опсле не критичных исключений и что-то ни одного слова о пробемах от тебя не слышно.

ПК>Да не обвиняю я управляемые среды... Среда тут ни при чем. Просто в них чаще можно
ПК>встретить использование исключений для "обработки" ошибочных ситуаций.

Исключительных. Ситуаций не предусмотренных логикой программы. И делается это по совсем банальным соображениям — управляемая среда за счет типобезопасности обеспечивает устойчивость приложения не давая ошибке программиста превратиться в крах приложения из-за порчи памяти.

ПК>Продолжение работы приложения в случае диагностирования ошибочного состояния
ПК>для сохранности данных не только не помогает, но и мешает.

Примеры я тебе уже приводил. Убеждать тебя не хочу. Пусть этим займутся твои клиенты. Я же просто постерегусь таковым становиться... если что.

ПК> В любом случае, для
ПК>обеспечения сохранности данных нужны более надежные средства. Например, на случай
ПК>отключения питания, аппаратного сбоя и т.п. Периодическое сохранение состояния,
ПК>журналирование и т.п.

Ага, точно! Журналирование. Будем журналировать ввод пользователя в Янусе чтобы потом его специально грохнуть. Самому то не смешно?

ПК>В этом случае никаких специальных действий от пользователя не нужно. Напротив,
ПК>нужно как можно быстрее завершить исполнение программы, вышедшей из режима,
ПК>предусмотренного разработчиками, чтобы пользователь не работал в этом состоянии,
ПК>потенциально не имея возможности сохранить данные, которые он произведет после
ПК>сбоя.

Не будет никто делать никакое журналирование в прикладных системах. Максимум транзакциями воспользуются. Только толку с того. Ну, и как тебе уже не раз говорили системы бывают многопользовательскими и класть сервер из-за ошибки в сесси — это идиотизм.

ПК>В случае возможности изоляции потоков исполнения и их данных вполне можно завершать
ПК>исполнение только того потока исполнения, в котором диагностировано нарушение логики.

Ну, вот в ГУИ приложении, если оно разумно написано, любая команда пользователя и живет изолировано. Так зачем срубать все приложение из-за мелкой ошибки в одной команде? Хотя вопрос уже риторический.

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Ну, мы с тобой точно не знаем, почему именно документ получается "плохим".

Да не плохим, а битым. И знать там не чего. По памяти уроды проходятся плюс имеют сложную структуру хранения вводимых данных.

ПК> Я бы, скорее предположил, что дело в порче инвариантов.

Конечно всегда есть шанс, что AV было вызванно потусторонними силами, а документ испортился не из-за этого, а из-за совпадения каких-то факторов. Но это каую же фантазию нужно иметь? И как нужно стараться себе это внушить?

ПК> В случае же продолжения работы было бы не лучше: пользователь успел бы
ПК>много наредактировать, прежде чем стало бы ясно, что документ уже ни к черту.

Было бы лучше переисать ворд на типобезопасном ООЯ. Тода применяя довольно простые паттерны можно было гарантировать целостность модели и мелкие ошибки вроде выхода за границу массива уже не приводили бы к наложенным AV с хаотичной порчей памяти. А Ворд до сих пор даже не на С++ пишется. Насколько мне извесно он на голимом С написан.

ПК> В случае "вылета", если
ПК>Auto Recovery приводит к проблемам (чего я на своих документах не замечал, но и Word у меня сам по себе не вылетает, за исключением отключения питания машины без shut down), то можно воспользоваться последней autosaved версией.

Это потому, что ты и 5% его возможностей не используешь. По пользуйся ревижонами и коментариями, да так чтобы их было от большого количества человек, да чтобы одно на другом сидело. Тогда ты еще и не то увидишь.

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Боюсь, получится 5%-ное решение, практическая польза от которого будет достаточно небольшой.

Возможно. Я правда оцениваю процент чуть выше. Но тут оно как... У меня и так проблем нет. И лишняя помощь тут вряд ли помешает.

Здравствуйте, alexeiz, Вы писали:

A>Не смертельно в смысле того, что runtime сможет продолжить выполнение программы. Однако с точки зрения надёжности выброс из Dispose имеет тот-же эффект, что и выброс из деструктора в C++. Гарантировать сохранение инвариантов, освобождение ресурсов и нормальную обработку исключений в таком случае невозможно.

Исключение в Dispose — это конечно не хорошо. Но все же последсвтия будут далеко не плюсовыми.

A>PS: Напомню, что в C++/CLI деструкторы прямо эквивалентны Dispose(),

И что?

A> и Visual C++ по крайней мере в Beta2 генерирует такой код для деструкторов, который в критических случаях просто проглатывает любые исключения, из него выбрасываемые.

Да? Вот глянул, что он там генерирует. Для следующего класса:

using namespace System;

ref class C
{
public:
    ~C() { Clinup(); }
    !C() { Clinup(); }

    // Не надо реализовыывать Dispose Pattern, т.к. ее поддерживает язык.
    // :)) не вопрос заведем просто виртуальный метод.
protected:
    virtual void Clinup()
    {
        Console::WriteLine("C.Clinup()");
    }
};

Генерируется следующий код:

internal class C : IDisposable
{
    // Methods
    private void !C() { this.Clinup(); }
    public C() { }
    private void ~C() { this.Clinup(); }
    
    protected virtual void Clinup()
    {
                Console.WriteLine("C.Clinup()");
    }

    public void Dispose()
    {
        this.Dispose(true);
        GC.SuppressFinalize(this);
    }

    protected virtual void Dispose([MarshalAs(UnmanagedType.U1)] bool flag1)
    {
        if (flag1)
        {
            this.~C();
        }
        else
        {
            try
            {
                this.!C();
            }
            finally
            {
                base.Finalize();
            }
        }
    }

    protected override void Finalize()
    {
        this.Dispose(false);
    }
}

Преобразование в C# (с) Рефлектор. Для читаемости отформатировано мной.

И где ты здесь узрел какое-то проглатывание исключений? Это качественная реализация паттерна Dispose. Не более того!

Да, я согласен, что было очень верно реализовать этот паттерн пямо в языке, а не заставлять каждый раз реализовывать его программиста. Это несомненно страхует программистов от лишних ошибок.

Мне вот только не понятно почему некоторые программисты так сильно борются с внедрением паттернов в языки типа C#, но когда эти самые паттерны внедряются в их любимые языки, то они вместо того, чтобы гревать восхищаются этим.

Здравствуйте, Cyberax, Вы писали:

>> C>А откуда он будет это знать?
>> Программист скажет. Ну, вылетит программка при тестировани...
>> программист подсмотрит тип исключения и обработает его. Или из
>> документации прочитает. В общем, не важно откуда.

C>В общем вы повторяете аргументы сторонников динамических языков.

Возможно, если пытаться проводить аналогии. Но есть огромная разница между обработкой исключительных ситуаций и системой типа языка.

VladD2 wrote:

> C>Куча мелких багов/недоработок,
> Ну, ты бы на сапорт написал. А то вот ПК пользуется и доволен.

Я тоже по большему счету доволен. А багрепорты всегда писать лень
(обещаю исправиться).

> C>да вдобавок еще и тормозит . Сообщения в
> C>Thunderbird'е открываются намного дольше, чем через web-интерфейс.
> Тебе не кажется, что тормоза связаны с общей загрузкой сайта? В часы
> пик и через веб-интерфейс пробиться не просто.

Нет, тормозит даже когда веб-интерфейс работает быстро.

> Кстати, Янус в этом аспекте показывает себя просто замечательно.
> Обработка ведь пакетная.

В Thunderbird — тоже при желании.

> C>Ну и падает часто.
> Где? Я вроде не замечал. Хотя я им и не пользуюсь.

С завидной переодичностью получаю OutOfMemory — несколько раз в неделю,
иногда не дает с постить с ошибкой о недостаточности прав и т.п.

--
С уважением,
Alex Besogonov (alexy@izh.com)

VladD2 wrote:

> C>Возьмем более сложный случай: есть два метода загрузки документа —
> C>быстрый и медленный. Сначала делается попытка использовать быстрый
> C>метод. Но в определенный момент загрузки может случится ситуация такая,
> C>что быстрый метод оказывается неприемлим, и нужно переключиться на
> C>медленный режим и перепарсить весь документ. Ситуация _не_ ошибочная, и
> C>встречается достаточно часто.
> C>У меня в этом случае кидается format_mismatch_exception. То есть
> C>используется управление потоком с помощью исключений.
> C>Это плохо?
> Несомненн, плохо. Это именно использование исключений в целях
> управления логикой приложения.

А какой вариант лучше? Сразу определить нужный метод загрузки — нельзя.
Предварительно обходить граф, чтобы проверить возможность быстрой
загрузки — неэффективно. Без исключений пришлось бы возвращать код
ошибки через несколько уровней вложенности.

> Хотя странна и сама ситуация. Чем отличаются эти методы?

Быстрый метод использует закэшированные локально преобразования (в виде
слинкованого бинарного изображения из собственного JIT-компилятора).
Если встречается неизвестное преобразование — включается второй режим,
когда преобразования врубаются в интерпретируемый режим с параллельной
перекомпиляцией.

И не надо предлагать мне использовать .NET и не мучаться с ручным JIT-ом...

--
С уважением,
Alex Besogonov (alexy@izh.com)