Часто встречаю в типовых такой код:
Перем а;
ЗаполнитьЗначение(а);
Б=а[0];

Я же привык к такому коду:

а=ЗаполнитьЗначение();
Б=а[0];

Т.е. в типовых часто в процедуру передают переменную с которой идет работа внутри этой процедуры. По окончании работы процедуры используется изменная переменная.
Я же привык (по моему так и учили) что нужно стремиться чтобы функции и процедуры были автономны и для возврата параметра лучше использовать функции.
Так как правильно?

голосовалка где?

апофиг

(0) Представь что надо несколько параметров обсчитать и изменить в процедуре/функци, все станет понятно.

Как бэ читабельность и понятность первого примера в разы выше, чем второго, хотя правильнее не менять переменную, а возвращать... но обычно это муторнее и неоправдано

(0) А если "а" ВНЕЗАПНО окажется не коллекцией, или коллекцией, но пустой?

(3) А почему нельзя вернуть структуру?

(6) соответствие круче

А потом потребовалось еще в этой же функции обрабатывать еще 1 переменную. И опаньки. А так - еще один параметр

(4) В чего это она выше? Во втором варианте понятно что с переменной что-то произошло. А в первом нет.

Структура рулит.
Её можно и передать, и вернуть.

(6) Ну напиши код когда 3 параметра в функции увеличиваются на +1 и возвращаются как структура, и сравни с кодом когда это происходит через параметры процедуры. Раз в 6 строк больше будет.

(9) функция не может называться Заполнить... тогда уж ПолучитьЗаполненноеЗначение, а так когнитивный диссонанс вызывает такая запись... и вообще в методе написано про значение, а в переменной оказалась коллекция O_o

Я почему спросил. Часто при отладки сталкиваюсь с первым примером. Мне не понятно в таком случае изменила ли процедура переменную/ые или нет. Нужно обязательно посмотреть как работает процедура. С функцией все понятно.

(11) Согласен, что кода будет больше. Но по моему читабильность такого кода выше.

(14) Ну тут спорно. Кто как привык. Да и сам понимаешь, часто а читабельность забивают.

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

точнее, должно быть так:

Перем а;
а = новый НужныйОбъект;
ЗаполнитьЗначение(а);
Б=а[0];

имхо, сложившееся за 18 лет программирования:
1. если функция проста и однозначна (типа математических синусов и проч.) - она должна возвращать результат своей работы - значение, полученное в результате вычислений
2. если функция сложнее простой арифметики - она должна возвращать код результата (ошибка или всё ок), в вот результат своей работы - структуру, значение и проч. - уже через параметры.
код, написанный с таким подходом, надёжен и понятен.
не знаю, как проголосовать сразу за всех (против всех [за себя])? :)))

Привык делать, как в №2, но потом пару раз наткнулся, что нужно возвратить Истину или Ложь, в случае успеха/неуспеха заполнения.
Перем а;
Если ЗаполнитьЗначение(а) тогда
Б=а[0];
КонецЕсли;

Переучиваюсь на №1

(18)Бывают еще такие варианты.
Перем а;
а = ЗаполнитьЗначение();
Если а <> Неопределено Тогда
Б=а[0];
КонецЕсли;

(17) лучше для обработки ошибки юзать ВызватьИсключение и ловить их в Попытке, а то обработка статусов и самописная работа с ошибками усложняет правильную логику сильно

(19)о! еще одна голосовалочка!

Функция должна возвращать результат своей работы на то она и Функция.
Согласен с (17) если нужно тебе передать ошибку из функции наверх генерируй исключение.

Если функция должна возвратить несколько значений они должны быть упакованы в структуру или иной подходящий объект.

Если вам нужно изменить переданные параметры то используйте процедуру и называйте её понятно

(20) попытку лучше использовать только для неуправляемых ресурсов (файлы и проч.)

(23) попытка это штатный механизм обработки исключительных ситуаций, зачем придумывать что то свое?

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

второй вариант немного оптимальнее, особенно если функция вызывается часто

(25) с чего бы он дорогой? и работа со статусами не займет больше времени при разработке и при выполнении?

(24) потому что тем самым можно заглушить другие ошибки, кои не надо глушить

Просто использовать функции только для того чтобы они возвращали коды ошибок как то некрасиво, они для других целей были придуманы. Вот представь себе конфигурацию в которой все функции возвращают коды ошибок и меняют переданные параметры.

Или вот 1С почитали нашу ветку и думают а что (16) (17) (18) правы давайте будем меять значения переданные в функцию и переделают ТекущаяДата(), Формат(), СокрЛ().

(28) при прямых руках ничего не глушиться и падает в то исключение, которое под эти ошибки выделено

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

