Что делать, если мне все-таки нужно поведение, когда, при возникновении ошибки в очередной строчке, мне нужно сразу же завершить выполнение фрагмента?
вот я тоже несколько раз пытался задать тут этот вопрос, но как-то не получилось. у пайка в статье тоже рассмотрены несколько вариантов, но не этот.
насколько я понял из комментариев, единственный выход в этом случае — это оформлять фрагмент в отдельную процедуру, и после каждого вызова, который может вернуть ошибку, писать что-то вроде if r.err != nil { return }
Про обработку ошибок кстати нарыл забавную статью от Роба Пайка, прочтение которой уберегло бы например меня от задавания глупых вопросов в комментариях.
Всё, прошу меня простить, в соседней ветке мне пояснили. Я достаточно долго не мог сообразить, что вариантов поведения при ошибке не два (обработать или проигнорировать), а три (явно вернуть полученную ошибку наверх).
В этом случае всё становится на свои места, просто всё, что было бы блоками try/catch, нужно оформлять отдельными процедурами.
Вопрос снимается, извините ещё раз. В статье этот момент не подчёркнут, и меня сбила с толку аналогия с vbs/vba
А, простите, я не сразу понял Вас. Вместо блоков try-catch предлагается использовать отдельные процедуры и вместо бросания исключения делать return? Ну тогда да, тоже подход
Простите, но «обработать или забить» — это чушь, не выбор. Большинство функций при ошибке не вернут осмысленного результата (или я чего-то не понимаю). Попытка использовать этот результат без обработки приведёт к настолько плохо диагностируемым ошибкам, что уши завернутся.
Если кодер сильно хочет и считает, что он прав — он может заглушить обработку ошибки
… при этом потеряв логическую связность кода — при заглушенной ошибке он нарвётся на клад где-то в совершенно другом месте, попытавшись использовать результат «заглушенной» функции.
Просто подобной логики обработки ошибок (весьма упрощённой, но идея та же) я наелся от души ещё в vbscript/vba. Иная простота, как говорится…
Ошибка — не означает автоматически, что нужно завершить функцию
Само собой. И, как в другой ветке уже упомянуто, огромные куски кода под try/catch — конечно же порочны. Но заставлять кодера маниакально писать анализ после каждого оператора… Крайность же, возведённая в стандарт )) какой-то «on error resume next» ))
я не хочу развивать тему exceptions vs return-values
Мне кажется, зря. Если что-то преподносится как преимущество, как обойтись без сравнения?
«Классическая» обработка исключений (try/catch) построена ровно на одном — сплошь и рядом есть фрагменты кода, которые работают как единое целое, в них последующие операции бессмысленны при ошибке в предыдущих. Если внутри такого блока произошло что-то, то дальше этот блок выполнять нет смысла. Именно поэтому исключения обрабатываются не после каждой строчки, а в конце блока.
В философии Go практика такого структурирования кода является порочной?
не надо этого делать. карма я так понимаю одна на всё, а терять интересных собеседников потому, что они на другом конце света кому-то не понравились...
насколько я понял из комментариев, единственный выход в этом случае — это оформлять фрагмент в отдельную процедуру, и после каждого вызова, который может вернуть ошибку, писать что-то вроде if r.err != nil { return }
В этом случае всё становится на свои места, просто всё, что было бы блоками try/catch, нужно оформлять отдельными процедурами.
Вопрос снимается, извините ещё раз. В статье этот момент не подчёркнут, и меня сбила с толку аналогия с vbs/vba
Просто подобной логики обработки ошибок (весьма упрощённой, но идея та же) я наелся от души ещё в vbscript/vba. Иная простота, как говорится…
Мне кажется, зря. Если что-то преподносится как преимущество, как обойтись без сравнения?
В философии Go практика такого структурирования кода является порочной?
2) на Большом Dirty основной рычаг не демократия, а модераторы. А в Лепрозории она работает ну мягко говоря неэффективно. хотя и забавно.