AIF - как экранировать вызовы throw в аксапте

[ex3em]

Из вне вызывается метод Аксапты при помощи AIF код выполняется, но внутри метода генерируется исключение throw error в конструкции try catch. На этом вызов метода из вне валиться и в catch выполнение кода не происходит.

Ax2009
пример

try
{
    this.postPurch(_purchId); //внутри этого метода возникает throw error....
}
catch
{
    //а это уже не выполняется ((
    this.sendMail();
    return 'Ошибка во время разноски заказа';
}

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

[gl00mie]

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

[ex3em]

Очень на это похоже. Мой класс в Ах не содержит транзакций, а вот выше на системном уровне (откуда происходит сам вызов моего класса) скорее всего и стоит транзакция, но куда рыть не знаю. Т.е. не знаю цепочку системных вызовов которые идут до моего класса. Мой класс - потомок extends AifDocumentService.

[ice]

Цитата:

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

Очень на это похоже. Мой класс в Ах не содержит транзакций, а вот выше на системном уровне (откуда происходит сам вызов моего класса) скорее всего и стоит транзакция, но куда рыть не знаю. Т.е. не знаю цепочку системных вызовов которые идут до моего класса. Мой класс - потомок extends AifDocumentService.

так поставьте точку остановки и посмотрите

[ex3em]

Не могу поставить точку остановки. Так как вызов AX метода происходит из php кода

[ski]

Можно написать костыль - в первых строках метода написать ttsCommit, а после заключительной обработки ttsBegin. Сделать еще дополнительные проверки в коде на уровень транзакции и т.д.

[Владимир Максимов]

Цитата:

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

Не могу поставить точку остановки. Так как вызов AX метода происходит из php кода

Стека вызова возвращает статический метод Xsession::xppCallStack(). Этот метод возвращает контейнер, где нечетые элементы - это полный путь доступа и имя выполняемого метода, а четные элементы - номер строки метода. Соответственно, вывести стек вызова в инфолог можно так

    Container   conValue;
    int         i;
    ;

    conValue = Xsession::xppCallStack();

    for (i = 1; i <= conLen(conValue); i+=2)
    {
        info(strFmt('%1 (строка = %2)',conPeek(conValue,i), int2str(conPeek(conValue,i+1)));
    }

Для целей отладки вставьте этот код сразу за ключевым словом try. Получите информацию о стеке вызова и далее можете разбираться где была установлена транзакция

[Kabardian]

Посмотрите на статью на StackOverflow, нам помогла решить похожую проблему год назад:Can't catch exception inside AIF service

Цитата:

AIF has one big transaction somewhere deep in the core code and an own try catch.

So when you throw an error inside AIF sevice it is going to abort the outer transaction and go to staight to the AIF catch clause, skipping all others.

That's why I couldn't catch it. Solution could be to commit AIF transaction, run your code and before return begin new transaction.

Реализовано было примерно так:

Цитата:

//перед запуском операции закрывались все транзакциии
ttsLevel = appl.ttsLevel();

for (i = 1; i <= ttsLevel; i++)
{
ttsCommit;
}

//-->>...
//здесь вызывалась бизнес-логика (у нас запускался сервис Аксапты)
//--<<

//после выполнения операции транзакции заново открывались
for (i = 1; i <= ttsLevel; i++)
{
ttsBegin;
}

[Logger]

Интересно, а зачем AIF-у одна большая транзакция на все.
Какой в этом смысл ?
Ведь штатно невозможно нормально пользоваться обработкой исключений.
Кто-нибудь встречал пояснения от поставщика решения ?

[DSPIC]

Цитата:

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

Интересно, а зачем AIF-у одна большая транзакция на все.
Какой в этом смысл ?
Ведь штатно невозможно нормально пользоваться обработкой исключений.
Кто-нибудь встречал пояснения от поставщика решения ?

А на все - это на что? Импорт одного файла, вызов одной WCF функции - логично их держать per transaction для целостности данных.
Другое дело, что AX не умеет ловить вложенные try\catch...

[Logger]

Цитата:

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

А на все - это на что? Импорт одного файла, вызов одной WCF функции - логично их держать per transaction для целостности данных.

Логично ?
Ни разу.

Почему бы не предоставить самому обработчику решать - нужна ему единая транзакция или нет ?

[Vadik]

Цитата:

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

Почему бы не предоставить самому обработчику решать - нужна ему единая транзакция или нет ?

А в каких случаях она не нужна ?

[Logger]

Цитата:

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

А в каких случаях она не нужна ?

В наших

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

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

P.S.
Я вообще не против транзакций, я хочу сам рулить - когда их начинать и завершать. И хочу чтобы нормально ловились исключения. А не жульническими методами как выше описано.