Понимание необходимости этой статьи пришло ко мне, когда я после бессонной ночи, проведенной за отладкой чужих «багов», читал статью одного из авторов нашего журнала и натолкнулся на засилье операторов as, используемых вместо оператора приведения типов.

В программе не было ни одного приведения типов, но постоянно встречались as. Мои попытки объяснить порочность данной практики были тщетны. Упорство, с которым отстаивалось применение as-ов, было воистину достойно лучшего применения.

A>Не совсем понятно, почему так легко отметается все-таки основной аргумент — скорость, а упор делается на в общем-то практически и не аргумент (эстетизм).

Но можно ли жертвовать надежностью ПО ради скорости?

_FR>>Очевидно, что сообщение в рантайме об ошибке приведения типов даст более правильную информацию, нежели ошибка обращения по нулевому поинтеру что позволит гораздо точнее локализовать место её возникновения и, соответственно, исправить.

A>Очевидно, что ошибка в production как в результате несловленного исключения, так и в результате не проверки на null — абсолютно неприемлемое поведение программы.

1. Ошибка может возникнуть и у бета-тестеров, не имеющих под рукой отладчика и исходников.
   
2. Если нам всё-таки не повезло и она появилась у енд-юзера (что поделать, и такое бывает ), то найти её будет много проще.

A>Посему, если мы будет говорить про написание качественного кода, т.е. кода, в котором предусматривается проверка на null или ловится исключение, надежность одинаковая, а по скорости выигрывает as. Вроде бы все очевидно. Совершенно не понятно, о чем спорить и это ИМХО тема вопроса в FAQ на 10-15 строк, а не статьи на несколько экранов.

int i = (int)-1.2;

System.Int32 i = (System.Int32)-1.2;

A i = (A)-1.2;

System.Int32 i  = (System.Int32)(-1.2);
int          i1 = (int)(-1.2);
A            i2 = (A)(-1.2);

((B)a).SomeMethod();

((D)((C)((B)a).Xxx).Yyy).SomeMethod();

(((a as B).Xxx as C).Yyy as D).SomeMethod();

D(С(B(a).Xxx).Yyy).SomeMethod();

AL>И что Вы тогда скажете о ВБшном CType (fromObject, toType)?

int    i = 123;
void*  p = &i;
double d = *(double*)p;
printf("i = %f", d);

int    i = 123;
void*  p = &i;
double d = ((double)*p);
printf("i = %f", d);

int    i = 123;
void*  p = &i;
double d = *(double*)p;
printf("i = %f", d);

При попытке повторить этот код в безопасном режиме C#:

int    i  = 123;
object p  = i;
double d = (double)p;
Console.WriteLine("value = {0}", d);

class A { }

class B : A
{
  public void SomeMethod() { }
}

class Test
{
  static B _b;

  static void Init(A a)
  {
    _b = a as B;
  }

  static void Main()
  {
    Init(new A());
    // ...
    _b.SomeMethod();
  }
}

Естественно, в таком простом коде не составит труда быстро найти настоящую причину. Но представим, что этот класс занимает тысячу строк витиеватого кода, да ещё, может быть, это реализуется не один классом, это может быть целый фреймворк. Найти истинную причину в этом случае может оказаться не совсем просто.

Но всё-таки после нескольких бессонных ночей я выхожу на A.CreateInstance и выясняю, что проблема в моём собственном коде, и понимаю, что сам дурак. Далее, чтобы избежать длительных поисков подобных ошибок в будущем, я привожу за ухо того, кто писал этот код и прошу его заменить as на cast. Но его аргументы такие: ошибка не в его коде, она уже исправлена мной самим в моём коде, и, главное, он не знает к чему приведут такие изменения, т.к. писал он это давно и уже не помнит, завязана ли его логика на возможный null или нет. Всё остается, как есть, и впоследствии на эти грабли наступают другие разработчики, тратя на борьбу с ними много времени.

a = b;
if (a != b) ReportRAMError();

Использование штатного оператора приведения типов «()» не делает код правильнее автоматически и не защищает от ошибок. С точки зрения функциональности код останется точно таким же. Оператор () позволит локализовать ошибку в месте, наиболее близком к ее появлению. А это в свою очередь позволит сэкономить немало вашего (и не только) драгоценного времени.

try
{
  ((B)a).SomeMethod();
}
catch(Exception e)
{
}

B b = null;
try
{
  b = ((B)a);
}
catch(Exception e)
{
}
b.SomeMethod();

if (a is B)
{
 (a as B).SomeMethod();
}

Одним из аргументов в пользу применения оператора as вместо приведения типов, является слова «в этом случая я могу доказать, что приведение всегда будет проходить успешно». Все мы люди и можем ошибиться, не учитывать каких-то еще не известных в данный момент нюансов, да и попросту могут произойти какие-то изменения.

Расследование показало, что в данном программном модуле присутствовало целых семь переменных, вовлеченных в операции преобразования типов. Оказалось, что разработчики проводили анализ всех операций, способных потенциально генерировать исключение, на уязвимость. И это было их вполне сознательным решением – добавить надлежащую защиту к четырем переменным, а три – включая BH – оставить незащищенными. Основанием для такого решения была уверенность в том, что для этих трех переменных возникновение ситуации переполнения невозможно в принципе. Уверенность эта была подкреплена расчетами, показывающими, что ожидаемый диапазон физических полетных параметров, на основании которых определяются величины упомянутых переменных, таков, что к нежелательной ситуации привести не может. И это было верно – но для траектории, рассчитанной для модели Ariane 4. А ракета нового поколения Ariane 5 стартовала по совсем другой траектории, для которой никаких оценок не выполнялось. Между тем она (вкупе с высоким начальным ускорением) была такова, что "горизонтальная скорость" превзошла расчетную (для Ariane 4) более чем в пять раз.

A>if (a is B)
A>{
A> (a as B).SomeMethod();
A>}
A>

B b = a as B;
if( b != null )
  b.SomeMethod();

Правила:
1. Если необходимо реализовать дополнительную логику работы с объектом, приведеным к другому типу, то используется оператор as:

X x = o as X;
if( x == null )
  return;
x.DoWork();

2. Если необходимо проверить, является ли объект определённого типа, но нет необходимости работать с приведеным объектом, то используется оператор is:

if( o is X )
  SomeLogic();

3. И наконец, если с объектом нужно работать только как с объектом определённого типа, то используется оператор приведения ():

X x = (X)o;
x.DoWork();

Исключения:
4. Value-типы не поддерживают оператор as, поэтому вместо (1) используется комбинация (2) и (3):

if( v is X )
  ((X)v).DoWork();

5. Оператор as не поддерживает приведения типов, определённые пользователем.

F>Правила:
F>1. Если необходимо реализовать дополнительную логику работы с объектом, приведеным к другому типу, то используется оператор as:
F>2. Если необходимо проверить, является ли объект определённого типа, но нет необходимости работать с приведеным объектом, то используется оператор is:
F>3. И наконец, если с объектом нужно работать только как с объектом определённого типа, то используется оператор приведения ():
F>4. Value-типы не поддерживают оператор as, поэтому вместо (1) используется комбинация (2) и (3):

F>Все доводы по эстетике, читабельности и быстродействию идут лесом. И попробуйте меня сбить с пути истинного

…указывать на орфографические и синтаксические ошибки и т. д. запрещается.