СоответсвиеПредставленияРезультата = Новый Соответствие;
    СоответсвиеПредставленияРезультата.Вставить(Перечисления.ОбнаруженоНеОбнаружено.ПустаяСсылка(),"?");
    СоответсвиеПредставленияРезультата.Вставить(Неопределено,"?");
    СоответсвиеПредставленияРезультата.Вставить(Перечисления.ОбнаруженоНеОбнаружено.Обнаружено,"+");
    СоответсвиеПредставленияРезультата.Вставить(Перечисления.ОбнаруженоНеОбнаружено.НеОбнаружено,"-");


однако оказывается Неопределено ключем быть не может ... вот и не расстройся

(57) в 1с фабрика не нужна.

"Оно не так реализуется"
Ну, фабрика может реализоваться через общий интерфейс, но тут чувствительность к null ещё сильнее.

Может приведёшь уже свои примеры? Как в шарпе доблестно и просто отбиваются одним null на все случаи жизни

(63) "Ну то есть ты по сути предлагаешь заменить эксепшн возвратом признака и описания ошибки"

Ты про что вообще? Зачем возвращать признак и описание ошибки?

(63) посмотри ещё раз внимательно пример. Это не некорректный параметр, это просто неучтённое значение, которое приведёт к null на выходе

(60) (Неопределено = Неопределено) = Истина?

Ну а я вот несогласный. (Неопределено=Неопределено) = Ложь.
Переубедите меня :)

Шутка. На самом деле я полагаю что такое сравнение не имеет смысла.
Скорее всего это ложь, потому что неопределенности могут быть разной природы.
А может, и нет. А может, да.

Закинул ТС небольшой странный пятничный тупнячок и пропал
А в ветку продолжали и продолжали писать личности, не имеющие доступа к конфигуратору и реальных задач

(68) А тут пришёл Рома, но так как он не лесник, то тихо пукнул в лужу...

(65) Ты привел пример "плохого" кода из шарпов, который выкидывает эксепшн в случае передачи методу неправильного параметра.
А я ответил - что в 1С нужно делать тоже самое и точно так же. А то, что это почти никто не делает - из той же серии почему в 1С почти никто тестов не пишет.

(69) Дружок, про всякие соответствия, Неопределено и NULL и на ИТС уже все давно расписано и в интернете вагон инфы
Но постоянно находятся особо одаренные, которые не умеют читать СП и в итоге постоянно какие-то споры о том, Неопределено = Неопределено или нет, NULL = Неопределено или нет и прочая пурга

(71) все тут прекрасно понимают как ЭТО работает
вопрос тут ближе к теме - зачем породили столько разных сущностей, вот собственно и все

(71) Да я не против, в общем, нравится тебе из себя пузырики выпускать - ну что уж тут поделать, старого пса новым трюкам не научишь.

(71) Раз хорошо знаком с документацией, опровергни (40) и закроем вопрос :)

(74) Рома сможет объяснить только, почему ты дурак, а он дартаньян :)

Потому что он соответствия соответствовал, когда вы еще пешком под стол ходили!
У нас субординация и выслуга лет!

(54) плохой код, хрупкий...
его придется дописывать при добавлении каждого нового вида
действительно, нужно опираться на интерфейс

а иначе вырастают такие вот монстры как в типовых а-ля методов ОбработатьСтрокуТЧ

(72) Каких сущностей-то?
Ты опять сейчас начнешь тянуть зеленую соплю о том, что множество разнообразных незаполненных значений взрывают твой мозг?
А то так-то все просто
Неопределено — это когда переменная есть, а тип значения не установлен, в итоге Неопределено
NULL — это вообще из запросов тянется, ситуация, когда вообще ничего нет, то есть пусто, вакуум то бишь
Про соответствие вообще не понял, что тут лишнего

(78) "Про соответствие вообще не понял, что тут лишнего"
Ну не понял и не понял, идем дальше

(74) А что тут опровергать-то?
Неопределено в качестве ключа использовать нельзя, пусть даже это не написано в явном виде в СП
Так-то вообще до кучи вещей можно доДДСиться, было бы желание
Проверка примитивная


С1 = Новый Соответствие;
С1.Вставить(1, "Зн1");
С1.Вставить(2, "Зн2");