Ещё раз, хотите менять значения параметров используйте Процедуры. Хотите получать функцию от переданых значений используйте функцию. Если внутри Процедуры не получается обработать ошибку бросайте исключение вам должно быть всё равно кто и для чего вас вызвал, вы свою задачу выполнили и сообщили миру что "нешмогла" а дальше это проблемы мира обрабатывать ваше исключение или порушиться

+(30) и вообще как они могут быть заглушены? если есть ошибка, она падает в исключение, где нужно ее обработать

(27) может в 1С это дешевле, но обычно там много всего помещается в стек и алгоритм работы несколько другой нежели обычный возврат значения из функции

так что исключение нужно применять только в соответствующих случаях

(31) как раз в книгах не по 1С видел рекомендации не писать свою обработку ошибок, основанную на возвращении статусов, а юзать try/catch

(33) она может попасть на тот уровень на котором именно это исключение не может быть обработано

а так как в 1С фильтрации по типу исключения нет, то соответственно придется писать достаточно запутанный код

(35) конкретный пример книги приведи пожалуйста? и про какой язык?

(34) при использовании исключений у нас 2 ветки для работы - основная, когда все ОК, на которой мы концентрируемся, и возникшие ошибки, которые падают в исключения и которые мы обрабатываем отдельно... выглядит это так:

пример без исключений:

Статус = СделатьЧтоТоАдин( Параметры,,, ТекстОшибки );

Если Не Статус = СтатусОК() Тогда
   СообщитьОбОшибке(ТекстОшибки);
   Возврат;
КонецЕсли;

Статус = СделатьЧтоТоДва( Параметры,,, ТекстОшибки );

Если Не Статус = СтатусОК() Тогда
   СообщитьОбОшибке(ТекстОшибки);
   Возврат;
КонецЕсли;

Статус = СделатьЧтоТоТри( Параметры,,, ТекстОшибки );

Если Не Статус = СтатусОК() Тогда
   СообщитьОбОшибке(ТекстОшибки);
   Возврат;
КонецЕсли;

Пример с исключением:

Попытка

СделатьЧтоТоАдин(Параметры);
СделатьЧтоТоДва(Параметры);
СделатьЧтоТоТри(Параметры);

Исключение

СообщитьОбОшибке( ИнформацияОбОшибке() );

КонецПопытки;

обсуждалось тут

v8: v8: Почему не рекомендуют пользоваться Попытка?

(38) ерунда, например (чисто для примера конструкции):


МассивОшибок=Новый Массив;

СделатьЧтоТоАдин(Параметры,МассивОшибок);
СделатьЧтоТоДва(Параметры,МассивОшибок);
СделатьЧтоТоТри(Параметры,МассивОшибок);

ВывестиОшибки(МассивОшибок);

(37) книгу не помню, вроде есть у Макконнелла в Совершенном коде для сей и джавы и в Чистом коде у Роберта Мартина. Не исключаю, что есть у Джоэла Спольски, у Фаулера и у Бека. Конкретно искать сильно впадлу

(40) а как же не делать второй метод, если ошибка в первом?

(38) а ты представь развитие второго варианта?
в 1С нет конструкции, которая описывала бы возможный вариант исключения, соответственно чтобы определить что функция может завершиться с исключительной ситуацией нужно исследовать текст этой функции, иначе ты будешь постоянно натыкаться на проблемы во время выполнения кода вызывающего данные функции

+ если функция часто вызывается и ошибочная ситуация возникает часто, то это очень дорого будет по времени

(42) проверить на пустоту ошибок

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

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

был случай

Попытка
 //тут поставили чтоб избежать ошибки, что параметр не структура
 Метод();
Исключение
 ...
КонецПопытки;

в Метод() позже добавили некорректный код, а ошибку (должен был валится синтаксис!) не обнаружили, все это в проведении документа, вот так вот

еще раз v8: v8: Почему не рекомендуют пользоваться Попытка?

(44) и код будет выглядеть как в (38) первый вариант... или ты предлагаешь узнавать о наличии ошибок внутри процедуры, которая как бэ вообще не должна знать о существовании соседей?

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

>>+ если функция часто вызывается и ошибочная ситуация возникает часто, то это очень дорого будет по времени

если исключительная ситуация часта, то ее есть смысл обрабатывать как то иначе, потому что это уже не исключительная ситуация. Да и не дорого это, работа с БД в разы дороже

(49) она и не будет знать, она будет знать о наличии ошибок или их отсутствии только

а я специально так делаю ))

(50) а откуда она знает, что эти ошибки не дадут ей правильно отработать?
(48) тыкни в конкретные посты, чтоле, там конструктива еще меньше, чем тут
(46) там про общую структуру работы с ошибками

(52) ткнул на конкретный пост и ссылки от него идут
(52) я так понял он хотел чтоб при наличии ошибок (неважно каких) она не стала бы отрабатывать

