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


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

Странно, да?

А ещё NULL ты не можешь туда впихнуть...

И слава БГ, что не можешь.

Вообще - да. Странно. Неопределено и null - особые типы. Но иметь возможность использовать их в качестве ключей была бы удобной.

(0) Продолжайте наблюдения.

(4) А еще ХранилищеЗначения и ДвоичныеДанные, да?

(6) Нет.

(4) они значения, а не типы

(3) БГН!

(8) Про null не помню, а Неопределено является ЕМНИП отдельным типом. Ну, чтобы корректно в полях составного типа отрабатывать.

(10) и тип и значение

(11) Ага. Единственное значение своего типа. Типа :)

(4) Есть СписокЗначений, там можно.

(13) Я подозреваю, что это просто техническая фича. Структура и соответствие являются хэш-структурами и конкретный тип должен поддерживать генерацию хэша для этих целей. Ну а для Неопределено по каким-то соображениям решили этого не делать. Может, какой-то высокий смысл в этом и есть. Но мне отсюда его не видно. А список значений - обычная коллекция, не на хэшах.

Тьфу ты. Для структуры же ключ - обычная строка. Т.е. вышенаписанное конкретно только для соответствия актуально.

(8) Типы тоже. В этих типах по одному значению.

Null нормально ключ, а неопределено нет

Это же 1с. Любители пустых значений

(18) Только хотел сказать, что главный ненавистник Неопределено в чате :) Еще один пункт в копилку ненависти :)

(19) да мне уже пох.. Просто стоит обратить внимание на тот же Шарп, где справляются одними null

(20) почему именно шарп?

Соответствие (Map)
Получить (Get)
Синтаксис:

Получить(<Ключ>)
Параметры:

<Ключ> (обязательный)

Тип: Произвольный.
Ключ значения.
Возвращаемое значение:

Тип: Произвольный.
Значение элемента соответствия.
Неопределено - если указанный ключ отсутствует.

Мне сразу было пох :) Этот двуликий анус особо жить не мешает. Благо правила игры простые.

(22) Браво! А слона-то никто и не заметил :)

(0) всё намного проще. Не суй никаких пустых значений в соответствие. А если соответствие ничего не вернуло, считай будто бы вернуло "?"

(20) А что в шарпе возвращают в качестве пустого результата поиска?

(26) А в 1с что возвращают?

(20) обходятся, только более дорогой ценой

(27) Для массивов/соответствий - Неопределено. Поэтому отпадает вариант помещать в них это самое Неопределено.

(22) так это значение, а не ключ

Вместо Неопределено вставляйте "У холмов есть глаза"

Тип (и значение) Неопределено есть в 1С потому, что есть составные типы. Для обозначения того, что нечто составного типа не только не содержит значения, то и конкретный тип не определен. Использование Неопределено для обозначения того, что функция/метод ничего не вернул, это уже вторично.

Сам нашел.
Attempting to get a non-existent key
Java's HashMap will return null.
.NET's Dictionary will throw a KeyNotFoundException
Ну а для массивов все индекс возвращают. Отрицательное число - значит не нашел.

(30) А ведь и действительно. Это значением в соответствие проблема Неопределено засунуть. Потому что не сможешь понять - это такое значение вернуло или ничего не нашло. На использование Неопределено в качестве это никак не влияет. В джава именно так и есть. Там можно null и в качестве ключа использовать и null возвращается, если ничего не нашло.
Так что вопрос, почему Неопределено нельзя использовать в качестве ключа соответствия остается открытым.

"На использование Неопределено в качестве ключа это никак не влияет"

(21) как пример такого же средства для корпоративных приложений

(35) а как ты поймешь у тебя там ключа нет, или Неопределено ?

(28) с чего такой вывод?

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

(39) +1
На самом деле невозможность использовать Неопределено в качестве ключа - это баг. В документации такого запрета нет, исключения при вставке тоже нет <!>, теоретических препятствий тоже нет.

(38) там приходится гораздо больше задрачиваться на эксепшены и проверки на null

(41) Причём Exception бывает разного типа...

(42) вот именно

(41) Поэтому в го по своему прикольный подход. На обработку эксепшнов часто забивают на старте и потом это выходит боком. А го форсит сразу прописывать обработку ошибок.

(39) Логично. Торможу.

(41) да конечно. Уж поменьше чем в 1с

(24) там нет слона

(46) ты шутишь?

(48) я серьезно вполне

Соответствие (Map)
Вставить (Insert)
Синтаксис:
Вставить(<Ключ>, <Значение>)
Параметры:
<Ключ> (обязательный)

скорее всего Неопределено эту проверку не проходит

(50) а null проходит

(50) Тогда исключение должно быть, а его нет

(47) Да. Уже потом понял.

(49) ну-ну. Берём типичный приём, паттерн фабрика (Factory). Это что-то вроде составного типа в ихнем тру-программировании

пример

public class CarFactory {
    public static Car buildCar(CarType model) {
        Car car = null;
        switch (model) {
        case SMALL:
            car = new SmallCar();
            break;
        case SEDAN:
            car = new SedanCar();
            break;
        case LUXURY:
            car = new LuxuryCar();
            break;
        default:
            throw new IllegalArgumentException("Incorrect car type");
        }
        return car;
    }
}

наверняка ты уже догадался, что где-то выше по стеку фабрику должен караулить try-catch? Скорее всего этот try будет отлавливать несколько эксепшенов. Вот так даётся "составной" тип данных в тру-программировании. Если не выбрасывать эксепшн из фабрики, то где-то дальше по коду легко можно схлопотать труднодиагностируемый NullPointerException. В 1с такие заморочки нафиг не нужны

(54) В 1С в случае некорректного входного параметра я тоже буду выбрасывать эксепшн. А ты что предлагаешь делать?

(55) зачем тебе эксепшн?

В 1с:
Неопределено как незаполненное значение составного типа
null как неудачно полученное из БД значение
ПустаяСсылка как пустое значение конктеного типа
и всё это прекрасно хаватеся методом ЗначениеЗаполнено()

В этих ихних джавах:
null как незаполненное значение составного типа
null как неудачно полученное из БД значение
null как пустое значение конктеного типа
но различать-то их между собой ой как хочется

(54) сценариев много, аналог этого в 1с у тебя есть?
Да и паттерн фабрика тут так себе. Оно не так реализуется

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

(40) см. (58). Нуллы и неопределенности нельзя сравнивать между собой.

(59) А зачем их сравнивать?
(Неопределено = Неопределено) = Истина?

(59) так себе объяснил...
В запросах неопределено сравнивать можно
В соответствиях null вполне себе ключ

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

(56) Ну то есть ты по сути предлагаешь заменить эксепшн возвратом признака и описания ошибки. То есть обрабатывать ошибку передачи некорректного параметра во всех местах вызова метода. Это глупо. Если ты пропустил в метод некорректный параметр, то тебе нужно тупо падать. Ибо это баг программы.

(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. При вызове функций не следует пропускать обязательные параметры. В противном случае, в параметр будет передано значение Неопределено, на которое функция может быть не рассчитана. Если же значение Неопределено является допустимым, то нужно или его передавать в функцию явно, или сделать этот параметр необязательным со значением по умолчанию Неопределено."