Сообщить("Ответ " + С1.Получить(1));
Сообщить("Ответ " + С1.Получить(3));
Сообщить("Ответ " + С1.Получить(Неопределено));

С2 = Новый Соответствие;
С2.Вставить(Неопределено, "Н");
С2.Вставить(1, "Зн1");
С2.Вставить(2, "Зн2");

Сообщить("Ответ " + С2.Получить(1));
Сообщить("Ответ " + С2.Получить(3));
Сообщить("Ответ " + С2.Получить(Неопределено));


выдает

Ответ Зн1
Ответ
Ответ
Ответ Зн1
Ответ
Ответ

(15) Структура начиная с 8.2 тоже хешируется, т.е. является полностью аналогом соответствия (ну только ограничения на значение ключа наложено)

эх времена были v8: Почему Неопределено не может быть ключом соответствия?

(80)
проверку то я делал, и гораздо проще и понятнее:  
С2 = Новый Соответствие;
С2.Вставить(Неопределено, "Н");
Сообщить(С2.Количество());

И мой вывод, что это баг. А ты пришёл с рассказами, что на ИТС и в СП всё расписано.

(83) Ну так удали в (40) "не" в тексте "На самом деле невозможность использовать" и будет сразу понятнее
А то сейчас звучит так, что типа невозможно использовать и это баг, должно быть возможно
А по факту у тебя получается, что невозможно, а баг — это то, что строка вставки с ключом Неопределено хоть и не добавляет записи, но не выдает исключения

(84) Под "использовать" естественно имелось в виду в том числе и получение по ключу, что по факту невозможно.
И естественно предполагалось, что читающий это сообщение в данной ветке знает о фактическом поведении системы. Предположение понятно в общем случае ложно, но для заинтересованных - верно.

(85) Ну так я и говорю, что невозможность получения — это не баг, а нормально, так и должно быть
А ты говоришь, что баг

(85) Самый главный вывод - чтобы избежать неопределённого поведения, надо при добавлении ключ соответствия проверять на Неопределено :)

(86) Почему нормально? В документации такое поведение не указано, теоретических преград - я не вижу.

(88) Да давай уже, признайся, что дурак, а то он ведь от тебя не отстанет.

(88) Потому что баг в данном случае — это невыдача исключения при выполнении такой строке
Ну а то, что не описано в доке — я же говорю, недоработка, в СП полно таких недоработок, че ж теперь

(89) Ты же понимаешь, что дураком здесь выглядишь только ты?

(90) недоработка это тоже баг
(91) ты неправ

(90) Баг - в целом такое поведение.
Ты ожидаешь исключения, а я ожидаю нормальной работы с ключом Неопределено.
Любой из этих вариантов был бы нормальным.

(92) Рома никогда в жизни не признается, что не прав, не по пацански это :))

(93) Ну, так-то ты прав, на мой взгляд логичнее было бы запретить Неопределено в качестве ключа

(94) Иди говна поешь :))

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

(96) кого это высказывание характеризует?

(96) Рома, я охотно верю, что ты это практикуешь, и что тебе это помогает, но нет, откажусь, пожалуй.

(63) Бизнес-приложение падать не должно - из-за этого теряются бабки. Оно должно работать, максимум лепетать что-то про некорректность.

А вообще, надо смотреть, относится ли тип Неопределено к множеству типов "Произвольный". Судя по тому, что его нельзя добавить в качестве типа в ОписаниеТипов - нет.

(90) Это не баг, это фича. Чтобы приложение не падало, если вдруг в качестве ключа Неопределено пролезет.

(102) Но если оно у тебя пролезет, ты об этом никогда не узнаешь. Может ли это быть критичным в определённых ситуациях?

(103) Если это критично - ставь проверку. Если не критично - пусть работает. Расчет на попоруких копрокодеров. Ну и, если посмотреть с прикладной точки зрения - если вдруг где-то пролезло Неопределено в качестве ключа - скорее всего и значение там будет тоже незаполненным, т.е. Неопределено.

(104) как объяснение на уровне "сам дурак" подойдёт

