Некоторое время назад обсуждали, так вот, ошибка возникла:
{Документ.НалоговаяНакладная.МодульОбъекта(4351)}: Преобразование значения к типу Булево не может быть выполнено
Если СообщатьОбОшибках Тогда
При таком написании ошибка не возникает:
Если СообщатьОбОшибках = Истина Тогда
Я обычно так и стараюсь делать
А маслаков со здой и циветой начали кричать, что я ничего не понимаю...
Вот я как только наткнулся на такую ошибку - привёл пример как и просили. Конфа типовая.
мне тоже один раз сказали, что это нелепо
Т.е. лучше пиши вариант
КитайскийМуй Если СообщатьОбОшибках = Истина
Чем
Просто
КитайскийМуй Если СообщатьОбОшибках Тогда
Так код безопаснее
Вот, нашёл ту ветку:
Ошибка в коде. Использование не инициализированной переменной скорее всего. Лучше получить явную и понятную ошибку как в (0) чем пустить дальше исполнение заведомо бажного кода и получить косяк где-нибудь дальше. Например, код должен был ругнуться на ошибку. При использовании конструкции
Если СообщатьОбОшибках = Истина Тогда
в нашем случае вывод сообщения об ошибке будет подавлен. Юзер не узнает, что произошла ошибка и будет считать неверный результат расчета правильным.
sda553 Одинэсина не является строго типизированной
Может, ты хотел сказать, что 1с не является языком со статической типизацией?
(10) вот и я о том же
(0) Кстати, озвучь релиз и место, в котором такое получилось. Страна должна знать своих героев.
(12) юзер и не должен получить сообщение об ошибке, это при попытке открыть НН когда в её ТЧ нет ни одной строки.
(16) юзер не должен получить сообщение об ошибке при условии, что разработчик написал годный код, устойчивый к входным данным
в данном случае мы видим, что это не так, поэтому юзер должен получить сообщение и пнуть им в разработчика
ТеньД Что такое НН
Налоговая накладная
Бухгалтерия для Украины по ходу
(17) косяк в том. что документ не открывается
(19) ошибки-то в документе нету, ошибкой является - сообщение об ошибке, оно не должно возникать в данной ситуации.
Муй в своём репертуаре
КитайскийМуй (1) Спор был о написании, я сказал, что опытный 1Сник обязательно напишет:
"Если Фигня = Истина Тогда", а не "Если Фигня Тогда"...
Кроме случаев когда там точно булево:
Пусть isФигня = Фигня == Истина; Если isФигня Тогда
Остается вопрос, почему у тебя в булевой переменной "СообщатьОбОшибках" записано не булево значение. Это уже косяк где-то выше.
webdev почему у тебя в булевой переменной "СообщатьОбОшибках"
в 1с нет понятия "булева переменная"
может быть строго типизированный булев реквизит, но не переменная.
одна и та же переменная может сейчас быть булева, а через секунду строкой. а за миг до этого быть Неопределено
andrewks в 1с нет понятия "булева переменная"
может быть строго типизированный булев реквизит, но не переменная.
одна и та же переменная может сейчас быть булева, а через секунду строкой. а за миг до этого быть Неопределено
Вообще-то есть. Если ты назвал переменную "СообщатьОбОшибках", то это точно должно быть булево, а не строковое значение или какой-то счетчик. Строковая переменная будет иметь такое имя: "СообщениеОбОшибках", а числовая: "КоличествоСообщенийОбОшибках".
webdev Ты наверное не понял о чем я тебе толкую.
да куда уж мне. я ж не программист, а дворник. так, мимо проходил
(35) не набиваюсь
(37) я чувствую разницу. а вот ты не почувствовал разницу.
ибо должен был назвать не КодыСообщенийОбОшибках , а КодыОшибокОКоторыхНадоСообщать
Пытаешься выкрутиться. Ну хорошо что хоть понял свою ошибку.
Что то в последнее время программисты стали частенько спорить о том, с какой стороны разбивать варёное яйцо
(41) скучно
andrewks ничего я не понял
:)))
sda553 Что то в последнее время программисты стали частенько спорить о том, с какой стороны разбивать варёное яйцо
Острым концом нужно бить об острый. А тупым об тупой. Если бить об голову andrewks, то тупым концом.
(47) Релиз напиши. Если забыл как сделать, напоминаю. Меню "Помощь" - "О программе".
"Управление производственным предприятием для Украины", редакция 1.3
Разработка конфигурации: "ABBYY Ukraine", 2005-2017
1.3.50.1
MIK можешь глянуть что там?
КитайскийМуй И Эндрю прав, а ты выглядишь глупо
Ты считаешь что так правильно делать?
andrewks я вполне могу там разместить массив, состоящий из кодов ошибок, о которых надо сообщать
(52) Конечно правильно, почему нет.
jsmith82 о чём спор?
andrewks хочет в переменную "СообщатьОбОшибках" записать массив кодов. Я считаю что это говнокод, и ему нужно по рукам надавать линейкой.
Типа, если переменная названа как Булево, то в ней и нужно хранить Булево, а не числа или массивы всякие.
Хочешь сохранить массив кодов, так и назови свою переменную: "КодыЧеготоТам..."
(56) Это феерично... с чего ты решил что имя переменной определяет её собственный тип этой самой переменной??? Это в какой вселенной?...
КитайскийМуй (56) Это феерично... с чего ты решил что имя переменной определяет её собственный тип этой самой переменной??? Это в какой вселенной?...
Еще один говнокодер. Но с тобой и раньше было все понятно, тут нечему удивляться.
ну йобушкин всемирный насос
вообще, насколько я помню, ошибка преобразования к Булево довольно часто встречается в типовых
sda553 вообще то прнято
кем и где принято?
sda553 isValid
а почему не bIsValid?
sda553 headNum
а почему не iHeadNum?
sda553 headNumArray
а почему не aHeadNum? или не headNums?
правила именования - вещь многообразная, в каждом проекте, и даже в каждом ЯП могут быть свои правила и особенности.
не нужно их экстраполировать на всех и вся
Чёто вы в какую-то иную степь ударились. вопрос в том, следует ли в типовых писать = Истина / Ложь.
Приведения типов в 1с нет. Поэтому ошибки могут спокойно валиться при попытках преобразования значений из результатов запроса типа Null или Неопределено, ну и при неинициализации (Неопределено) и прочих косяках разработчиков.
(66) ну есть пара тройка команд...
в ассемблере тоже есть переменные. их тоже надо как-то именовать. давайте поговорим об этом
я обычно именую переменные с большой буквы, ставлю пробелы вокруг операторов, фигурные скобки переношу на следующую строку
MIK Не могу я глянуть, какой-та древний релиз
Сильно древний релиз? Тогда я вижу ситуацию так: крайне сомнительно, что муй сидел на багованом релизе все это время и терпел. Это какой-то совсем нездоровый мазохизм получается. Скорее всего баг появился усилиями самого муя или его коллег в процессе допилки конфы под заказчика.
Но виноваты разумеется все равно разрабы типовых. За то, что пишут код так, что не удается спрятать под капот косяки конфигурастов-улучшателей.
Там стока ошибок, что божешьмой-божешьмой...
http://downloads.v8.1c.eu/content//EnterpriseUkr/1_3_56_2/ErrEnterpriseUkr_1_3_56_2.htm
УПП - мертвое направление для 1с. Хочешь Светлого Будущего - переходи на ЕРП. Не хочешь переходить? Правь косяки самостоятельно. Как правильно замечено в (71) используй расширения.
(76) эй! английский размовляешь?
sda553 (57) вообще то прнято, чтобы тип переменной определял название переменной. Соответственно по названию был бы очевиден тип.
bool isValid;
int headNum;
int[] headNumArray;
Верно, но только название типа писать в имени переменной - не очень красиво.
Лучше вместо:
int[] headNumArray;
Написать во множественном числе по-человечески:
int[] headNums;
Тогда не понятно будет, сет это эррэй, или может вообще какая нибудь кьюа или стэк. Понятно что коллекция какая то и не боле
sda553 Тогда не понятно будет, сет это эррэй, или может вообще какая нибудь кьюа или стэк. Понятно что коллекция какая то и не боле
Современная IDE подскажет. Уже нет необходимости писать что это. Зато красиво получится.
К тому же иногда бывает, что я определяю, к примеру тип
typedef int* HeadNums;
//Потом объявляю переменную этого типа
HeadNums nu_i_kak_mne_teper_peremennuyu_nazvat;//?
sda553 К тому же иногда бывает, что я определяю, к примеру тип
typedef int* HeadNums;
//Потом объявляю переменную этого типа
HeadNums nu_i_kak_mne_teper_peremennuyu_nazvat;//?
Странное название для типа. Но переменную нужно называть по смыслу, что она обозначает.
я стараюсь избегать всяких префиксов и постфиксов, обозначающих типы
(76) Просто выполнил своё обещание - как только встречу такой случай - сообщу. Вот и сообщил.
sda553 Понятно что коллекция какая то и не боле
так и не надо боле, вполне достаточно
вот наименование типа полюбас лучше обозначить префиксом или суффиксом, чтобы явно было видно, что это именно тип
ну если только по-человечески назвать: ListOf.., а не lst.. или al..
а почему не tNums, или не NumsType?
