Comments 3
У фильтров, кстати, есть очень забавный побочный эффект — поскольку они выполняются до отмотки кода, то они предоставляют потенциальную точку для выполнения внешнего (по отношению к вашему классу) кода, который может наблюдать состояние объекта. Все вроде бы ничего, но если у вас в методе есть код, который временно нарушает инварианты класса, то фильтры могут увидеть этот нарушенный инвариант.
Например, в классе есть два связанных друг с другом поля. Код обновляет сначала одно, а потом второе, при этом вычисление нового значения для поля может кинуть исключение. Обычно подобное оборачивают в try/finally, где в finally возвращают объект в изначальное состояние. Но фильтры выполняются до finally, и если у них есть ссылка на ваш объект, они могут увидеть его в состоянии, где первое поле уже обновилось, а второе — еще нет, и связывающий их инвариант нарушен.
Например, в классе есть два связанных друг с другом поля. Код обновляет сначала одно, а потом второе, при этом вычисление нового значения для поля может кинуть исключение. Обычно подобное оборачивают в try/finally, где в finally возвращают объект в изначальное состояние. Но фильтры выполняются до finally, и если у них есть ссылка на ваш объект, они могут увидеть его в состоянии, где первое поле уже обновилось, а второе — еще нет, и связывающий их инвариант нарушен.
Более подробно (с примерами кода, если кому непонятно пояснение) об этом когда-то писал Липперт. Примеры, правда, на VB.NET, потому что в 2004 году только он поддерживал фильтры исключений.
Это, конечно, жесть :) Мало того, что в фильтре используется код, который может бросить исключение, так он ещё и вызывается по рефлексии :)
Sign up to leave a comment.
Неожиданное поведение фильтров исключений в C# 6