(104) Ну вот, например, пишешь ты в соответствие связку Заказ-ПТУ, Заказ получаешь какой-нибудь хитрой функцией, которая может вернуть Неопределено, если не проверять Заказ на Неопределено, ты потеряешь минимум одно ПТУ :) Так что склонен всё-же отнести такое поведение, и отсутствие его внятного описания в документации, к ошибкам. Но если об этом помнить, и проверять на Неопределено ключ соответствия, то никаких проблем, да.

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

(100) Если ты обрабатываешь в коде конкретную ошибочную ситуацию - то все хорошо. Это уже не баг, а предусмотренная программистом ситуация с описанными вариантами ее разрешения. Проверка же входных параметров с эксепшнами - это последний защитный барьер на тот случай, если ты в коде натупил и допустил очевидные баги.

(100) Банальный пример. Ты вызываешь метод с числовым параметром из недопустимого диапазона. Если ты хочешь мягко обработать некорректный ввод пользователя - ты должен сделать это до вызова метода. Если ты уже вызвал метод с некорректным параметром, значит ты этого не сделал и функция не сможет выдать корректный результат. Определять ошибку входных параметров по результату работы метода - это глупо. Во-первых, программист может забыть это сделать во всех местах использования метода (и получит тот самый плавающий баг). Во-вторых, в этот момент неудобно устанавливать конкретную причину. Либо ее надо пробрасывать в результат работы метода, либо программисту придется полностью воспроизводить ситуацию.

В golang прикольнее решили. Ты выбрасываешь эксепшн не "куда-то туда", а прямо в результат работы метода. И принимать решение что с этим делать нужно не "где-то там", а сразу при обработке результата работы метода. Тут есть и минусы и плюсы. Я из лагеря тех, кто плюсов видит больше, чем минусов.

(109) + При этом, даже если ты определяешь ошибку входных параметров по результату работы метода - то наиболее частый сценарий это все равно остановка работы программы с выдачей сообщения об ошибке. То есть ровно тоже самое что произойдет при выбросе либо вообще не обрабатываемого эксепшна, либо с глобальным перехватчиком эксепшнов (для "облагораживания" их отображения пользователю). Такую возможность, кстати, в последних релизах добавили (глобальный перехватчик эксепшнов).

(106) Как ты его потеряешь? Ты же сравнишь то, что привязалось к заказам, и то, что нет - и выдашь список непривязанного. Выведешь сообщение вида "К заказу Не определено нет ПТУ".

(107) Ну да, конечно. Лучше бизнесу вообще ничего не делать, потому что программа не работает, чем делать бизнес и ВОЗМОЖНО что-то потерять.

(112) Ничего я не сравниваю в общем случае, просто заполняю соответствие, чтобы дальше там что-то с этим соответствием делать. Пример же утрированый, может быть этот заказ получается веб-сервисом из внешней базы, например :) Но в общем не суть, хороший стиль программирования должен включать в себя проверку соответствия входных параметрам типам принимаемых параметров.

(109) В бизнес-логике редко когда передается один параметр. При этом каждый из параметров по отдельности может иметь допустимое значение, но их сочетание может быть недопустимым. Поэтому вызываемая функция один фиг должна проверять сочетание параметров на корректность. Так что единичный баг будет достаточно быстро выловлен.

(115) Этак мы сейчас до модульного тестирования договоримся :)

(116) Ну, если бизнес пойдет вширь - к этому все равно рано или поздно придется обратиться ;) А пока бизнес мелкий - он может сэкономить на квалификации исполнителей.

(117) С какого уровня бизнес перестаёт быть мелким? Завод с 1000 работникам, торговая сеть с 1000 магазинов? Оптовик с 5000 клиентами? Каковы критерии?

(118) Как только автотестирование становится необходимым - бизнес можно считать крупным...

(119) О, точно, офигенный критерий :)))

(119) Про Сонар куб? ... .да прикольно

(121) Сонар - не панацея

(121) Сонар куб  - это статический анализ, этого для качества программного продукта недостаточно.

(118) Когда потери от копрокода станут больше сопоставимы или больше затрат на нормальную разработку ;)

вот
в развитие темы - а как в табличной части найти строки с незаполненным составным типом?

т.е. есть строка в ТЧ со значением реквизита =  неопределено


ТЧ.Найти(Неопределено,"Результат") = Неопределено;

(124) Ну так это не от размера бизнеса зависит, если что.

(125) ЗАпросом

