Запуталась в 3 соснах (( или как отловить исключение

[IKA]

Есть код , типа такого

try
{
    ttsbegin;
    ....
    stdClass.Method();

    myClass.Method();
    ....
    ttscommit;
}
catch
{}

в stdClass.Method();
код приблизительно такой:

try
{
    ttsbegin;
    ....
    if (!someValidation())
         throw error();....
    ttscommit;
}
catch
{}

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

myClass.Method();

.

(То есть, суть в том, что вычисления в stdClass не критичны для моего класса и мне достаточно сообщения в инфологе, что они закончились с ошибкой и нужно продолжить выполние кода )
Retry не подходит, тк он на самое начало вернет моего try блока.
Замена исключения в stdClass на ttsAbort тоже не поможет, тк ttsAbort откатывает не только текущую транзакцию, но и внешние тоже(.

Как перехватить ошибку, выбрасываемую stdClass классом и продолжить выполнение кода?

[Ruff]

Как-то так подойдет?

try
{
    ttsbegin;
    ....
    try
    {
       stdClass.Method();
    }
    catch
    { 
     // warning
    }
   
    myClass.Method();
    ....
    ttscommit;
}
catch
{}

Добавлено: Хотя правильнее наверно будет разбить этот блок на две транзакции - первая со стандартным, вторая - с вашим методом.

[pedrozzz]

Цитата:

Сообщение от Ruff

Как-то так подойдет?

Не подойдет, т.к. вложенный try{}catch{} не работает внутри внешней транзакции. Правильнее разбить на две независимых транзакции, но тут надо постановку смотреть, можно ли будет обеспечить целостность данных.
Добавлено: пока писал ответ, Вы и сами все поняли

[IKA]

По постановке они именно вложенные в этом-то и проблема.
по-видимому, придется переписывать логику в std, чтобы обойти исключение ... ох(

[S.Kuskov]

Цитата:

Сообщение от IKA

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

А для чего вы тогда свою транзакцию открываете до stdClass?

[IKA]

Смысл мероприятия:

В цикле вставляются записи в таблицу - должны либо вставиться все, либо ни одной. Т.о транзакция. При вставке каждой записи для нее выполняются определенные пересчеты, которые, если произойдут - хорошо, если нет, то пользователь на основании инфолога потом разберется в каждой конкретной ситуации.
То есть по идее должно быть в инфологе нечто типа :
Строка 1:
Вставлена
Пересчет А выполнился
Пересчет Б закончился с такими-то ошибками (это надо отловить и продолжить выполнение кода)
Строка 2:
Вставлена
Пересчет А закончился с такими-то ошибками
Пересчет Б выполнился ....

и так для кучи строк.

Можно, конечно все переструктурировать в существующем коде. чтобы обойти проблему, но:
1) пользователям это не нравится, тк они для каждой строки хотят видеть все релевантные для нее ошибки /предупреждения. (И, вообще-то, я с ними согласна.)
2) по-моему, это принципиально неправильно, что , дожив до 2012, мы до сих пор не можем нормально отлавливать ошибки.

[RVS]

Как вариант :

- все вставлять во временную таблицу (общая транзакция не нужна)
- при отсутствии ошибок - переносить из временной в нормальную таблицу, в транзакции, ессно, но уже после всех "пересчетов"

Как вам оно?

[gl00mie]

Цитата:

Сообщение от IKA

Можно, конечно все переструктурировать в существующем коде. чтобы обойти проблему, но:
1) пользователям это не нравится, тк они для каждой строки хотят видеть все релевантные для нее ошибки /предупреждения. (И, вообще-то, я с ними согласна.)

Научите пересчеты не выбрасывать исключения - вот и все. Чтобы не лезть глубоко в код, если проблематично протащить в пересчеты новый параметр, можно где-нить в GlobalCache вести флажок, управляющий этим поведением, а также повесить обработчик в ttsNotifyAbort(), чтобы этот флажок вычищал. При наличии флажка пересчеты будут просто выводить предупреждения и прекращать работу, при отсутствии - выбрасывать исключения, как раньше. В конце вставки всех строк анализируете наличие предупреждений в инфологе, как в проверках целостности сделано, и принимаете решение о том, накатывать транзакцию или нет. После успешного накатывания транзакции не забываете удалить флажок из GlobalCache, чтобы пересчеты заработали, как раньше.

Цитата:

Сообщение от IKA

2) по-моему, это принципиально неправильно, что , дожив до 2012, мы до сих пор не можем нормально отлавливать ошибки.