Роберт Мартин, Чистый Код. Глава 7. Обработка ошибок: http://screencast.com/t/ywGXkEmkzQ7

Макконнелла пересматривать не буду

Пофиг. Лишь бы выдерживался принцип - "безобразно, но однообразно".

как-то так ... еще один довод против использования исключений
http://imglink.ru/show-image.php?id=a8704306baca92382fa1b9a078211028

передача неправильного параметра, кстати, в 1С и должна вызывать исключение, но это уже касается разработки неких общих библиотек, что для 1С нехарактерно

(40) Вот круто если у тебя

СделатьЧтоТоАдин выполняется 15 минут, СделатьЧтоТоДва выполняется 10 минут, СделатьЧтоТоТри 15 минут и ошибка у тебя в первой строке "СделатьЧтоТоАдин" пользователь прождет 40 минут и увидит ошибку типа "Ошибка при чтении файла".

(53) на 25ый пост указывает? так там не написано почему плохо использовать для обработки исключительных ситуаций,

в примере (38) во втором случае каждая функция внутри не проверяет контекст на возможность работы изза предыдущих ошибок, а просто делает только то, что должна, вызывая исключение, если не справляется.

тупая ветка

а транзакции попытка так вообще песня

(56) и? вызов исключения занимает 0,4/10000 секунды, хочется экономить такие значения, надо писать на чем то более низкоуровневом, а для 1Ски это мгновенно

(60) если произошла ошибка внутри транзакции, то ее надо б откатить, я ж не говорю, что попытку надо юзать для реализации основной логики

+(59)

против исключений есть только один убедительный довод:

отлаживать заип...ся

попробуйте напременять исключения и потом в этом коде найти ошибку с помощью режима отладчика "останавливаться при ошибке"

(62)
> я ж не говорю, что попытку надо юзать для реализации основной логики
о, уже ближе)

(64) кто мешает на период отладки отключить обработку исключений

(64) нормально все, и с помощью остановки по ошибке очень хорошо ловятся исключительные ситуации в коде, а если ошибка в другом месте, то нормальный код очень редко генерит исключения

Я сталкиваясь с кодом некоторых 1С Программистов прихожу в ярость, это не код это зачастую поток сознания в виде спагети, процедуры читают и меняют глобальные переменные используют их для передачи параметров в другие процедуры, зависят от вызывающего контекста, если потребуется хоть одну процедуру перенести из проекта в другой проект приходится половину переписывать отвязывать от реквизитов формы и обработки через которые организован обмен это пи...ц просто.

С обработкой ошибок это тоже тот ещё цирк  если я хочу использовать процедуру я блин должен для неё лично написать обработку её ошибок потому как исключение она не генрит в итоге.

Я думал это только мне не повезло с наследством, как вижу это общий тренд... Печально.

посмотрел посты про исключения и понял, что 1сник ленивый и жадный )

(64) Если у тебя при отладке сыпятся сплошные исключения да ещё и в циклах то есть повод задуматься. Исключения должны быть редки если их дохрена есть повод задуматься.

(66)(67) попытка всегда генерит исключения, если что

(70) так о чем и речь...
исключения это плохой стиль программирования

(71) Попытка никогда не генерирует, генерирует ВызватьИсключение или сама платформа

(72) тебе не хватает фантазии

при отсутствие всяких этических ограничений, возникают программные конструкции типа такой:

Попытка
  ЗначениеРеквизита = Форма.ИмяРеквизита:
Исключение
  ЗначениеРеквизита = Неопределено;
КонецПопытки;


такой код генерит охрененное количество исключений, отладка превращается в муку

(73) дык это говн0код, кто ж говорит, что так можно писать?

(74) а кто сказал, что нельзя? ))))

(74) тогда и в (38) второй вариант говн0код в общем случае

(76) второй вариант, по определение говн0код,
за такую писанину надо яйца отрывать

+(77) тем более вариант 1 не равен варианту 2

(74)  Бросай это дело, бисер нынче дорог чтобы так бездумно его тратить.

(76) Почему? в (73) мы стучимся в неизвестный реквизит и вместо того, чтобы что то сделать, чтоб он был всегда или сообщить наверх, что данные некорректны. Исключение составляет универсальный метод, в который падает произвольная форма. в (38) нормальная обработка ошибок, а не спагетти или велосипеды как в (40)

(80) потому что так пишут быдлопрограммисты

(81) как так? Правильно? с использованием механизмов платформы? или любой стиль программирования, отличный от твоего, это быдлокод?

(78) и в чем различие?

+(81) одно и требовании к современному программированию это возможность повторяемости, т.е. повторному использованию кода...

твой код если скопировать, то он работать не будет ибо еще нужно переменные не забыть, а код Ненавижу 1С не зависит от контекста выполнения...

не знать этого - позор для программиста, т.к. этому в школе еще учат

