Здравствуйте, Shmj, Вы писали:

S>Очень важен вариант обработки ошибки вот какой, копирую:

S>

S>Если изменился пользователь а некая операция продолжила выполняться и завершилась после смены пользователя — то это не ошибка, это штатное поведение. Но при этом нельзя применять результаты данной операции — нужно сгенерить исключение. Но! Пользователю и даже в лог вносить это исключение смысла нет, т.к. ситуация штатная и доп. решения не треубет.

S>Т.е. важно уметь оборвать операцию в процессе, но при этом не тревожить пользователя лишними оповещениями, т.к. это штатная ситуация.

Это не "очень важен", это какое-то наркомание. Ложка огурцы банка майонез.

1. Что такое "изменился пользователь"? Во время операции ему (в другом потоке) изменили список ролей/привилегий? Или просто он отключился от "соединения"?
2. Что значит "применять результаты"? Операция — это, как правило, атомарное действие, у которого может быть результат (который просто возвращается, как результат вычисления выражения 2*3), а может быть эффект (который влияет на состояние, как результат выполнения стейтмента x = 2*3). Может быть и то и другое. В итоге, "не применять результаты" — это какой-то оксюморон: результат и так никуда не "применяют". А "не применять эффект" нужно детализировать: то ли разрешать частичное выполнение, то ли нет.
Вот, к примеру, MS SQL Server поддерживает heartbeet даже во время выполнения длинного запроса, который не предусматривает коммуникации с клиентом в процессе.
Ну, там insert into mytable(v) (select sum(values) from VeryLongTableWithoutAppropriateIndices lt where lt.tag % 17 = 3) — результат "1 row(s) updated" приедет только в самом-самом конце.
Но если я в процессе исполнения запроса отключусь (штатно там или аварийно), то сервер это заметит и выполнит rollback transaction.
3. Зачем генерировать исключение, которое вы не собираетесь ни вносить в лог, ни показывать кому-то?

В общем, вам надо аккуратно факторизовать задачу на составляюшие. И тогда решение станет очевидным.