Решил я как-то проверить каким образом вычисляются составные условия в 1С 8.1
Не думаю, что профи найдут для себя в этой статье нечто новое или интересное, но Капитан Очевидность продолжает вещать.
Первое, что пришлось проверить - не инициализированные переменные:
На код вроде:
А = 1;
Если (А=1) и (Б=1) Тогда
Сообщить("Ок!");
КонецЕсли;
Выругался сам "компилятор" при попытке сохранить обработку. Логично, так как переменная
Б нигде не определена. Но, если обмануть синтаксический контроль следующим образом:
А = 1;
Если 0=1 Тогда // заведомо ложное условие
Б=1; // никогда не выполняющийся код
КонецЕсли;
Если (А=1) и (Б=1) Тогда
Сообщить("Ок!");
КонецЕсли;
В этом случае при сохранении ошибки синтаксиса не будет, а при запуске надписи "Ок!" не появляется. По логике следования кода мы нигде не определяли переменную
Б, но код успешно выполняется.
Что говорит нам отладчик?
Обратите внимание, что в самом начале, когда ни одна переменная еще не определена память под них уже зарезервирована и им назначен тип "Неопределено", в отличии от переменной
В, которая вообще не упоминается в процедуре.
Сделаем пару шагов:
Теперь все очевидно. Условие совершенно корректно и дает на выходе ложь, так как единица не равна "Неопределено" и вообще разных типов.
Итак, предварительный вывод:
Под переменные, которые могут быть инициализированы, внутри своей области видимости память выделяется в самом начале и они неявно инициализируются типом "Неопределено".
Чисто теоретически следующий код мог бы работать:
А = 1;
Если (А=1) и (Б=1) Тогда
Сообщить("Ок!");
КонецЕсли;
Если 0=1 Тогда
Б=1;
КонецЕсли;
Но нет. Не проходит синтаксический контроль, что вообщем-то правильно.
Чем же эта информация может быть полезна? Например тем, что если в процессе отладки у вас какая-то переменная имеет тип "Неопределено", то возможно она была инициализирована неявно и вам стоит проверить свои условия. Хотя, вносить инициализацию переменной в условие вообще-то плохой тон. Да, да, как раз из-за вышеизложенного.
Однако, неявная инициализация это не совсем то, что я собирался выяснить с самого начала и я вернулся к условиям.
Следующий код работает как положено и выдает правильный результат:
Товар = Справочники.Номенклатура.НайтиПоКоду("00000026");
Если (ТипЗнч(Товар) <> Тип("Неопределено")) и (Товар.Наименование = "Тест") Тогда
Сообщить("Ок!");
КонецЕсли;
В описании функции "НайтиПоКоду" написано, что:
Если не существует ни одного элемента с требуемым кодом, то будет возвращена пустая ссылка.
Если код не задан, то будет возвращено Неопределено.
Если честно, я не смог сразу добиться от функции возврата значения "Неопределено" и потому поступил проще:
//Товар = Справочники.Номенклатура.НайтиПоКоду("00000026");
Товар = Неопределено;
Если (ТипЗнч(Товар) <> Тип("Неопределено")) и (Товар.Наименование = "Тест") Тогда
Сообщить("Ок!");
КонецЕсли;
Запускаем - бинго! Все работает, несмотря на то, что в составном условии есть обращение к реквизиту переменной "Товар", к "Наименованию", которого у типа "Неопределено" быть не может.
Для проверки попробуем еще два вида условия:
1.
Если (ТипЗнч(Товар) <> Тип("Неопределено")) или (Товар.Наименование = "Тест") Тогда
2.
Если (Товар.Наименование = "Тест") и (ТипЗнч(Товар) <> Тип("Неопределено")) Тогда
В первом случае мы поменяли "и" на "или" в условии, во-втором поменяли местами части условия.
В обоих случая при попытке выполнения мы получили сообщение об ошибке. Почему? Потому, что "компилятор" вычисляя выражение условия идет от начала к концу по-очереди вычисляя каждое вложенное выражение (по правилам арифметики, ага) и как только становится очевидно, что все выражение имеет определнный результат (истина/ложь) вычисление прекращается.
В нашем случае, когда мы сначала проверяли не является ли переменная "Товар" неопределенной и получали "ложь" смысл проверки остальных операндов утрачивался, так как в операции "И" достаточно одному операнду быть ложным, чтобы остальные можно было не проверять - все-равно конечный результат будет "ложь".
В первом случае, когда мы заменили "и" на "или" необходимость проверять все выражение возникла снова так как в определении "или" говорится, что истинным должен быть "хотя бы один" из операндов. Но пытаясь вычислить второй операнд мы сталкивались с ошибкой о которой я писал выше.
Во-втором варианте, результат выполнения так же изменился, несмотря на то, что операция "и" коммутативная. Теперь проверка начинала выполняться с первого, заведомо провального операнда.
Такое поведение, на мой взгляд оправдано и удобно. Сравните, например с похожим кодом в платформе 7.7:
//Товар = СоздатьОбъект("Справочник.Номенклатура");
//Товар.НайтиПоКоду(" 52200");
Товар = ПолучитьПустоеЗначение();
Если (ПустоеЗначение(Товар) = 0) и (Товар.Наименование = "Тест") Тогда
Сообщить("Ок!");
КонецЕсли;
В отличии от 8.1 он не будет работать, так как проверяются все операнды операции "и", а второй у нас будет выдавать ошибку.
Для платформы 7.7 пришлось бы применить следующее:
Если (ПустоеЗначение(Товар) = 0) Тогда
Если (Товар.Наименование = "Тест") Тогда
Сообщить("Ок!");
КонецЕсли;
КонецЕсли;
Что на мой взгляд является неоправданным (хоть и небольшим) усложнением структуры кода.
Итак, теперь вы можете смело записывать в одно условие конструкции, которые могут вызывать ошибки, в случае расхождения типов, главное не забывайте предварять их проверками на соответствие.
Спасибо за внимание и хорошего вам кода!