(84) какие переменные то?

(85) если бы  функция ИнформацияОбОшибке() не была бы встроенной  в платформу то тебе пришлось бы организовывать стек для хранения сообщений...
в данном же случае, текст ошибки тебе дает как минимум в два раза меньше пользы, т.к. программисту усложняется возможность поиска места ошибки
+ полностью прогнать код и выявить все ошибки тоже будет невозможно

(84) в отличие от кода Ненавижу 1С даже переменные дополнительные для учета ошибок не надо создавать, а методы прекрасно вызываются и из других мест, и копипастяться проще, чем методы, которые возвращают статусы, которые еще в точке вызова нужно особенно обрабатывать.

меня почему то в школе не учили защитному программированию, но я научился сам

(87) " и копипастяться проще" стиль программирования ясен

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

(88) я про перенос в другую конфу и в ответ на "твой код если скопировать, то он работать не будет", так что не передергивай

(89) а теперь попробуй протрассировать свой код и найти бажное место...

>>>программист сразу же найдет ошибку, выставив флаг остановки по ошибке.

не найдет... отладчик перейдет на исключение

1С внятно try catch обработать не в силах - на все про все - одна беда, п.э. избыточное использование поппыток - не камильфо...

(92) дык исключение там, где ошибка!
(91) легко все трассирую и отлаживаю

(94) исключение... в конструкции исключение..

ты там вообще чем руководишь?
бумажки что ли только пишешь и совещания проводишь?

(95) отладчик остановится на строчке ВызватьИсключение, а не в конструкции исключения. Ты вообще знаешь, как работает Попытка исключение?

(96) послушай, из твоих фраз следует примерно следующее:

попытка/исключение очень удачный вариант, но в большинстве случаев его не следует использовать

это если все твои предложения/оговорки прочитать

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

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

что в итоге получим?

Процедура РазДваТри()
   
   а = 1;
   б = 0;
   Попытка
       с = а/б;
   Исключение
       Сообщить("Ошибка");
   КонецПопытки
   
КонецПроцедуры

Процедура Привет()
   Сообщить("Пока");
КонецПроцедуры

Процедура КнопкаВыполнитьНажатие(Кнопка)
   
   
   Попытка
       
       РазДваТри();
       Привет()
       
   Исключение
       
       Сообщить("Ошибка");
       
   КонецПопытки
   
   
КонецПроцедуры



ЗЫ. ну вообще 1С стала значительно лучше работать с попытками

(99) Переносишь или вызываешь из своей процедуры?

(97) моя позиция, если внутри метода нужно обработать исключительную ситуацию и вернуть эту инфу выше (обработка ошибки по простому если), то надо использовать ВызватьИсключение с отловом в попытке, а не возвращать статус с доп. инфой и его самостоятельно обрабатывать.

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

Отдельно можно рассматривать конструкции типа
//проверка имени реквизита на корректность
Попытка
структ.Вставить( имяРеквизита );
Исключение
Сообщить("Не корретно");
КонецПопытки

(98) а зачем? если у нас есть первая ошибка, то далеко не факт, что вторая самостоятельна, а не следствие первой

(87) не защитное программирование
а писать безопасный код

(103), Похоже (98) не знает о существовании ВызватьИсключение(). Не думаю что стоит ему рассказывать об этом за бесплатно :))

(103) если ты используешь не свои процедуры, то какие у тебя гарантии того, что туда не вставят свои попытки? и при этом не забудут передать информацию об ошибке выше?

(99) там много различных ситуаций и сильно зависит от контекста, единого решения есессно нет. Я пытаюсь замкнутые методы писать в безопасной области, то есть попытками проверяются входные параметры в экспортных методах, а все то, что внутри (что вызывает метод) считаем безошибочным

(106) это проблемы того кто будет вызывать твою функцию, какие у тебя гарантии что этот человек проверит состояние возвращаемое твоей функцией?

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

(106) а мне пофик чо там внутри, пусть она ругнется исключением, если я что то не то на вход дал и сделает как надо, если дал то

(110) в твоей попытке код дальше выполняться будет

(111) а что в этом плохого? значит вызванная функция отработала корретно

(104) не придирайся, у Макконнелла это называется защитным программированием, а безопасный код в моем понимании, это тот, который не порушит данные, а не корректно обработает ошибки

(112) как узнать, что на нижних уровнях произошла исключительная ситуация? это информация бывает необходима

изощренный пример:



   Попытка
       ПолучитьФорму("Форма1").ОткрытьМодально(); //в орме1 юзер нжал кнопку с обработчиком Б=1/0;    
   Исключение
       Сообщить(1); //исключение вызвано не было!
   КонецПопытки;

(115) но надо признать, обработка исключительных ситуации у 1С стала значительно лучше...
еще бы стэк и было бы счастье