(125) разве не работает?
Ну или найтистроки

(125)
Отбор = Новый Структура("ТвойРеквизит", Неопределено);//пустые ссылки в отбор не попадут!
СтрокиСНеопределено = ТЧ.НайтиСтроки(Отбор);

Если в функцию не передан параметр,то значение будет Неопределенно,другими словами,система считает,что параметр не передали

(130) Тогда исключение должно быть, параметр же обязательный.

(131) Почему исключение, в 1С любой параметр можно пропустить, независимо от того, задано для него в сигнатуре значение по умолчанию или не задано

(126) У мелкого бизнеса потери в абсолютном выражении меньше, а затраты на правильную разработку имееют явно выраженную постоянную часть, а потому у них порог случается гораздо позже ;) Если вообще случается.

(127) С запросом еще веселее: Неопределено при проверке условия "Неопределено В (&Параметр)", дает истину даже если в списке явно нет значения Неопределено.

(133) " Неопределено В (&Параметр)", дает истину даже если в списке явно нет значения Неопределено "

Сам придумал?

(132) " в 1С любой параметр можно пропустить "

Да откуда такое? Я про 8-ку

(132) А как тогда трактовать термин "обязательный"?

(132) Вечно ты путаешь 1С с какими-то другими языками.

(133) Тогда вернёмся к вопросу - С какого уровня бизнес перестаёт быть мелким? Завод с 1000 работникам, торговая сеть с 1000 магазинов? Оптовик с 5000 клиентами? Каковы критерии?

(138) законодательно после over 250 сотрудников и/или 2 млрд оборота

(139) Тогда всё вышеперечисленное крупный бизнес, но вполне себе работает без тестирования ПО. В чём-то другом причина применения тестирования, точно не в размере бизнеса, значит.

(135) И я

(136) Без значения по умолчанию

(142) Почему тогда все остальные функции дают исключение. Попробуй СокрЛП()

(143) А, мы про "системные" методы. Я про прикладные говорил.
Но в системные вместо пропуска обязательно параметра достаточно передавать "Неопределено" в явном виде и тогда исключение уже не возникает.

(144) Изначально речь была про
  Соответсвие.Вставить(Неопределено, ЧегоТо)
Мой опыт тоже говорит, что неопределено вполне себе параметр, а в (130) предполагается иное

(144) прикладные точно также работают, проверяйте вначале

(146) Ошибаешься

пропуск параметра и передача неопределено - это разные вещи

(147) зачем ты откровенно говоришь ложь?

Недостаточно фактических параметров
{ВнешняяОбработка.ПримерПропускаПараметра.Форма.Форма.Форма(4)}:    ОбщегоНазначенияКлиентСервер.ЗапуститьПрограмму();

(149) Ни одного не указывать точно нельзя, да.

(149) Приведенный тобою фрагмент не имеет никакого отношения к пропуску параметра / параметров

(151) давай свой

(152) ОбщегоНазначенияКлиентСервер.ЗапуститьПрограмму(,);

(153) интересное поведение, а если бы там был все-таки один параметр?

(154) Пропустить единственный обязательный параметр не получится, в этом случае эквивалентного эффекта можно добиться через передачу значения Неопределено.
И тоже никаких исключений не будет.

(155) хех, это описанный эффект в языке7

(156) Конечно. На ИТС в абзацах где про "опущенные" параметры. В свое время этот термин вызывал у меня улыбку.

(157) спасибо, как-то пропустил этот момент, действительно:

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

Но довольно сомнительное свойство языка

(140) тестирование применяют в основном серьёзные конторы. Обычно это холдинги от нескольких десятков тысяч человек, у которых ИТ-департаменты. Конторы численностью до 2-3 тысяч могут применять ларёчные подходы

(158) Это откуда цитата?

(160) Нашел в разделе по 8.2.
Там устаревшие и неполные / неточные формулировки. Смотри в 8.3.

(160) СП

И на ИТС рекомендация: "7. При вызове функций не следует пропускать обязательные параметры. В противном случае, в параметр будет передано значение Неопределено, на которое функция может быть не рассчитана. Если же значение Неопределено является допустимым, то нужно или его передавать в функцию явно, или сделать этот параметр необязательным со значением по умолчанию Неопределено."