Comments 17
Тут возникает приславутый вопрос zero cost abstractions. Насколько адекватно компилятор реагирует на подобные усложнения? Чисто теоретически все должно быть нормально, но на деле тот же Write во втором примере будет inline фукнцией или будет дополнительным вызовом с сохранением стека? Все же для такого низкоуровневого кода, каждый лишний call может быть критичен.
Смысл понятен, статья хорошая.
Вопрос по сути: разве такое вот сокрытие ошибок не идёт в разрез с самой идеей Роба Пайка? Насколько я помню тот его тезис, он как раз говорил о том, что обрабатывать ошибки надо везде обычным образом, трактуя их просто как один из результатов вызова функции. Да и в целом любое сокрытие кода и введение дополнительных конструкций и абстракций как по мне не очень-то «the way to Go». Как считаете?
Вопрос по сути: разве такое вот сокрытие ошибок не идёт в разрез с самой идеей Роба Пайка? Насколько я помню тот его тезис, он как раз говорил о том, что обрабатывать ошибки надо везде обычным образом, трактуя их просто как один из результатов вызова функции. Да и в целом любое сокрытие кода и введение дополнительных конструкций и абстракций как по мне не очень-то «the way to Go». Как считаете?
Нет ошибки в том, чтобы исправить свою ошибку…
Это я про то, что way of Go можно подкорректировать, если есть way получше )
Задача любого языка — предоставить программисту хороший инструмент для реализации его (программиста) идей. Понятие «хороший», имхо, включает в себя и лаконичность — когда алгоритм записывается кратко и четко, без необходимости излишне углубляться в низкоуровневые детали, как выделение/освобождение памяти, управление блокировками либо постоянная обработка ошибок на каждом! шагу (наш случай). И если с управлением памятью и многопоточностью у Go получилось вполне неплохо, то обработке ошибок в первой версии Go уделили все-таки недостаточно внимания.
Так что очень хорошо, что этот вопрос не теряет в актуальности и активно прорабатывается.
Это я про то, что way of Go можно подкорректировать, если есть way получше )
Задача любого языка — предоставить программисту хороший инструмент для реализации его (программиста) идей. Понятие «хороший», имхо, включает в себя и лаконичность — когда алгоритм записывается кратко и четко, без необходимости излишне углубляться в низкоуровневые детали, как выделение/освобождение памяти, управление блокировками либо постоянная обработка ошибок на каждом! шагу (наш случай). И если с управлением памятью и многопоточностью у Go получилось вполне неплохо, то обработке ошибок в первой версии Go уделили все-таки недостаточно внимания.
Так что очень хорошо, что этот вопрос не теряет в актуальности и активно прорабатывается.
Я не увидел сразу, что это перевод м-ра Чейни :) Это многое объясняет, у него уже давно есть какая-то тактика, и он её старается придерживаться. Толковый мужик, безусловно.
Хотя лично мне его взгляды не всегда близки, и понятность кода в Go очень нравится. Пускай даже с вот этими шаблонами для обработки ошибок.
Впрочем, разработчики языка скорее на Вашей с Дейвом стороне, и свою недоработку при выборе метода обработки ошибок они признают. Подождём версии 1.13 или 2.0.
Хотя лично мне его взгляды не всегда близки, и понятность кода в Go очень нравится. Пускай даже с вот этими шаблонами для обработки ошибок.
Впрочем, разработчики языка скорее на Вашей с Дейвом стороне, и свою недоработку при выборе метода обработки ошибок они признают. Подождём версии 1.13 или 2.0.
Ещё немного и получатся haskell абстракции. Второй пример особенно ужасен, если между вызовами через пару лет вставят код и будут надеяться, что он не выполнится, если ранее возникла ошибка.
предложенные вариенты добавляют не ясности в код, а магию…
ошибки нужно контролировать… и в идеале — лучше это делать (контроль над ошибками) непосредственно в созданной функции, а не где-то там в десятой по счету под слоями абстракций… это и ясность кода, и логики, и легче модифицировать\отлаживать.
а вообще, мне странно воспринимать когда в ошибку пишут конец файла и т.п., почему тогда не сделать чтото типо:
где `eof` — булевый тып, говорит что достигнут конец файла.
да, способ покажется избиточным (+1 переменная ради такого), но тогда `err != nill` когда и правда есть ошибка, по моему — так больше явности.
ошибки нужно контролировать… и в идеале — лучше это делать (контроль над ошибками) непосредственно в созданной функции, а не где-то там в десятой по счету под слоями абстракций… это и ясность кода, и логики, и легче модифицировать\отлаживать.
а вообще, мне странно воспринимать когда в ошибку пишут конец файла и т.п., почему тогда не сделать чтото типо:
_, eof, err = br.ReadString('\n')где `eof` — булевый тып, говорит что достигнут конец файла.
да, способ покажется избиточным (+1 переменная ради такого), но тогда `err != nill` когда и правда есть ошибка, по моему — так больше явности.
по-моему, никакой магии, а только чуточка элегантности
внутри это +1 операция чтения, чтобы понять а есть там что-то или нет, если не конец, то надо сохранить результат упреждающего чтения а соответственно при очередном вызове проверять было ли что-то прочитано заранее…
сомнительное такое преимущество
сомнительное такое преимущество
В чем проблема написать в первом случае так?
for {
_, err = br.ReadString('\n')
if err != nil {
if err == io.EOF {
break;
}
return 0, err
}
lines++
}
Sign up to leave a comment.
Освобождаемся от обработки ошибок, устраняя ошибки