(114) если метод может сам с этим разобраться, то это его проблемы. Отладчиком так же легко ловится при установленной галке.

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

+(117) то есть так нужно писать код, чтоб шел такой каскад

(117) под каскадом ошибок, ты имеешь ввиду потерю данных?

весело

(118) как бы, большинство 1Сов работают преимущественно не только со своим кодом, ты в курсе?

(106) ты даже пример неправильно написал в процедуре РазДваТри() ты кому сообщаешь об ошибке? Пользователю? Твою процедуру пользователь вызвал? Вот это Сообщить в общих процедурах тоже злит, и меня и пользователей, у тебя в процедуре произошла ошибка ты должен о ней известить НЕ ПОЛЬЗОВАТЕЛЯ! а контекст который тебя вызвал, что будет дальше делать контекст с твоей ошибкой это его дело. То что ты пользователю сообщил ничего не решило.

Дикообразко по тебе видно что ты не когда не работал в большой команде, у тебя весь мир крутится вокруг тебя и все думают как ты. В реальной команде не так, есть правила закрепленные на уровне платформы и грамотный разработчик должен следовать им а не придуманым тобой правилам.

А правила такие, получил ошибку которую не можешь обработать вызови исключение.

Если пишешь обработку исключений то не забывай отправить на верх исключение по цепочке

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

(120) 1С в типовых довольно часто используют ВызватьИсключение().

Зато в самописках гении в каждой попытке пытаются сообщить пользователю "Ура у меня ошибка вот какая я херовая процедура" в то же время вызывающий программист должен использовать эту функцию как процедуру в ответ получая код ошибки.

(120) как бэ в типовых примерно так и написано

(121) ты серьезно экспериментальный код вставляешь в рабочие версии ?
мне жаль твоих коллег
мучаются они наверно с тобой
страшно подумать как они тебя за глаза называют,
а насчет большой команды да, я в команде больше чем из 10 программистов не работал

Что значит эксперементальный :) ???
Это если я в попытке "Сообщить" не написал?

К чему огород городить?

(126) экспериментальный это значит экспериментальный,
когда исследуются методы платформы
ты наверно свой код по 33 раза переписываешь, правишь туда-сюда?

и да в (38) тоже я СообщитьОбОшибке написал

(127) потому что люди которые получили хоть какое то образование в области программирования знают как нужно пользоваться процедурами и как функциями и у них не возникает желание отсупать от общепринятых концепций.

В то время как люди которые за 3 месяца изучили 1Ц и написали рабочий код мнят себя пупами земли и для них нет Стандартов и правил они БОГИ и они могут выбирать как им удобнее делать так и делают.

(128) т.е. для тебя ВызватьИсключение это экспериментальная неизвестная фича платформы которую надо исследовать?

(122) как бы C# и делфи закрыли форму и вызвали код в catch

(130) кхм... я занимаюсь 1С далеко не 3 месяца

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

просто ребята торчат от "попытка" и от того, что отладчик срабатывает, не мешайте )))

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

как работать с исключениям: http://its.1c.ru/db/v8std#content:2149184148:1  это из стандарта 1С, на итс есть копия

(133) тогда попробуй вспомнить как работала попытка на 77,
ну если не сможешь, тогда вспомни как она работала на 8,0 или хотя бы на первых релизах 8.1

(129) кстати, я не внимательно посмотрел что в примерах указано :(
сейчас еще раз глянул, действительно
ЗаполнитьЗначение(а); - это более правильный путь чем а=ЗаполнитьЗначение();
так что я был не прав с ответом. поторопился.

(135) закрылась, закрылась и это вполне себе корректно
ее закрыло внутренне "вшитое" в нее исключение и передало его дальше

(137) Функция ЗаполнитьЗначение(а) это неправильно, правильно Процедура ЗаполнитьЗначение(а)

(139) Майкрософт об этом знает?

(139) ну почему же так категорично?
К примеру, функция может возвращать ложь|истина как указатель на то, что все прошло успешно или нет.

Я иногда организую стек ошибок для модуля, а через функции передаю все ли ОК или нет при заполнении чего-то (например при необходимости получить данные из внешних источников).

(141) см. (102) и остальной холивар

(139) где это написано?

(141)
>>>К примеру, функция может возвращать ложь|истина как указатель на то, что все прошло успешно или нет.

он как раз и доказывает, что религиозно верно проверить наличие исключения, т.к.
теперь 1С сделала нормальную обработку ошибок

т.е. вместо

errorLevel = ЗаполнитьЗначение(а);
Если errorLevel <> 0 Тогда
 // обработать ошибку
КонецЕсли;

нужно писать

Попытка
   ЗаполнитьЗначение(а);
Исключение
  // обработать ошибку
КонецЕсли;

по мне те же яйца, только в профиль
но лучше бы 1С дало бы доступ к стеку ошибок...
или он есть?

(142) ну да, не почитал.
Вообще все зависит от ситуации. Универсального единственно правильного решения не существует. Вот и вся правда.

(143) в любой книге по качеству написания кода, где то в разделах про именование функций и процедур

(144) яйца может и те же, но 1) достигается единообразие в обработке исключений 2) с потоками данных нужно меньше заморачиваться 3) обработка ошибок стандартными инструментами описана в статьях/книгах, в отличие от своего кода

