Comments 14
Ну для начала - это никакая не отмена defer, правильнее было бы назвать это отключением.
Во, вторых предложенный пример уж очень сильно искусственный (создаем странную логику и старательно с ней боремся).
У вас даже switch - не к месту ибо int всегда либо четный, либо нет: достаточно одного if else или if return без else.
Ну да, зануда. А что поделать если говнокод не оптимальные решения режут глаз...
Я тоже, увидев заголовок статьи, ожидал какой-то магический механизм. Какой-нить сахар типа cancel defer, о котором я не знал... А тут получилось первая часть статьи вообще не по теме заголовка, а во второй автор предлагает обычные костыли... для кейса который в реальной жизни и так редко нужен, если руки прямые)
Спасибо за отзыв. Да, согласен, ситуация в вакууме. Идею придумал за вечер. Крутое решением, мб, через RSP регистр спуститься вниз по стэку и убрать вызов defer функции. Буду стараться, первый блин очень большим комом
Кликбейт какой-то.
Причем тут отмена defer, если он совершенно успешно выполнился?
И зачем эти танцы с указателем? Вы же понимаете, что можно убрать Execute из кода, в defer убрать аргументы и просто там проверять
if a%2 == 0 { fmt.Println(a / 2) }
Только для очень условного внешнего управления? Да, можно, но это, как выше заметили очень искусственный пример. В реальной жизнь это буквально говорит о том, что нужно код переписать.
Там собственно и defer не нужен - если есть только одна ветка где нужно делить - там и делить.
Ну и отдельно напишу, раз уж про переписывание упомянул, что тут что-то типа декоратора напрашивается, а не абьюз defer (не используйте defer, пожалуйста, если он вам не нужен),
func dec(f func(int), i int) {
if i%2 == 0 {
f(i)
}
}
или что-то типа того
Я извиняюсь за негатив, вообще не часто (никогда) пишу комментарии, но что это за статья ради статьи? Автор серьёзно использовал 1 if и написал об этом статью? При всем при этом зачем-то используется указатель на локальную переменную И анонимная функция, из которой можно получить прямой доступ к переменной, а не по ссылке. Для кого эта статья? (Ещё раз извиняюсь за негатив, но это уже совсем ни в какие рамки не лезет)
Очень занятная статья на самом деле. Вскрывает всю подноготную нашего нелёгкого ремесла, особенно в такие времена. Прочитал с удовольствием, публикация — настоящая отдушина для разбирающегося в своём деле человека.
По этому поводу вспомнился один очень хороший советский анекдот, услышанный мной на радиорынке в Урюпинске году этак в 89-м.
Запомните раз и навсегда, что шуруп, забитый молотком, всегда лучше, чем гвоздь, завернутый отверткой. - золотые слова. Особенно очевидно это становится, когда приходит опыт в профессиональной деятельности. Для кого эта статья? Мне кажется – для искушенных профессионалов, горящим своим делом. Спасибо, что поделились!
Ситуация очень искуственная, но я плюсанул и карму и статью - все таки хочется видеть побольше на хабре инженерных идей (пусть даже сырых и не особо продуманых), а не бесконечные блоги компаний
А зачем указатель на Execute? Можно просто не передавать как аргумент, а использовать значение из области видимости родительской функции
var Execute bool
defer func() {
if !Execute {
return
}
}()
Но вообще говоря, если возникает необходимость в подобных решениях - скорее всего, вам не нужен defer, а нужно подумать ещё раз над тем, как получше разбить логику на процедуры. Если избавиться от пресловутой монстр-функции с десятью кейсами, то и необходимость в подобных не шибко хорошо читаемых решениях пропадёт
Зачем тут указатели? Вы в курсе что произойдет аллокация в куче и стек не будет задействован?
Отмена defer вызова функции в Golang