Что ж, если у Вас правило любой код заворачивать в Попытку - далее дискутировать бесполезно. Если интересно почитайте комментарии к статье https://infostart.ru/1c/articles/2053466/ и вообще литературу о таком подходе. И да, проблема большей частью не с производительностью кода в данном случае. И почему в загрузку обработкой нельзя добавить проверку - тоже не объясняете. А спроектировать правильно можно, это не иллюзия, было бы желание.
Да, я понимаю, что это стандартные обработчики. И в них никогда в стандартных конфигурациях не используется конструкция Попытка - Исключение. Вы видели такие примеры в коде типовых конфигураций, например, в этих обработчики? Вообще, конструкция Попытка - Исключение нужна в работе, когда мы имеем дело с транзакциями, например, или вызовом внешних сервисов, когда мы не можем гарантировать, как поведет себя система в тех местах, которые мы не контролируем. Если есть текстовое поле, которое мы даём ввести пользователю, и мы не можем его ограничить, чтобы оно было введено корректно и вынуждены ловить Попыткой ошибки - значит, что мы спроектировали что-то не так. К сожалению, повторюсь, такие вещи часто встречаются и в тиражных решениях (в конфигурациях Альфа-Авто, например) - и все эти места очень режут глаз и говорят о недоработанности решения.
Из плюсов - представленное решение понятно, просто и решает поставленную задачу. Конечно, реализация получилась очень частная, например, непонятно, как реализовать представление по нескольким полям.
Но сама реализация очень спорна с разных точек зрения. Например, заполнение поля "Альтернативное представление" для пользователя трудоёмко, правильно указать все эти ru, en и точки с запятыми в правильных местах - явно не задача пользователя. Напрашивается программное заполнение данного реквизита, чтобы форматирование происходило автоматически, но тогда поле не должно быть доступно в пользовательском режиме, а данные для его заполнения хранятся в нормальных полях "Английское наименование", "Российское наименование" и т.д. или в таблице соответствий Язык - Поле - Значение, например, Английский язык - Наименование товара - Метрические тонны.
Заполнение пользователями, видимо, приводит и к не очень хорошему коду. Попытка - Исключение сразу режут глаза, но, как я понимаю, это позволяет обойти ошибки заполнения. Тем не менее, такой код точно не прошел бы код-ревью. Нужно изменить архитектуру и избавиться от методов написания кода "оберну всё в попытку", чем грешат многие, закрывая ошибки проектирования. Заменить попытки как минимум нужно на проверку того, что содержится в параметре Данные (содержится ли ключ с нужным полем) + проверка корректности форматной строки.
Что ж, если у Вас правило любой код заворачивать в Попытку - далее дискутировать бесполезно. Если интересно почитайте комментарии к статье https://infostart.ru/1c/articles/2053466/ и вообще литературу о таком подходе. И да, проблема большей частью не с производительностью кода в данном случае. И почему в загрузку обработкой нельзя добавить проверку - тоже не объясняете. А спроектировать правильно можно, это не иллюзия, было бы желание.
Хорошо. Тогда в каких случаях мы ожидаем, что функция НСтр не сработает?
Да, я понимаю, что это стандартные обработчики. И в них никогда в стандартных конфигурациях не используется конструкция Попытка - Исключение. Вы видели такие примеры в коде типовых конфигураций, например, в этих обработчики? Вообще, конструкция Попытка - Исключение нужна в работе, когда мы имеем дело с транзакциями, например, или вызовом внешних сервисов, когда мы не можем гарантировать, как поведет себя система в тех местах, которые мы не контролируем. Если есть текстовое поле, которое мы даём ввести пользователю, и мы не можем его ограничить, чтобы оно было введено корректно и вынуждены ловить Попыткой ошибки - значит, что мы спроектировали что-то не так. К сожалению, повторюсь, такие вещи часто встречаются и в тиражных решениях (в конфигурациях Альфа-Авто, например) - и все эти места очень режут глаз и говорят о недоработанности решения.
Из плюсов - представленное решение понятно, просто и решает поставленную задачу. Конечно, реализация получилась очень частная, например, непонятно, как реализовать представление по нескольким полям.
Но сама реализация очень спорна с разных точек зрения. Например, заполнение поля "Альтернативное представление" для пользователя трудоёмко, правильно указать все эти ru, en и точки с запятыми в правильных местах - явно не задача пользователя. Напрашивается программное заполнение данного реквизита, чтобы форматирование происходило автоматически, но тогда поле не должно быть доступно в пользовательском режиме, а данные для его заполнения хранятся в нормальных полях "Английское наименование", "Российское наименование" и т.д. или в таблице соответствий Язык - Поле - Значение, например, Английский язык - Наименование товара - Метрические тонны.
Заполнение пользователями, видимо, приводит и к не очень хорошему коду. Попытка - Исключение сразу режут глаза, но, как я понимаю, это позволяет обойти ошибки заполнения. Тем не менее, такой код точно не прошел бы код-ревью. Нужно изменить архитектуру и избавиться от методов написания кода "оберну всё в попытку", чем грешат многие, закрывая ошибки проектирования. Заменить попытки как минимум нужно на проверку того, что содержится в параметре Данные (содержится ли ключ с нужным полем) + проверка корректности форматной строки.