(147) суть та же, техническая реализация разная...
еще тупо не все на 82 перешли, что бы с этим заморачиваться

(144) твой пример слишком простой и надуманный. (про как надо)
Более того, при таком подходе будут одни сплошные поытки и исключения.

Это как минимум не удобно.

Вот к примеру часть кода

СостояниеОшибки = ложь;

   СтруктураДанныхДляВыгрузкиПоНоменклатуре = ПолучитьСтруктуруДанныхДляВыгрузкиПоНоменклатуре(СостояниеОшибки);
   
   // активируем свойства товара "качество"
   СостояниеОшибки = не (не СостояниеОшибки и АктивироватьСвойства(ПолучитьКодСвойстваКачество(),СтруктураДанныхДляВыгрузкиПоНоменклатуре["ТаблицаКачествНоменклатуры"]));
   
   // выгружает список штрих-кодов, каждый штрих-код привязывается к номенклатуре, но без
   // привязки к конкретному размеру и качеству
   СостояниеОшибки = не (не СостояниеОшибки и ВыгрузитьСписокШтрихКодов(СтруктураДанныхДляВыгрузкиПоНоменклатуре["ТаблицаШтрихКодовНоменклатуры"]));

   // связываем штрих-код с размером
   СостояниеОшибки = не (не СостояниеОшибки и СвязатьНоменклатуруШтрихКодРазмер(СтруктураДанныхДляВыгрузкиПоНоменклатуре["ТаблицаШтрихКодовНоменклатуры"]));
   
   // связываем штрих-код и качество
   СостояниеОшибки = не (не СостояниеОшибки и СвязатьНоменклатуруШтрихКодКачество(СтруктураДанныхДляВыгрузкиПоНоменклатуре["ТаблицаШтрихКодовНоменклатуры"]));
   
   возврат Не СостояниеОшибки;

Это не большой кусок функции.

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

(148) в (38) разве не заметно упрощение?

(147) встреча в апишных функциях возврат наличие ошибки (errorLevel ) а в переменных данные (а):
errorLevel = ЗаполнитьЗначение(а);

(150) а если ошибок несколько?
сразу так с наскоку сложно оценить последствия такого решения

(149)
>>Более того, не понятно как работать с иерархией ошибок, когда исключение было вызвано на 3й вложенности функций

+1

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

(154)
1.
и что тут красивого?

Попытка

СделатьЧтоТоАдин(Параметры);

Исключение

СообщитьОбОшибке( ИнформацияОбОшибке() );

КонецПопытки;

Попытка

СделатьЧтоТоДва(Параметры);


Исключение

СообщитьОбОшибке( ИнформацияОбОшибке() );

КонецПопытки;


Попытка

СделатьЧтоТоТри(Параметры);

Исключение

СообщитьОбОшибке( ИнформацияОбОшибке() );

КонецПопытки;


?

(154) а зачем его генерировать?

мне нравится второй вариант, т.к. он более явный. если нужно вернуть несколько значений, можно вернуть структуру.

(155) если код начинает выглядеть так, то или попытки нужно спускать ниже в функции, или разделить метод на независимые... при использовании статуса код всегда будет выглядеть так, а не только в извращенных случаях

(158) хреновый путь. Организация стека ошибок, с его обработкой на нужном уровне гораздо элегантнее и проще.
Функция возвращает все ОК или нет. А тому кому нужно обрабатывает ошибку или передает ее обработку выше.

(158) имхо, нормально выглядит

Если Не СделатьЧтоТоАдин(Параметры) Тогда
  Возврат;
КонецЕсли;

Если Не СделатьЧтоТоДва(Параметры) Тогда
  Возврат;
КонецЕсли

Если Не СделатьЧтоТоТри(Параметры) Тогда
  Возврат;
КонецЕсли

(160) а где обработка ошибки то?

+(160)а можно, так



Отказ = Отказ И СделатьЧтоТоАдин(Параметры, СтруктураОшибок);
Отказ = Отказ И СделатьЧтоТоАдДва(Параметры, СтруктураОшибок);
Отказ = Отказ И СделатьЧтоТоТри(Параметры, СтруктураОшибок);

Если Отказ Тогда
  ОбработатьОшибки(СтруктураОшибок);
КонецЕсли;

+(160)

(161) например в (162)

