Max Home IndustryЯзыки — это вопрос моды и стиля, и я не груб, ну, может быть, насчет моды. Дело в том, что есть функции, которые соответствуют стилю и этике языка, и есть функции, которые этого не делают. Недавно сообщество Go отклонило небольшой синтаксический сахар, который мог бы значительно упростить обработку ошибок.
Модифицированные языковые функции могут стать катастрофой, поскольку с течением времени обнаруживаются неожиданные взаимодействия, требующие введения особых случаев. Языки сложны и тонки, и вам действительно нужно быть осторожным, прежде чем спешить и принимать новые идеи. Go-это язык с очень своеобразным стилем и подходом к вещам, хотя может быть трудно точно сказать, что это такое. На мой взгляд, Go-это простой язык, который отвергает многие блестящие игрушки, которые ценят другие языки и их пользователи. Go на самом деле не является объектно-ориентированным. На самом деле это не функциональный язык. Он не делает ничего необычного, нового или академического. Это язык, стоящий обеими ногами на земле, который, безусловно, соответствует образу суслика.
Я слышал теорию, что Go привлекает программистов, которые на самом деле не очень заботятся об отсутствии функций, которые другие программисты находят привлекательными. Это означает, что ваш среднестатистический программист Go не очень заинтересован в структурированной обработке исключений или универсальных методах. Они просто хотят написать код и сделать его как можно более простым и прозрачным.
Это подводит нас к обработке ошибок Go. Это примитивно, и это можно считать хорошей вещью, но это также многословно. Функции Go возвращают код ошибки, и это должно быть проверено:
f, err := os.Open(имя файла)
если err != ноль {
возвращение …, err }
Хорошо, это просто, но если вы пишете функцию, которая вызывает множество функций, у вас мало выбора, кроме как повторять обработку ошибок для каждого вызова — и это много «если». Да, у нас есть копирование и вставка, но именно так происходят ошибки, и кто-то должен прочитать этот код.
Предлагаемое решение состоит в том, чтобы добавить функцию try, которая будет использоваться с существующим оператором defer:
f := попробуйте(ос.Открыть(имя файла))
Это приводит к завершению функции, если есть ошибка, и, в свою очередь, это запускает любые функции отсрочки, которые вы можете включить. Это означает, что вместо множества операторов if вы можете обрабатывать ошибку с помощью одного обработчика ошибок:
отложите функцию() {
если err != nil { // возможно, ошибки не произошло — проверьте это
err = …// ошибка обертывания/увеличения
}
}()
Напомним, что функция отсрочки вызывается, когда функция, содержащая ее, заканчивается. Обычно он используется в качестве операции очистки, но он уже используется для борьбы с паникой — более фатальным видом ошибки Go.
В целом, я думаю, что идея элегантна и достойна реализации, поскольку это небольшая модификация, которая вписывается в существующие функции, но, похоже, это не мнение сусликов. Чтение обсуждения этой идеи, похоже, не выявило «убийственного» аргумента в пользу того, чтобы не включать ее. В основном возражения, по — видимому, связаны с общим беспокойством о том, что он запутывает поток управления, что уже делает defer, и в основном в том, что нет ничего плохого в простом способе выполнения работы с операторами if:
Наиболее важной проблемой, по-видимому, является то, что try не поощряет хороший стиль обработки ошибок, а вместо этого способствует «быстрому выходу
Многим людям не нравится идея встроенного модуля или синтаксис функции, который поставляется с ним, потому что он скрывает возврат.
Для некоторых статус-кво явных утверждений, если это не проблема, они довольны этим
и так далее.
Все это похоже на бурю в чайной чашке, и синтаксический сахар кажется хорошим, если вам не нравится носить рубашку для волос — возможно, Суслики приходят со встроенной рубашкой для волос. Однако команда Go решила отложить или, возможно, отказаться от этого предложения:
Основываясь на подавляющем отклике сообщества и обширном обсуждении здесь, мы отмечаем, что это предложение отклонено досрочно.
Может ли это быть реакцией на недавнюю критику проекта Go — что это был Google Go, а не сообщества? Проекты с открытым исходным кодом с большим участием крупных компаний подвергаются риску такого рода обвинений. Может быть, это попытка быть великодушным и очень заметно поддаться давлению сообщества — не то, чтобы оно было таким сильным? Откладывая их собственное предложение, мы получаем доказательства того, что это чувствительное к сообществу управление. Если бы мы настаивали на этом предложении, это подтвердило бы, что это проект Google для всех, кто хочет доказать это, даже если бы это было правильно.
Я не знаю, как вы, но я думаю, что проект Go нуждается в Доброжелательном Диктаторе На всю жизнь, который мог бы увидеть смысл в добавлении современных языковых функций, когда они стоят так мало. Я не думаю, что это решение хорошо для Go, и оно, безусловно, не подходит для будущего принятия Go программистами, ищущими язык с небольшим количеством сахара.