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

[Hans]

Цитата:

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

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

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

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

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

[DreamCreator]

Цитата:

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

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

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

[Hans]

Цитата:

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

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

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

[Migel_84]

Цитата:

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

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

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

[Hans]

Цитата:

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

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

Идея хорошая, я в данный моменты просто добавил свой цикл, перед основным while (salesParmLine) в Classes\SalesFormLetter_Invoice\updateNow и там все методы продублировал, где заменил все throw на info. Если бы я точно знал в каком месте можно поставить проверку на глобальную переменную, чтобы накладная точно не приходывалась, я бы так и сделал, но я не знаю в каком месте накладная по Заказу приходуется (я имею в виду себестоимость, проводки и т.д).

[Migel_84]

Цитата:

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

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

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

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

[DreamCreator]

Цитата:

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

Не так. info просто выводит сообщение, а checkfailed можно возвращать вместо супер

Да, согласен. Спасибо!

Как раз сегоня воспользовался:

PHP код:

    if(!this.parmInvoiceId(this.parmSalesIdNonPrefix()))
        ret = checkFailed(strfmt("@SYS26332",
                new DictType(extendedTypeNum(SalesId)).label()));