если 1С сделает еще и стэк ошибок, то претензии к ним снимутся ;)

(161) если нет такой ситуации как в (23) то смысл обрабатывать

(160) + 1, я тоже так делаю.
Обработка исключений нужна для тех случаев, когда невозможно предотвратить ошибку программными средствами. например, какое-нибудь УстановитьСоединение()

(164) они рекомендуют не хранить ошибки, а в журнал регистрации писать сразу

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

(168) это к чему?

(166) и то можно посмотреть что вернуло соединение, оно внутри сама все обрабатывает

А можно (160) модернизировать

Ошибка = СделатьЧтоТоАдин(Параметры);

Если ЗначениеЗаполнено(Ошибка) Тогда
  Возврат Ошибка;
КонецЕсли;

Ошибка = СделатьЧтоТоДва(Параметры);

Если ЗначениеЗаполнено(Ошибка) Тогда
  Возврат Ошибка ;
КонецЕсли;

Ошибка = СделатьЧтоТоТри(Параметры);

Если ЗначениеЗаполнено(Ошибка) Тогда
  Возврат Ошибка ;
КонецЕсли;

(169) это пофиг что они там рекомендуют, как хочу так и обрабатываю ошибки.

в принципе (171) мало чем отличается от этого:


Попытка
  СделатьЧтоТоАдин(Параметры);
Исключение
  Возврат(ИнформацияОбОшибке());
КонецПопытки;

Попытка
   СделатьЧтоТоДва(Параметры);
Исключение
   Возврат(ИнформацияОбОшибке());
КонецПопытки;

Попытка
  СделатьЧтоТоТри(Параметры);
Исключение
   Возврат(ИнформацияОбОшибке());
КонецПопытки;

(173)
вот только не понятно как обрабатывать такой "Возврат(ИнформацияОбОшибке());"

Я вообще за второй вариант, но 1-й заслуживает "жизни" в единственном случае - если никогда не изменяет тип параметра и ничего не возвращает.

(162)
Попытка
  СделатьЧтоТоАдин(Параметры);
Исключение
  Возврат(ИнформацияОбОшибке());
КонецПопытки;

Попытка
   СделатьЧтоТоДва(Параметры);
Исключение
   Возврат(ИнформацияОбОшибке());
КонецПопытки;

Попытка
  СделатьЧтоТоТри(Параметры);
Исключение
   Возврат(ИнформацияОбОшибке());
КонецПопытки;


Можно написать так:
Попытка
  СделатьЧтоТоАдин(Параметры);
  СделатьЧтоТоДва(Параметры);
  СделатьЧтоТоТри(Параметры);

Исключение
   Возврат(ИнформацияОбОшибке());
КонецПопытки;

В этом случае если у тебя исключение произойдет в Адин у тебя не будут в пустую выполнятся функции Два,Три.

Подразумевается что в (176) код который не будет взываться другими процедурами.

А трюкачить с подобными методами вообще непонятно зачем.

(176) больше одной ошибки информации не получишь... незачет
см (152)

(173) скорее наверное от стиля зависит, сам пользуюсь редко. когда сильно спишу, когда лень или когда ситуация без контрольная

(176) а что если в СделатьЧтоТоАдин тоже есть попытка/исключение которые там обрабатываются?

(181) в исключение СделатьЧтоТоАдин
передавать исключение выше используя метод ВызыватьИсключение

такие веяния от 1С, прикинь

(181)
Процедура РазДваТри()
   
   а = 1;
   б = 0;
   Try
       с = а/б;
   Except
       Raise;
   EndTry
   
КонецПроцедуры

Процедура КнопкаВыполнитьНажатие(Кнопка)
   
   
   Try
       РазДваТри();
       Инфо = ИнформацияОбОшибке();
   Except
       Инфо = ИнформацияОбОшибке();
       Сообщить(НСтр("ru=""Описание="";en=""Description=""") + Инфо.Описание + """");
       Сообщить(НСтр("ru=""ИмяМодуля="";en=""ModuleName=""") + Инфо.ИмяМодуля + """");
       Сообщить(НСтр("ru=""НомерСтроки="";en=""LineNumber=""") + Инфо.НомерСтроки);
       Сообщить(НСтр("ru=""ИсходнаяСтрока="";en=""SourceLine=""") + Инфо.ИсходнаяСтрока + "'");
   EndTry
   
КонецПроцедуры

Ну вы блин даете. Я думал ветка давно уже утонула.

*(183) на русском

Процедура РазДваТри()
   
   а = 1;
   б = 0;
   Попытка
       с = а/б;
   Исключение
       ВызватьИсключение;
   КонецПопытки
   
КонецПроцедуры

