Отложить использовать не только для очистки - хорошая или плохая практика?

Question

Откладывание выполнения кода обычно используется в Go для очистки ресурсов. Это не так часто встречается, но бывает, что defer также используется для выполнения обычной бизнес-логики. В качестве последнего шага выполнения, независимо от того, в какой точке функция нажимает ключевое слово return.

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

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

Answer 1

Компилятор Go не знает, какой код является кодом очистки. Так что, если он работает для отсрочки кода очистки, он, очевидно, будет работать и для отсрочки любого кода не очистки.

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

Одна вещь, которую вы должны иметь в виду: отложенные функции запускаются, даже если код паникует (что желательно для очисткикод), который в противном случае не был бы нормальным потоком выполнения. Так что это будет разница при использовании отложенного по сравнению с неиспользованием. Смотрите связанные: `defer` в цикле - что будет лучше?

Answer 2

Давайте уточним, какие накладные расходы в настоящее время добавляют операции отсрочки Go (до Go 1.14).

Начиная с Go 1.13, большинство операций отсрочки занимают около 35 нс (по сравнению с 50 нс в Go 1.12). ). Напротив, прямой вызов занимает около 6 нс. Этот пробел стимулирует инженеров исключить отложенные операции из горячих путей кода, что отнимает время у более продуктивных задач, приводит к снижению объема поддерживаемого кода (например, если позднее возникает паника, «оптимизация» больше не является правильной) и не поощряет людейот использования языковой функции, если в противном случае это было бы подходящим решением проблемы.

Предложение: Недорогие отсрочки через встроенный код и дополнительные функции для управления случаем паники