Это - by design, потому что предполагается, что если код выбрасывает исключение в транзакции, значит, в этой транзакции что-то пошло не так, и ее надо откатить. Это как остановка конвейера на японских заводах: каждый рабочий может это сделать при необходимости, но при этом каждый рабочий осознает всю полноту ответственности за такое решение. А когда можно "нормально отлавливать" любое и каждое исключение в транзакции, то получается, как с запуском Челленджера (см. про уплотнительные кольца и предупреждения Morton Thiokol).

PS.

Цитата:

Сообщение от IKA

В цикле вставляются записи в таблицу - должны либо вставиться все, либо ни одной. Т.о транзакция.

Вставляйте свои записи в RecordSortedList - тогда на момент вызова пересчетов можно будет обойтись без общей транзакции и отловить каждую ошибку в вашем try/catch, а в конце обработки, если ошибок не было, можно будет вставить все строки разом в одной транзакции (вариации на тему временной таблицы )

[S.Kuskov]

Цитата:

Сообщение от IKA

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

Можно сначала вставить записи, закрыть транзакцию, а потом без общей транзакции (если необходимо, то сделать транзакцию для каждой отдельной строки) выполнить пересчет?

[gl00mie]

Результат пересчетов, насколько я понял, должен влиять на то, накатывать транзакцию или нет.

[S.Kuskov]

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

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

Ещё момент, на который стоит обратить внимание. При вставке строки, необходимо обрабатывать ошибки только своего метода, или же и стандартного тоже? Если вопрос в обработке (читай предотвращении отката транзакции) в стандартном методе, то здесь необходимо задуматься. Используя стандартный метод, вы либо соглашаетесь с его действиями, либо нет. Если метод написан так, что при неудачной валидации вставка строки откатывается, то никакими внешними (по отношению к методу) перехватчиками вы не сможете (да и не должны) изменить это. Для изменения поведения придется изменить метод. И мне кажется это правильным.

[RVS]

Цитата:

Сообщение от S.Kuskov

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

Перечитал еще раз - а ведь правда, и так тоже понять можно )))

Все-таки, КМК, хотят следующего :

- сперва проверить весь массив исходных данных (а-ля Проверка журнала)
- затем, если все ОК - записать данные из этого массива данных в какую-то таблицу (а-ля Разноска журнала)

То, что я там предлагал - минимально трудоемкое решение второго случая.

[S.Kuskov]

RVS, спасибо. Да в такой постановке вопроса есть смысл.

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

[S.Kuskov]

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

Решение.
Идея такая: Этап первый "оптимистический". Открываем транзакцию и строка за строкой выполняем обработку в надежде на то что исключений не будет. Если все получилось закрываем транзакцию.
Этап второй "ловим исключение". Помещаем транзакцию, описанную в первом этапе в блок try-catch. При возникновении исключения транзакция откатится и мы узнаем об этом.
Этап третий "зацикливаем". В случае поимки нами исключения повторяем для оставшихся строк первый и второй этап, но уже без подтверждения транзакции даже в случае успеха.

enumerator = Lines.getEnumerator()
first = true;
do
{
    toBeContinued = false;

    try
    {
        ttsbegin;
            while (enumerator.moveNext())
            {
                stdClass.exceptionWarinigMethod(enumerator.current())
            }
        if (first) ttscommit;
        else ttsabort;
    } 
    catch
    {
        toBeContinued = true;
    }

    first = false;
}
while (toBeContinued)

[Ruff]

Испытываю дискомфорт при большом скоплении флагов) Поэтому позволил себе альтернативную модификацию решения от S.Kuskov:

    enumerator = Lines.getEnumerator();
    for (errCount = 0; true; errCount++)
    {
        try
        {
            ttsbegin;
                while (enumerator.moveNext())
                {
                    stdClass.exceptionWarinigMethod(enumerator.current())
                }
            if (errCount == 0) ttscommit;
            else ttsabort;
        }
        catch
        {
            continue;
        }
        break;
    }