Процедура КнопкаВыполнитьНажатие(Кнопка)
   
   Попытка
       РазДваТри();
   Исключение
       Инфо = ИнформацияОбОшибке();
       Сообщить(НСтр("ru=""Описание="";en=""Description=""") + Инфо.Описание + """");
       Сообщить(НСтр("ru=""ИмяМодуля="";en=""ModuleName=""") + Инфо.ИмяМодуля + """");
       Сообщить(НСтр("ru=""НомерСтроки="";en=""LineNumber=""") + Инфо.НомерСтроки);
       Сообщить(НСтр("ru=""ИсходнаяСтрока="";en=""SourceLine=""") + Инфо.ИсходнаяСтрока + "'");
   КонецПопытки
   
КонецПроцедуры

(182) если честно, вообще не понимаю о чем сыр-бор :)
Как хочу так и организовываю обработку ошибок. В 1С не очень удобный механизм, это факт. Хочу - делаю свою обработку ошибок. Да и вообще (166) + 1
"Обработка исключений нужна для тех случаев, когда невозможно предотвратить ошибку программными средствами. например, какое-нибудь УстановитьСоединение()"

(186) мыши плакали и кололись, но продолжали жрать кактус (цы)
1С все равно заставит ;)

(187) как? ) как хочу так и делаю.

(183) такое уродство тянуть эти попытки/исключения через десяток уровней и не запутаться где же кто вызвал исключение. И вообще - какого хрена? )

(188) они умеют проникать в мозг

(189) вот и я о том же,
если 1С придумает нормальный стэк, тогда может и взлетит,
а так имхо балавство

И эти люди запрещают мне ковырятся в носу. (с) анекдот про вовочку.
Как можно нафлудить 200 постов на эту тему?

(192) просто вторник ))

а да кстати, по (0)

имхо, правильно так

а = Новый Массив(10);
ЗаполнитьЗначение(а);
Б=а[0];

и так:

а=ВернутьЗаполненныйМассив();
Б=а[0];

мне удобно как в (166), (160)

Обычно делаю так:
   
Если НЕ СделатьЧтоТоАдин(Параметры, ОписаниеОшибки) Тогда
   ЗаписатьОшибку("При попытке выполнения Адин произошла ошибка: " + ОписаниеОшибки);
   Сообщить("Невозможно выполнить Адин"); // если надо оно
   Возврат;
КонецЕсли;
   
   
Как вариант, в транзакциях и в попытках .. исключениях:
   
   
Попытка
   КакойтоОбъект.Записать();
   
   Если НЕ СделатьЧтоТоАдин(Параметры, ОписаниеОшибки) Тогда
       ВызватьИсключение ОписаниеОшибки;
   КонецЕсли;
   
   Если НЕ СделатьЧтоТоДва(Параметры, ОписаниеОшибки) Тогда
       ВызватьИсключение ОписаниеОшибки;
   КонецЕсли;
Исключение
   ЗаписатьОшибку("При попытке выполнения чего-то-там-важного произошла ошибка: " + ОписаниеОшибки);
   Сообщить("Невозможно выполнить Адин"); // если надо
   Возврат;
КонецПопытки

по голосовалке - зависит от ситуации

(188) Почитай (129)

(183) Зачем тянуть, ты взывал функцию, она взывала исключение ты уже вероятно не сможешь продолжить работу, если ты пишешь общую функцию то ты тоже вызываешь исключение из за того что произошел сбой в чужой функции. тупо выдаётся ошибка.

Всё что от тебя требуется если пишешь общую Функцию помнить что ты не один и быть вежливым с чужими исключениями, и не забывать про свои.


(195)
Попытка
  СделатьЧтоТоАдин(Параметры);
  СделатьЧтоТоДва(Параметры);
  СделатьЧтоТоТри(Параметры);

Исключение
Инфо = ИнформацияОбОшибке();
Сообщить("Описание='" + Инфо.Описание + "'");
Сообщить("ИмяМодуля='" + Инфо.ИмяМодуля + "'");
Сообщить("НомерСтроки=" + Инфо.НомерСтроки);
Сообщить("ИсходнаяСтрока='" + Инфо.ИсходнаяСтрока + "'");
Возврат(ИнформацияОбОшибке());
КонецПопытки;

(Опять же если это не экспортная процедура, например обработчик кнопки)

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

(197) Мы тут обсуждаем то к чему надо стремится, жизнь и платформа подкидывают задачки которые решить иначе как "неправильно" нельзя например из моего кода:
Попытка
пОбъект.ВнешнийКлюч = Строка(ВнешнийКлюч);
Исключение
КонецПопытки;

Может быть передан произвольный объект нужно заполнить внешний ключ узнать о наличии свойства малой кровью нельзя, так приходится делать и есть множество других ситуаций но важно стремится к правильному коду хотя бы в общих моментах.

(198) в любом случае это лишь техническая реализация...
идеология обработки ошибок абсолютно одинаковая

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