Отправьте баги в Майкрософт

[Jabberwocky]

Уважаемый ZVV, Вы правы лишь отчасти, и то - с точностью до наоборот. Попробуйте в методе PurchLine.delete() заменить

TaxWorkRegulation::deleteRegulation_W(this);

на что-нибудь вроде:

ttsbegin;
throw error('');
ttscommit;

Уверяю Вас, удалить строку закупки Вам после этого не удастся, т.к. при удалении строки из формы неявно (implicit) инициируется транзакция, и возникновение исключения внутри неё или в любой из вложенных транзакций откатывает её (и все вложенные транзакции) полностью.

Отсюда Ваш вывод относительно кода в SalesLine.delete(); также неверен, - здесь как раз транзакционные скобки являются лишними, но их присутствие не так уж критично.

[ZVV]

Вы чертовски правы, Jabberwocky. Действительно, всё наоборот. Слона то я (неявного) и не приметил. Спасибо!

Даже если вызовы идут и не из формы, а в коде, то там всё равно практически всегда будет присутствовать явная транзакция извне... Разве что вставку можно без транзакции сделать, и тогда всё-таки SalesLine.insert() пройдёт в двух транзакциях. Но это не сильно типичная ситуация, имхо.

Тогда сформулирую обратный вопрос: а зачем в методах Sales/PurchSalesLine.insert/update/delete() организованы эти масштабные try-catch блоки? Ведь получается они никогда не работают, или всё таки работают, но тогда что-то не понимаю когда?

[alex55]

Цитата:

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

Тогда сформулирую обратный вопрос: а зачем в методах Sales/PurchSalesLine.insert/update/delete() организованы эти масштабные try-catch блоки? Ведь получается они никогда не работают, или всё таки работают, но тогда что-то не понимаю когда?

Работают в случае Exception::UpdateConflict, как минимум:
TTS и try..catch

[ZVV]

Цитата:

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

Работают в случае Exception::UpdateConflict, как минимум:
TTS и try..catch

Ну да, перехватит, конечно...
И отправит дальше!
Потому что appl.ttsLevel() <> 0...

[gl00mie]

Цитата:

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

if (! this.validate())
    throw error("");

считаю, что

throw Exception::Error;

как-то посимпатичнее и пишу в таких случаях именно так.

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

Цитата:

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

А с другой стороны почему бы не написать лишний раз, что не получилось там что-то сделать.

Мне кажется, в таких ситуациях просто необходимо писать еще какое-то сообщение - и вот по какой причине:

• у Аксапты есть замечательная, пусть и несско глючная, возможность указывать префиксы для выводимых сообщений, что позволяет создавать информативные сообщения и в то же время не тянуть всю необходимую для них информацию через весь стек вызываемых методов (например, «обработка заказа такого-то/строка ндцатая, номенклатура такая-то/проверка блокировок/склад такой-то/заблокировано по складу»);
• построение дерева сообщений infolog'а (я так понимаю, \Classes\Info\viewBuild) криво работает с префиксами, если сообщение лишь одно; т.е. в этом случае префикс почему-то не используется, будто он важен, лишь когда сообщений несколько.

В результате, если в данном примере метод validate() вызывает кучу вложенных методов, и на разных уровнях стэка вызова устанавливаются префиксы для возможных сообщений, а затем выводится одно сообщение об ошибке (скажем, из-за того, что номенклатура такая-то заблокирована по складу такому-то), то в приведенном выше примере в случае простого выброса Exception::Error в инфолог выведется лишь «заблокировано по складу» без какой-либо детализации, закладываемой в префиксы на каждом уровне стека вызова. Дополнительное же сообщение, наподобие "модификации были отменены", поспособствует тому, что инфолог построит нормальное дерево сообщений со всеми префиксами.