Вопрос по поводу "Модификации были отменены". Что можно сделать?

[Hans]

Выдает сообщение при обработки заказа - накладная - "Модификации были отменены." и прекращает работу. Если это место закомментировать программа дальше тоже выдает ошибку, нужна складская аналитика, потом тоже выдает ошибку, так как не может разнести по проводкам.
А нельзя ли сделать так чтобы выдал сразу все ошибки, а то после throw ничего больше не делает. Спасибо!

[twilight]

Quote:

Originally Posted by Hans

Выдает сообщение при обработки заказа - накладная - "Модификации были отменены." и прекращает работу. Если это место закомментировать программа дальше тоже выдает ошибку, нужна складская аналитика, потом тоже выдает ошибку, так как не может разнести по проводкам.
А нельзя ли сделать так чтобы выдал сразу все ошибки, а то после throw ничего больше не делает. Спасибо!

А не проще ввести заказ правильно?
Я как-то не понимаю в чем смысл комментировать ошибки

[Hans]

А тогда можно узнать что делает эта команда?

[Dron AKA andy]

В Руководстве Разработчика поищите по этому слову, там все подробненько написано.

[DreamCreator]

Quote:

Originally Posted by Hans

А тогда можно узнать что делает эта команда?

Пример использования:

PHP Code:

static void testThrow(Args _args)
{
    ;
    try
    {
        throw('Генерация исключительной ситуации');
    }
    catch(Exception::Info)
    {
        checkFailed('Возникла исключительная ситуация:');
        Global::callStack2infolog();
    }
} 


[Hidden]

Задам свой первый вопрос с картинкой.
Вопрос: Как сделать так чтобы при разноске накладной выдавались сразу все ошибки по строкам, а не по одной? Это создает затруднения для пользователя, потому что ему приходится делать много раз разноску накладной для исправления всех ошибок по строкам заказа. Можно ли все таки так сделать?

[MironovI]

В складских журналах есть механзм проверки, для заказов писать придется по-моему..

[Dron AKA andy]

2Hidden:
Судя по вашему сообщению, Hidden и Hans - это одно лицо. Пункт 4.10 правил еще никто не отменял. Разберитесь с вашими никами, пожалуйста, не вводите людей в заблуждение.

[DreamCreator]

Quote:

Originally Posted by Hidden

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

Один из классов участвующих в проверке, можно поставить точку останова и смотреть стек вызовов, во всяком случае с него можно начать

\Classes\LedgerVoucherTransObject\check

[Hidden]

Quote:

Originally Posted by Dron AKA andy

2Hidden:
Судя по вашему сообщению, Hidden и Hans - это одно лицо. Пункт 4.10 правил еще никто не отменял. Разберитесь с вашими никами, пожалуйста, не вводите людей в заблуждение.

Это Программист у нас в отделе не мог картинку со своего компьютера вставить в сообщение(что то с настройками Эксплорера), я ему с моего компьютера предложил отправить сообщение, только Ник он не сменил поэтому получилось как будто я отправил сообщение. Извиняюсь.

[Hans]

По поводу ника, совершенно справедливо, есть проблемы в отправлении сообщенний на моем компьютере. Сейчас проверю \Classes\LedgerVoucherTransObject\check.

[Dron AKA andy]

2Hidden&Hans:

ОК, спасибо.

[Hans]

Quote:

Originally Posted by DreamCreator

Один из классов участвующих в проверке, можно поставить точку останова и смотреть стек вызовов, во всяком случае с него можно начать

\Classes\LedgerVoucherTransObject\check

У мне туда дебагер даже не попал, точка останова приводит к \Classes\InventOnhand\CheckItemDraw -
return checkFailed(strFmt("@SYS2176", _inventQty,this.availPhysical()));
\Classes\InventUpdate_Physical\updatePhysicalIssue - throw error("@SYS18447").

[DreamCreator]

Возникло две мысли

1. Причина того что мы видим одну ошибку -- после генерации исключительной ситуации оператором throw за ним ничего выполняется. Можно заменить все участвующие в обработке накладной операторы throw на что-нибудь менее жесткое. Чревато непредсказуемыми последствиями и трудоемко.

2. Чтобы логика алгоритма продолжалось после throw, однажды я использовал вложенные try..catch -- помогло.

[Hans]

Quote:

Originally Posted by DreamCreator

Возникло две мысли

1. Причина того что мы видим одну ошибку -- после генерации исключительной ситуации оператором throw за ним ничего выполняется. Можно заменить все участвующие в обработке накладной операторы throw на что-нибудь менее жесткое. Чревато непредсказуемыми последствиями и трудоемко.

2. Чтобы логика алгоритма продолжалось после throw, однажды я использовал вложенные try..catch -- помогло.

первый метод работает, если заменить throw на что-нить вроде checkFailed(), можно ли поступать таким образом. Пострадает ли от этого функционал?

[DreamCreator]

Quote:

Originally Posted by Hans

первый метод работает, если заменить throw на что-нить вроде checkFailed(), можно ли поступать таким образом. Пострадает ли от этого функционал?

Да, пострадает. Потому как checkFailed это аналог info (поправьте если не так), отличие только в иконке, таким образом несмотря на ошибку алгоритм не прервется как задумывалось ранее, а продолжится. И нет никакой гарантии что продолжится верно (ошибка ведь была -- допустим что-то не инициализировалось). Поэтому и трудоемко будет все переделывать.

[DreamCreator]

Можно написать свой отдельный класс в котором будут реалзованы все проверки с корректным сообщением. Вызывать до основной проверки. Но выйдет что проверка будет дважды -- это плата за нетронутый основной функционал.

[Hans]

Quote:

Originally Posted by DreamCreator

Да, пострадает. Потому как checkFailed это аналог info (поправьте если не так), отличие только в иконке, таким образом несмотря на ошибку алгоритм не прервется как задумывалось ранее, а продолжится. И нет никакой гарантии что продолжится верно (ошибка ведь была -- допустим что-то не инициализировалось). Поэтому и трудоемко будет все переделывать.

Вот это меня и интересует, мы не можем заменить throw, так как не знаем какая ошибка будет последней, я дошел до 6 ошибок в разных методах таблиц и классов, и когда необходимо будет делать прерывание чтобы накладная не оприходовалась. Дальше я вряд ли смогу что-нибудь придумать (уровень не позволяет), наверное лучше оставить стандартный функционал. Спасибо!

[Migel_84]

Quote:

Originally Posted by DreamCreator

Потому как checkFailed это аналог info (поправьте если не так)

Не так. info просто выводит сообщение, а checkfailed можно возвращать вместо супер, например
if (условие)
ret = checkfailed(какая-то ошибка);
else
ret = super();
return ret;

поправьте если не так

[Migel_84]

Quote:

Originally Posted by Hans

Вот это меня и интересует, мы не можем заменить throw, так как не знаем какая ошибка будет последней, я дошел до 6 ошибок в разных методах таблиц и классов, и когда необходимо будет делать прерывание чтобы накладная не оприходовалась. Дальше я вряд ли смогу что-нибудь придумать (уровень не позволяет), наверное лучше оставить стандартный функционал. Спасибо!

А как насчёт использовать логическую переменную? Убрать throw и, если хоть одна ошибка будет присвоить переменной true, а при оприходовании проверять, если переменная равна true, то не оприходовать