Я согласен, что это лучший путь вперед: исправить наиболее распространенную проблему с помощью простого дизайна.

Я не хочу отвлекаться (не стесняйтесь отложить этот разговор), но Rust пошел туда и в конечном итоге остановился на постфиксном операторе ? , а не на встроенной функции, для повышения читабельности.

Предложение gophercon цитирует ? в рассмотренных идеях и приводит три причины, по которым оно было отвергнуто: первое («передачи потока управления, как правило, сопровождаются ключевыми словами») и третье («обработчики определены более естественно с ключевым словом, поэтому проверки тоже должны быть") больше не применяются. Второй — стилистический: в нем говорится, что, хотя постфиксный оператор лучше работает для цепочки, он все же может хуже читаться в некоторых случаях, например:

check io.Copy(w, check newReader(foo))

скорее, чем:

io.Copy(w, newReader(foo)?)?

но теперь у нас было бы:

try(io.Copy(w, try(newReader(foo))))

который, я думаю, явно худший из трех, поскольку уже даже не очевидно, какая основная функция вызывается.

Итак, суть моего комментария заключается в том, что все три причины, указанные в предложении gophercon для отказа от использования ? , не относятся к этому предложению try ; ? является кратким, очень читабельным, он не затеняет структуру оператора (с его внутренней иерархией вызовов функций) и может быть объединен в цепочку. Он удаляет еще больше беспорядка из представления, не затеняя поток управления больше, чем уже делает предложенный try() .

Чтобы уточнить:

Делает

func f() (n int, err error) {
  n = 7
  try(errors.New("x"))
  // ...
}

вернуть (0, "х") или (7, "х")? Я бы предположил последнее.

Нужно ли называть возвращаемую ошибку в случае, когда нет оформления или обработки (например, во внутренней вспомогательной функции)? Я бы предположил, что нет.

Ваш пример возвращает 7, errors.New("x") . Это должно быть понятно из полного документа, который скоро будет представлен (https://golang.org/cl/180557).

Параметр результата ошибки не нужно называть, чтобы использовать try . Его нужно называть только в том случае, если функция должна ссылаться на него в отложенной функции или где-либо еще.

Я действительно недоволен встроенной функцией _function_, влияющей на поток управления вызывающей стороны. Я ценю невозможность добавления новых ключевых слов в Go 1, но решение этой проблемы с помощью магических встроенных функций кажется мне неправильным. Затенение других встроенных функций не приводит к таким непредсказуемым результатам, как изменение потока управления.

Мне не нравится, как выглядит постфикс ? , но я думаю, что он все же лучше try() .

Редактировать: Ну, мне удалось полностью забыть, что паника существует и не является ключевым словом.

Подробное предложение уже здесь (в ожидании улучшений форматирования, которые появятся в ближайшее время) и, надеюсь, ответит на множество вопросов.

@dominikh В подробном предложении это подробно обсуждается, но обратите внимание, что panic и recover — это две встроенные функции, которые также влияют на поток управления.

Одно уточнение/предложение по улучшению:

if the last argument supplied to try, of type error, is not nil, the enclosing function’s error result variable (...) is set to that non-nil error value before the enclosing function returns

Можно ли вместо этого сказать is set to that non-nil error value and the enclosing function returns ? (с/до/и)

При первом чтении казалось, что before the enclosing function returns _в конце концов_ установит значение ошибки в какой-то момент в будущем прямо перед возвратом функции - возможно, в более поздней строке. Правильная интерпретация заключается в том, что try может привести к возврату текущей функции. Это удивительное поведение для текущего языка, поэтому приветствуется более четкий текст.

Я думаю, что это просто сахар, и небольшое количество ярых противников дразнили golang по поводу многократного использования ввода if err != nil ... , и кто-то воспринял это всерьез. Я не думаю, что это проблема. Не хватает только этих двух встроенных модулей:

https://github.com/purpleidea/mgmt/blob/a235b760dc3047a0d66bb0b9d63c25bc746ed274/util/errwrap/errwrap.go#L26

Не знаю, зачем кому-то писать подобную функцию, но каков будет ожидаемый результат для

try(foobar())

Если foobar вернул (error, error)

Я отказываюсь от своих прежних опасений по поводу потока управления и больше не предлагаю использовать ? . Я прошу прощения за рефлекторный ответ (хотя я хотел бы отметить, что этого бы не произошло, если бы проблема была зарегистрирована _после_ того, как было доступно полное предложение).

Я не согласен с необходимостью упрощенной обработки ошибок, но я уверен, что это проигрышная битва. try , как указано в предложении, кажется наименее плохим способом сделать это.

@webermaster Только последний результат error является особым для выражения, переданного в try , как описано в документе предложения.

Как и @dominikh , я также не согласен с необходимостью упрощенной обработки ошибок.

Он превращает вертикальную сложность в горизонтальную, что редко бывает хорошей идеей.

Однако, если бы мне пришлось выбирать между предложениями по упрощению обработки ошибок, это было бы моим предпочтительным предложением.

Было бы полезно, если бы это могло сопровождаться (на каком-то этапе приемлемости) инструментом для преобразования кода Go для использования try в некотором подмножестве функций, возвращающих ошибку, где такое преобразование может быть легко выполнено без изменение семантики. Мне приходят в голову три преимущества:

• При оценке этого предложения люди могли бы быстро понять, как try можно использовать в их кодовой базе.
• Если try появится в будущей версии Go, люди, скорее всего, захотят изменить свой код, чтобы использовать его. Наличие инструмента для автоматизации простых дел очень поможет.
• Имея возможность быстро преобразовать большую кодовую базу для использования try , вы сможете легко изучить влияние реализации в масштабе. (Скажем, правильность, производительность и размер кода.) Однако реализация может быть достаточно простой, чтобы этим можно было пренебречь.

Я просто хотел бы сказать, что, по моему мнению, голый try(foo()) , фактически выходящий из вызывающей функции, лишает нас визуальной подсказки о том, что поток функции может измениться в зависимости от результата.

Я чувствую, что могу работать с try , если достаточно привыкну, но я также чувствую, что нам потребуется дополнительная поддержка IDE (или что-то в этом роде), чтобы выделить try для эффективного распознавания неявного потока в обзорах кода. /сеансы отладки

Что меня больше всего беспокоит, так это необходимость именования возвращаемых значений только для того, чтобы оператор отсрочки был счастлив.

Я думаю, что общая проблема обработки ошибок, на которую жалуется сообщество, представляет собой комбинацию шаблона if err != nil И добавления контекста к ошибкам. В FAQ четко указано, что последнее намеренно опущено как отдельная проблема, но я чувствую, что тогда это становится неполным решением, но я готов дать ему шанс, подумав об этих двух вещах:

1. Объявите err в начале функции.
   Это работает? Я вспоминаю проблемы с отложенными и неназванными результатами. Если это не так, предложение должно рассмотреть это.

func sample() (string, error) {
  var err error
  defer fmt.HandleErrorf(&err, "whatever")
  s := try(f())
  return s, nil
}

1. Назначайте значения так же, как мы делали это в прошлом, но используйте вспомогательную функцию wrapf с шаблоном if err != nil .

func sample() (string, error) {
  s, err := f()
  try(wrapf(err, "whatever"))
  return s, nil
}
func wrapf(err error, format string, ...v interface{}) error {
  if err != nil {
    // err = wrapped error
  }
  return err
}

Если что-то работает, я могу с этим справиться.

func sample() (string, error) {
  var err error
  defer fmt.HandleErrorf(&err, "whatever")
  s := try(f())
  return s, nil
}

Так не пойдет. Отсрочка обновит локальную переменную err , которая не связана с возвращаемым значением.

func sample() (string, error) {
  s, err := f()
  try(wrapf(err, "whatever"))
  return s, nil
}
func wrapf(err error, format string, ...v interface{}) error {
  if err != nil {
    // err = wrapped error
  }
  return err
}

Это должно сработать. Однако он будет вызывать wrapf даже при нулевой ошибке.
Это также будет (продолжать) работать, и ИМО намного понятнее:

func sample() (string, error) {
  s, err := f()
  if err != nil {
      return "", wrap(err)
  }
  return s, nil
}

Никто не заставит вас использовать try .

Не знаю, зачем кому-то писать подобную функцию, но каков будет ожидаемый результат для

try(foobar())

Если foobar вернул (error, error)

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

Не могли бы вы уточнить на примере?

@cespare : кто-то должен иметь возможность написать go fix , который переписывает существующий код, подходящий для try , так что он использует try . Может быть полезно понять, как можно упростить существующий код. Мы не ожидаем каких-либо существенных изменений в размере кода или производительности, поскольку try — это просто синтаксический сахар, заменяющий общий шаблон более коротким фрагментом исходного кода, который производит практически такой же код на выходе. Также обратите внимание, что код, который использует try , будет привязан к версии Go, по крайней мере той версии, в которой был введен try .

@lestrrat : Согласен, что нужно будет узнать, что try может изменить поток управления. Мы подозреваем, что IDE может достаточно легко выделить это.

@Goodwine : Как уже указал @randall77 , ваше первое предложение не сработает. Один вариант, о котором мы подумали (но не обсуждался в документе), — это возможность иметь некоторую заранее объявленную переменную, которая обозначает результат error (если он присутствует в первую очередь). Это устранило бы необходимость называть этот результат только для того, чтобы его можно было использовать в defer . Но это было бы еще большим волшебством; это не кажется оправданным. Проблема с присвоением имени возвращаемому результату, по сути, косметическая, и самое главное — это автоматически сгенерированные API, обслуживаемые go doc и друзьями. Было бы легко решить эту проблему в этих инструментах (см. также FAQ подробного проектного документа по этому вопросу).

@nictuku : Что касается вашего предложения по разъяснению (s/before/and/): я думаю, что код непосредственно перед абзацем, на который вы ссылаетесь, ясно дает понять, что именно происходит, но я понимаю вашу точку зрения, s/before/and/ может сделать прозу более понятной. Я внесу изменения.

См. CL 180637 .

Мне на самом деле очень нравится это предложение. Однако у меня есть одно замечание. Точка выхода функций в Go всегда помечалась return . Паники также являются точками выхода, однако это катастрофические ошибки, которые, как правило, никогда не должны возникать.

Создание точки выхода для функции, которая не является return и должна быть банальной, может привести к гораздо менее читаемому коду. Я слышал об этом в докладе, и трудно не заметить красоту того, как устроен этот код:

func CopyFile(src, dst string) error {
    r, err := os.Open(src)
    if err != nil {
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }
    defer r.Close()

    w, err := os.Create(dst)
    if err != nil {
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }

    if _, err := io.Copy(w, r); err != nil {
        w.Close()
        os.Remove(dst)
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }

    if err := w.Close(); err != nil {
        os.Remove(dst)
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }
}

Этот код может выглядеть как большой беспорядок, и он был _предназначен_ черновиком обработки ошибок, но давайте сравним его с тем же самым с try .

func CopyFile(src, dst string) error {
    defer func() {
        err = fmt.Errorf("copy %s %s: %v", src, dst, err)
    }()
    r, err := try(os.Open(src))
    defer r.Close()

    w, err := try(os.Create(dst))

    defer w.Close()
    defer os.Remove(dst)
    try(io.Copy(w, r))
    try(w.Close())

    return nil
}

Вы можете посмотреть на это с первого взгляда и подумать, что он выглядит лучше, потому что в нем гораздо меньше повторяющегося кода. Однако было очень легко определить все места, которые функция вернула в первом примере. Все они были с отступом и начинались с return , за которым следовал пробел. Это связано с тем, что все условные возвраты _должны_ находиться внутри условных блоков, таким образом, они имеют отступ в соответствии со стандартами gofmt . return также, как было сказано ранее, является единственным способом выйти из функции, не говоря о том, что произошла катастрофическая ошибка. Во втором примере есть только один return , поэтому похоже, что единственное, что функция _ever_ должна вернуть, это nil . Последние два вызова try легко увидеть, но первые два немного сложнее, и было бы еще сложнее, если бы они были где-то вложенными, т.е. что-то вроде proc := try(os.FindProcess(try(strconv.Atoi(os.Args[1])))) .

Возврат из функции, казалось, был «священным» делом, поэтому я лично считаю, что все точки выхода из функции должны быть отмечены return .

Кто-то это уже реализовал 5 лет назад. Если вы заинтересованы, вы можете
попробуй эту функцию

https://news.ycombinator.com/item?id=20101417

Я реализовал try() в Go пять лет назад с препроцессором AST и использовал его в реальных проектах, это было довольно приятно: https://github.com/lunixbochs/og

Вот несколько примеров того, как я использую его в функциях с тяжелой проверкой ошибок: https://github.com/lunixbochs/poxd/blob/master/tls.go#L13 .

Я ценю усилия, затраченные на это. Я думаю, что это самое удачное решение, которое я когда-либо видел. Но я думаю, что это вводит кучу работы при отладке. Распаковывать try и добавлять блок if каждый раз, когда я отлаживаю, и перепаковывать его, когда я закончу, утомительно. И у меня также есть некоторое передергивание по поводу волшебной переменной err, которую мне нужно учитывать. Меня никогда не беспокоила явная проверка ошибок, так что, возможно, я не тот человек, которого нужно спрашивать. Мне всегда казалось, что он «готов к отладке».

@griesemer
Моя проблема с предложенным вами использованием отсрочки в качестве способа обработки переноса ошибок заключается в том, что поведение из фрагмента, который я показал (повторяется ниже), не очень распространено, AFAICT, и поскольку это очень редко, я могу представить, что люди пишут это, думая, что это работает когда это не так.

Например... новичок не знал бы об этом, если бы у него была ошибка из-за этого, он не сказал бы "конечно, мне нужен именованный возврат", они бы напряглись, потому что это должно работать, а это не работает.

var err error
defer fmt.HandleErrorf(err);

try уже слишком волшебно, так что вы можете пойти дальше и добавить это неявное значение ошибки. Думайте о новичках, а не о тех, кто знает все нюансы Го. Если это недостаточно ясно, я не думаю, что это правильное решение.

Или... Не предлагайте использовать отсрочку таким образом, попробуйте другой способ, более безопасный, но все же читабельный.

@deanveloper Это правда, что это предложение (и, если уж на то пошло, любое предложение, пытающееся сделать то же самое) удалит явно видимые операторы return из исходного кода - в конце концов, в этом весь смысл предложения, не так ли? Чтобы удалить шаблон из операторов if и returns , которые все одинаковы. Если вы хотите сохранить return , не используйте try .

Мы привыкли сразу распознавать операторы return (и panic ), потому что именно так этот тип потока управления выражается в Go (и многих других языках). Кажется невероятным, что мы также распознаем try как изменяющийся поток управления после некоторого привыкания к нему, точно так же, как мы это делаем для return . Не сомневаюсь, что и в этом поможет хорошая поддержка IDE.

У меня две проблемы:

• именованные возвраты были очень запутанными, и это побуждает их к новому и важному варианту использования.
• это будет препятствовать добавлению контекста к ошибкам

По моему опыту, добавление контекста к ошибкам сразу после каждого сайта вызова имеет решающее значение для получения кода, который можно легко отлаживать. А именованные возвраты в какой-то момент приводили в замешательство почти каждого разработчика Go, которого я знаю.

Более мелкая стилистическая проблема заключается в том, что, к сожалению, много строк кода теперь будет заключено в try(actualThing()) . Я могу себе представить, что большинство строк кодовой базы завернуты в try() . Это прискорбно.

Я думаю, что эти проблемы будут решены с помощью настройки:

a, b, err := myFunc()
check(err, "calling myFunc on %v and %v", a, b)

check() будет вести себя так же, как try() , но в общем откажется от передачи значений, возвращаемых функцией, и вместо этого предоставит возможность добавлять контекст. Это все равно вызовет возврат.

Это сохранит многие преимущества try() :

• это встроенный
• следует за существующим потоком управления WRT, чтобы отложить
• это хорошо согласуется с существующей практикой добавления контекста к ошибкам
• он согласуется с текущими предложениями и библиотеками для переноса ошибок, такими как errors.Wrap(err, "context message")
• это приводит к чистому сайту вызова: в строке a, b, err := myFunc() нет шаблона
• описание ошибок с помощью defer fmt.HandleError(&err, "msg") по-прежнему возможно, но это не нужно поощрять.
• сигнатура check немного проще, потому что ей не нужно возвращать произвольное количество аргументов из функции, которую она обертывает.

@ s4n-gt Спасибо за эту ссылку. Я не знал об этом.

@Goodwine Точка взята. Причина, по которой не предоставляется более прямая поддержка обработки ошибок, подробно обсуждается в проектной документации. Также фактом является то, что в течение года или около того (с тех пор, как эскизы проектов были опубликованы на прошлогоднем Gophercon) не было найдено удовлетворительного решения для явной обработки ошибок. Вот почему в этом предложении это намеренно опущено (и вместо этого предлагается использовать defer ). Это предложение по-прежнему оставляет возможность для будущих улучшений в этом отношении.

В предложении упоминается изменение пакетного тестирования, позволяющее тестам и эталонным тестам возвращать ошибку. Хотя это не будет «скромным изменением библиотеки», мы могли бы рассмотреть возможность принятия func main() error . Это сделало бы написание небольших сценариев намного приятнее. Семантика будет эквивалентна:

func main() {
  if err := newmain(); err != nil {
    println(err.Error())
    os.Exit(1)
  }
}

Последняя критика. На самом деле это не критика самого предложения, а критика общего ответа на контраргумент «функция управления потоком».

Ответом на «Мне не нравится, что функция управляет потоком» будет то, что « panic также управляет потоком программы!». Однако есть несколько причин, по которым panic может сделать это, но они не относятся к try .

1. panic удобен для начинающих программистов, потому что он интуитивно понятен, он продолжает разворачивать стек. Не нужно даже искать, как работает panic , чтобы понять, что он делает. Начинающим программистам даже не нужно беспокоиться о recover , так как новички обычно не создают механизмы восстановления после паники, тем более что они почти всегда менее благоприятны, чем простое избегание паники.

2. panic — это имя, которое легко увидеть. Это вызывает беспокойство, и это необходимо. Если кто-то видит panic в кодовой базе, он должен немедленно подумать о том, как _избежать_ паники, даже если это тривиально.

3. В дополнение к последнему пункту panic не может быть вложен в вызов, что еще больше упрощает его просмотр.

Паника может управлять ходом программы, потому что ее очень легко обнаружить, и интуитивно понятно, что она делает.

Функция try не удовлетворяет ни одному из этих пунктов.

1. Невозможно догадаться, что делает try , не посмотрев на него документацию. Многие языки используют это ключевое слово по-разному, что затрудняет понимание того, что оно означает в Go.

2. try не бросается в глаза, особенно когда это функция. _Особенно_ когда подсветка синтаксиса выделяет его как функцию. _ОСОБЕННО_ после разработки на таком языке, как Java, где try рассматривается как ненужный шаблон (из-за проверенных исключений).

3. try можно использовать в аргументе вызова функции, как в моем примере в моем предыдущем комментарии proc := try(os.FindProcess(try(strconv.Atoi(os.Args[1])))) . Это еще больше усложняет обнаружение.

Мои глаза игнорируют функции try , даже когда я специально их ищу. Мои глаза увидят их, но сразу перейдут к вызовам os.FindProcess или strconv.Atoi . try — это условный возврат. И поток управления, и возврат в Go поддерживаются на пьедестале. Весь поток управления внутри функции имеет отступ, а все возвращаемые значения начинаются с return . Смешивание обеих этих концепций вместе в вызове функции, который легко пропустить, кажется немного странным.

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

@buchanae интересно. Однако, как написано, форматирование в стиле fmt перемещается из пакета в сам язык, что открывает банку червей.

Однако, как написано, форматирование в стиле fmt перемещается из пакета в сам язык, что открывает банку червей.

Хорошая точка зрения. Более простой пример:

a, b, err := myFunc()
check(err, "calling myFunc")

@buchanae Мы решили сделать явную обработку ошибок более непосредственно связанной с try — см. подробный проектный документ , в частности раздел, посвященный итерациям проектирования. Ваше конкретное предложение check позволит увеличить количество ошибок только с помощью чего-то вроде fmt.Errorf API (как часть check ), если я правильно понимаю. В общем, люди могут захотеть делать все что угодно с ошибками, а не просто создавать новый, который ссылается на исходный через его строку ошибки.

Опять же, это предложение не пытается решить все ситуации обработки ошибок. Я подозреваю, что в большинстве случаев try имеет смысл для кода, который сейчас выглядит примерно так:

a, b, c, ... err := try(someFunctionCall())
if err != nil {
   return ..., err
}

Существует очень много кода, который выглядит так. И не каждый фрагмент кода, выглядящий как этот, нуждается в дополнительной обработке ошибок. А там, где defer неверно, можно использовать оператор if .

Я не следую этой линии:

defer fmt.HandleErrorf(&err, “foobar”)

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

defer fmt.HandleErrorf(&err, “foobar: %v”, err)

Дублирование err немного заикается. На самом деле это не совсем соответствует предложению, просто побочный комментарий к документу.

Я разделяю две озабоченности, поднятые @buchanae , относительно именованных возвратов и контекстных ошибок.

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

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

Я действительно думаю, что предложение try делает некоторый код значительно лучше. Вот функция, которую я выбрал более или менее наугад из кодовой базы моего текущего проекта, с некоторыми измененными именами. Я особенно впечатлен тем, как try работает при назначении полям структуры. (Это при условии, что мое прочтение предложения верно и что это работает?)

Существующий код:

func NewThing(thingy *foo.Thingy, db *sql.DB, client pb.Client) (*Thing, error) {
        err := dbfile.RunMigrations(db, dbMigrations)
        if err != nil {
                return nil, err
        }
        t := &Thing{
                thingy: thingy,
        }
        t.scanner, err = newScanner(thingy, db, client)
        if err != nil {
                return nil, err
        }
        t.initOtherThing()
        return t, nil
}

С try :

func NewThing(thingy *foo.Thingy, db *sql.DB, client pb.Client) (*Thing, error) {
        try(dbfile.RunMigrations(db, dbMigrations))
        t := &Thing{
                thingy:  thingy,
                scanner: try(newScanner(thingy, db, client)),
        }
        t.initOtherThing()
        return t, nil
}

Никакой потери читабельности, за исключением, возможно, того, что менее очевидно, что newScanner может потерпеть неудачу. Но тогда в мире с try программисты Go будут более чувствительны к его присутствию.

@josharian Что касается main , возвращающего error : мне кажется, что ваша маленькая вспомогательная функция - это все, что нужно для получения того же эффекта. Я не уверен, что изменение подписи main оправдано.

Что касается примера «foobar»: это просто плохой пример. Я, вероятно, должен изменить его. Спасибо, что подняли это.

defer fmt.HandleErrorf(&err, “foobar: %v”, err)

На самом деле, это не может быть правильным, потому что err будет оцениваться слишком рано. Есть несколько способов обойти это, но ни один из них не так чист, как оригинальный (я думаю, ошибочный) HandleErrorf. Я думаю, было бы хорошо иметь более реалистичный рабочий пример или два вспомогательной функции.

РЕДАКТИРОВАТЬ: эта ошибка ранней оценки присутствует в примере
ближе к концу документа:

defer fmt.HandleErrorf(&err, "copy %s %s: %v", src, dst, err)

@adg Да, try можно использовать, как вы используете его в своем примере. Я оставлю ваши комментарии относительно именованных возвратов такими, какие они есть.

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

try не пытается обрабатывать все виды вещей, которые люди хотят делать с ошибками, а только те, которые мы можем найти практическим способом значительно упростить. Я считаю, что мой пример check идет по тому же пути.

По моему опыту, наиболее распространенной формой кода обработки ошибок является код, который по существу добавляет трассировку стека, иногда с добавленным контекстом. Я обнаружил, что трассировка стека очень важна для отладки, когда я следую за сообщением об ошибке в коде.

Но, может быть, другие предложения добавят трассировку стека ко всем ошибкам? Я потерял след.

В примере, который дал @adg , есть две потенциальные ошибки, но нет контекста. Если newScanner и RunMigrations сами по себе не предоставляют сообщений, которые подсказывают вам, что из них пошло не так, вам остается только гадать.

В примере, который дал @adg , есть две потенциальные ошибки, но нет контекста. Если newScanner и RunMigrations сами по себе не предоставляют сообщений, которые подсказывают вам, что из них пошло не так, вам остается только гадать.

Это верно, и это выбор дизайна, который мы сделали в этом конкретном фрагменте кода. Мы часто переносим ошибки в другие части кода.

Я разделяю опасения @deanveloper и других, что это может усложнить отладку. Это правда, что мы можем не использовать его, но стили сторонних зависимостей не находятся под нашим контролем.
Если менее повторяющиеся if err := ... { return err } являются основной точкой, мне интересно, будет ли достаточно «условного возврата», как предложено https://github.com/golang/go/issues/27794 .

        return nil, err if f, err := os.Open(...)
        return nil, err if _, err := os.Write(...)

Я думаю, что ? будет лучше, чем try , и постоянное преследование defer за ошибку также будет непростой задачей.

Это также навсегда закрывает ворота для исключений, использующих try/catch .

Это также навсегда закрывает ворота для исключений с использованием try/catch.

Я более чем согласен с этим.

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

Как говорит @griesemer :

Опять же, это предложение не пытается решить все ситуации обработки ошибок. Я подозреваю, что в большинстве случаев try имеет смысл для кода, который сейчас выглядит примерно так:
a, b, c, ... err := try(someFunctionCall())
если ошибка != ноль {
вернуться ..., ошибиться
}
Существует очень много кода, который выглядит так. И не каждый фрагмент кода, выглядящий как этот, нуждается в дополнительной обработке ошибок. И там, где отсрочка неверна, можно использовать оператор if.

Да, но разве хороший идиоматический код не должен всегда оборачивать/украшать свои ошибки? Я считаю, что именно поэтому мы представляем усовершенствованные механизмы обработки ошибок, чтобы добавить ошибки контекста/обтекания в stdlib. Как я вижу, это предложение рассматривает только самый простой вариант использования.

Кроме того, это предложение касается только случая переноса/украшения нескольких возможных мест возврата ошибок в _одном месте_ с использованием именованных параметров с вызовом отсрочки.

Но это ничего не дает для случая, когда нужно добавить разные контексты к разным ошибкам в одной функции. Например, очень важно декорировать ошибки БД, чтобы получить больше информации о том, откуда они берутся (при условии отсутствия трассировки стека).

Это пример реального кода, который у меня есть -

func (p *pgStore) DoWork() error {
    tx, err := p.handle.Begin()
    if err != nil {
        return err
    }
    var res int64
    err = tx.QueryRow(`INSERT INTO table (...) RETURNING c1`, ...).Scan(&res)
    if err != nil {
        tx.Rollback()
        return fmt.Errorf("insert table: %w", err)
    }

    _, err = tx.Exec(`INSERT INTO table2 (...) VALUES ($1)`, res)
    if err != nil {
        tx.Rollback()
        return fmt.Errorf("insert table2: %w", err)
    }
    return tx.Commit()
}

По предложению:

Если требуется дополнение или перенос ошибки, есть два подхода: придерживаться проверенного оператора if или, альтернативно, «объявить» обработчик ошибок с помощью оператора defer:

Я думаю, что это попадет в категорию «придерживаться проверенного оператора if». Я надеюсь, что предложение может быть улучшено, чтобы решить и эту проблему.

Я настоятельно рекомендую команде Go отдать приоритет дженерикам , так как именно здесь Go слышит больше всего критики, и дождаться обработки ошибок. Сегодняшняя техника не такая болезненная (хотя go fmt должна стоять на одной строке).

Концепция try() имеет все проблемы check из проверки/дескриптора:

1. Это не читается как Go. Людям нужен синтаксис присваивания без последующего нулевого теста, так как это похоже на Go. Это предполагалось в тринадцати отдельных ответах на проверку/обработку; см. _Повторяющиеся темы_ здесь:
   https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback#recurring -темы

   f, #      := os.Open(...) // return on error
   f, #panic := os.Open(...) // panic on error
   f, #hname := os.Open(...) // invoke named handler on error
   // # is any available symbol or unambiguous pair
   

2. Вложенность вызовов функций, которые возвращают ошибки, скрывает порядок операций и затрудняет отладку. Положение дел при возникновении ошибки, а значит и последовательность вызова, должно быть понятно, а здесь нет:
   try(step4(try(step1()), try(step3(try(step2())))))
   Теперь вспомним, что язык запрещает:
   f(t ? a : b) и f(a++)

3. Было бы тривиально возвращать ошибки без контекста. Ключевым обоснованием проверки/обработки было поощрение контекстуализации.

4. Он привязан к типу error и последнему возвращаемому значению. Если нам нужно проверить другие возвращаемые значения/типы на наличие исключительного состояния, мы вернемся к: if errno := f(); errno != 0 { ... }

5. Он не предлагает несколько путей. Код, вызывающий API-интерфейсы хранилища или сети, обрабатывает такие ошибки иначе, чем те, которые возникают из-за неправильного ввода или неожиданного внутреннего состояния. Мой код делает одно из этого гораздо чаще, чем return err :

   • лог.Фатальный()
   • panic() для ошибок, которые никогда не должны возникать
   • запишите сообщение и повторите попытку

@gopherbot добавить Go2, LanguageChange

Как насчет использования только ? для развертки результата, как rust

Причиной, по которой мы скептически относимся к вызову try(), может быть два неявных связывания. Мы не можем видеть привязку для ошибки возвращаемого значения и аргументы для try(). Что касается try(), мы можем установить правило, согласно которому мы должны использовать try() с функцией-аргументом, которая имеет ошибку в возвращаемых значениях. Но привязки к возвращаемым значениям нет. Поэтому я думаю, что пользователям нужно больше выражений, чтобы понять, что делает этот код.

func doSomething() (int, %error) {
  f := try(foo())
  ...
}

• Мы не можем использовать try(), если doSomething не имеет %error в возвращаемых значениях.
• Мы не можем использовать try(), если foo() не имеет ошибки в последнем из возвращаемых значений.

Сложно добавить новые требования/функции к существующему синтаксису.

Честно говоря, я думаю, что foo() также должен иметь %error.

Добавить еще 1 правило

• %error может быть только один в списке возвращаемых значений функции.

В подробном проектном документе я заметил, что в более ранней итерации было предложено передать обработчик ошибок встроенной функции try. Так:

handler := func(err error) error {
        return fmt.Errorf("foo failed: %v", err)  // wrap error
}

f := try(os.Open(filename), handler)  

или еще лучше вот так:

f := try(os.Open(filename), func(err error) error {
        return fmt.Errorf("foo failed: %v", err)  // wrap error
})  

Хотя, как говорится в документе, это вызывает несколько вопросов, я думаю, что это предложение было бы гораздо более желательным и полезным, если бы в нем была сохранена возможность опционального указания такой функции обработчика ошибок или замыкания.

Во-вторых, я не возражаю против того, что встроенная функция может вызвать возврат функции, но, если немного пошутить, имя «попытка» слишком короткое, чтобы предположить, что оно может вызвать возврат. Так что более длинное имя, например, attempt , мне кажется лучше.

РЕДАКТИРОВАТЬ: В-третьих, в идеале, язык go должен сначала получить дженерики, где важным вариантом использования будет возможность реализовать эту функцию try как дженерик, чтобы можно было закончить байкшединг, и каждый мог получить обработку ошибок, которую они предпочитают сами.

Хакерские новости имеют определенный смысл: try не ведет себя как обычная функция (она может возвращать значение), поэтому нехорошо придавать ей синтаксис, подобный функции. Синтаксис return или defer был бы более подходящим:

func CopyFile(src, dst string) (err error) {
        r := try os.Open(src)
        defer r.Close()

        w := try os.Create(dst)
        defer func() {
                w.Close()
                if err != nil {
                        os.Remove(dst) // only if a “try” fails
                }
        }()

        try io.Copy(w, r)
        try w.Close()
        return nil
}

@sheerun общий контраргумент этому заключается в том, что panic также является встроенной функцией изменения потока управления. Лично я с этим не согласен, но это правильно.

1. Вторя @deanveloper выше , а также аналогичные комментарии других, я очень боюсь, что мы недооцениваем затраты на добавление нового, несколько тонкого и, особенно когда он встроен в другие вызовы функций, легко упускаемого из виду ключевого слова, которое управляет управлением стеком вызовов. поток. panic(...) — относительно явное исключение (каламбур) из правила, согласно которому return — единственный выход из функции. Я не думаю, что мы должны использовать его существование как оправдание для добавления третьего.
2. Это предложение канонизировало бы возврат необработанной ошибки как поведение по умолчанию, а ошибки упаковки считали бы чем-то, на что вы должны согласиться, с дополнительной церемонией. Но, по моему опыту, это прямо противоположно хорошей практике. Я надеюсь, что предложение в этой области упростит или, по крайней мере, не усложнит добавление контекстной информации к ошибкам на месте ошибки.

возможно, мы можем добавить вариант с дополнительной функцией увеличения, что-то вроде tryf с этой семантикой:

func tryf(t1 T1, t1 T2, … tn Tn, te error, fn func(error) error) (T1, T2, … Tn)

переводит это

x1, x2, … xn = tryf(f(), func(err error) { return fmt.Errorf("foobar: %q", err) })

в это

t1, … tn, te := f()
if te != nil {
    if fn != nil {
        te = fn(te)
    }
    err = te
    return
}

поскольку это явный выбор (вместо использования try ), мы можем найти разумные ответы на вопросы в более ранней версии этого дизайна. например, если функция увеличения равна нулю, ничего не делайте и просто верните исходную ошибку.

Я обеспокоен тем, что try заменит традиционную обработку ошибок и в результате затруднит аннотирование путей ошибок.

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

a, b, err := doWork()
if err != nil {
  updateCounters()
  writeLogs()
  return err
}

Go — чрезвычайно социальный язык с общими идиомами, усиленными инструментами (fmt, lint и т. д.). Пожалуйста, имейте в виду социальные последствия этой идеи - будет тенденция использовать ее повсюду.

@politician , извините, но слово, которое вы ищете, не _социальный_, а _самоуверенный_. Go — самоуверенный язык программирования. В остальном я в основном согласен с тем, к чему вы клоните.

Инструменты сообщества @beoran , такие как Godep и различные линтеры, демонстрируют, что Go является одновременно самоуверенным и социальным, и многие драмы с языком проистекают из этой комбинации. Надеюсь, мы оба согласимся, что try не должна стать следующей дорамой.

@politician Спасибо за разъяснение, я не так понял. Я, конечно, могу согласиться с тем, что мы должны стараться избегать драмы.

Я в замешательстве.

Из блога: Ошибки — это ценности , с моей точки зрения, они предназначены для того, чтобы их ценили, а не игнорировали.

И я верю тому, что сказал Роп Пайк: «Ценности можно запрограммировать, а поскольку ошибки — это ценности, ошибки можно запрограммировать».

Мы не должны рассматривать error как exception , это похоже на импорт сложности не только для мышления, но и для кодирования, если мы это делаем.

«Используйте язык, чтобы упростить обработку ошибок». -- Роб Пайк

И еще, мы можем просмотреть этот слайд

Одна из ситуаций, когда проверка ошибок с помощью if кажется мне особенно неудобной, — это закрытие файлов (например, в NFS). Я думаю, в настоящее время мы должны написать следующее, возможны ли возвраты ошибок из .Close() ?

r, err := os.Open(src)
if err != nil {
    return err
}
defer func() {
    // maybe check whether a previous error occured?
    return r.Close()
}()

Может ли defer try(r.Close()) быть хорошим способом иметь управляемый синтаксис для обработки таких ошибок? По крайней мере, имело бы смысл как-то скорректировать пример CopyFile() в предложении, чтобы не игнорировать ошибки из r.Close() и w.Close() .

@seehuhn Ваш пример не скомпилируется, потому что отложенная функция не имеет возвращаемого типа.

func doWork() (err error) {
  r, err := os.Open(src)
  if err != nil {
    return err
  }
  defer func() {
    err = r.Close()  // overwrite the return value
  }()
}

Будет работать так, как вы ожидаете. Ключ — это именованное возвращаемое значение.

Мне нравится это предложение, но я думаю, что следует рассмотреть и пример @seehuhn :

defer try(w.Close())

вернет ошибку из Close() только в том случае, если ошибка еще не была установлена.
Этот шаблон используется так часто...

Я согласен с опасениями по поводу добавления контекста к ошибкам. Я считаю это одной из лучших практик, которая делает сообщения об ошибках более удобными (и понятными) и упрощает процесс отладки.

Первое, о чем я подумал, это заменить fmt.HandleErrorf tryf , которая ставит перед ошибкой дополнительный контекст.

func tryf(t1 T1, t1 T2, … tn Tn, te error, ts string) (T1, T2, … Tn)

Например (из реального кода, который у меня есть):

func (c *Config) Build() error {
    pkgPath, err := c.load()
    if err != nil {
        return nil, errors.WithMessage(err, "load config dir")
    }
    b := bytes.NewBuffer(nil)
    if err = templates.ExecuteTemplate(b, "main", c); err != nil {
        return nil, errors.WithMessage(err, "execute main template")
    }
    buf, err := format.Source(b.Bytes())
    if err != nil {
        return nil, errors.WithMessage(err, "format main template")
    }
    target := fmt.Sprintf("%s.go", filename(pkgPath))
    if err := ioutil.WriteFile(target, buf, 0644); err != nil {
        return nil, errors.WithMessagef(err, "write file %s", target)
    }
    // ...
}

Можно изменить на что-то вроде:

func (c *Config) Build() error {
    pkgPath := tryf(c.load(), "load config dir")
    b := bytes.NewBuffer(nil)
    tryf(emplates.ExecuteTemplate(b, "main", c), "execute main template")
    buf := tryf(format.Source(b.Bytes()), "format main template")
    target := fmt.Sprintf("%s.go", filename(pkgPath))
    tryf(ioutil.WriteFile(target, buf, 0644), fmt.Sprintf("write file %s", target))
    // ...
}

Или, если я возьму пример @agnivade :

func (p *pgStore) DoWork() (err error) {
    tx := tryf(p.handle.Begin(), "begin transaction")
        defer func() {
        if err != nil {
            tx.Rollback()
        }
    }()
    var res int64
    tryf(tx.QueryRow(`INSERT INTO table (...) RETURNING c1`, ...).Scan(&res), "insert table")
    _, = tryf(tx.Exec(`INSERT INTO table2 (...) VALUES ($1)`, res), "insert table2")
    return tryf(tx.Commit(), "commit transaction")
}

Однако @josharian поднял хороший вопрос, который заставляет меня сомневаться в этом решении:

Однако, как написано, форматирование в стиле fmt перемещается из пакета в сам язык, что открывает банку червей.

Я полностью согласен с этим предложением и вижу его преимущества на ряде примеров.

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

Для меня я бы предпочел, чтобы встроенная функция называлась pass . Я чувствую, что это дает лучшее представление о том, что происходит. В конце концов, вы не обрабатываете ошибку, а передаете ее обратно вызывающей стороне. try создает впечатление, что ошибка была обработана.

Я не согласен с этим, главным образом потому, что проблема, которую он призван решать («шаблонные операторы if, обычно связанные с обработкой ошибок»), просто не является проблемой для меня. Если бы все проверки ошибок были просто if err != nil { return err } , то я мог бы увидеть некоторую ценность в добавлении синтаксического сахара для этого (хотя Go по своей склонности является относительно свободным от сахара языком).

На самом деле то, что я хочу сделать в случае ненулевой ошибки, довольно сильно варьируется от одной ситуации к другой. Может быть, я хочу t.Fatal(err) . Может быть, я хочу добавить украшающее сообщение return fmt.Sprintf("oh no: %v", err) . Может быть, я просто регистрирую ошибку и продолжаю. Может быть, я устанавливаю флаг ошибки на своем объекте SafeWriter и продолжаю, проверяя флаг в конце какой-то последовательности операций. Возможно, мне нужно предпринять какие-то другие действия. Ни один из них нельзя автоматизировать с помощью try . Поэтому, если аргумент в пользу try заключается в том, что он удалит все блоки if err != nil , этот аргумент не имеет силы.

Устранит ли это _some_ из них? Конечно. Это привлекательное предложение для меня? Мех. Я искренне не беспокоюсь. Для меня if err != nil — это просто часть Go, как фигурные скобки или defer . Я понимаю, что это выглядит многословным и повторяющимся для людей, которые плохо знакомы с Go, но люди, которые плохо знакомы с Go, не в лучшем положении, чтобы вносить кардинальные изменения в язык по целому ряду причин.

Планка для существенных изменений в Go традиционно заключалась в том, что предлагаемое изменение должно решить проблему, которая (A) значительна, (B) затрагивает множество людей и (C) хорошо решается предложением. Я не убежден ни по одному из этих трех критериев. Я вполне доволен обработкой ошибок Go как таковой.

Повторяя @peterbourgon и @deanveloper , одна из моих любимых особенностей Go заключается в том, что поток кода ясен, а panic() не рассматривается как стандартный механизм управления потоком, как в Python.

Что касается дебатов о панике, panic() почти всегда появляется в строке сам по себе, потому что он не имеет значения. Вы не можете fmt.Println(panic("oops")) . Это значительно увеличивает его видимость и делает его гораздо менее сравнимым с try() , чем люди думают.

Если должна быть другая конструкция управления потоком для функций, я бы предпочел, чтобы это был оператор, который гарантированно будет крайним левым элементом в строке.

Один из примеров в предложении решает проблему для меня:

func printSum(a, b string) error {
        fmt.Println(
                "result:",
                try(strconv.Atoi(a)) + try(strconv.Atoi(b)),
        )
        return nil
}

Поток управления действительно становится менее очевидным и очень скрытым.

Это также противоречит первоначальному замыслу Роба Пайка, согласно которому все ошибки должны обрабатываться явно.

Хотя реакция на это может быть «тогда не используйте это», проблема в том, что другие библиотеки будут использовать это, и их отладка, чтение и использование становятся более проблематичными. Это побудит мою компанию никогда не переходить на go 2 и начать использовать только библиотеки, которые не используют try . Если я не одинок с этим, это может привести к разделению а-ля питон 2/3.

Кроме того, имя try автоматически подразумевает, что в конце концов catch появится в синтаксисе, и мы снова станем Java.

Итак, из-за всего этого я _категорически_ против этого предложения.

Мне не нравится имя try . Это подразумевает _попытку_ сделать что-то с высоким риском неудачи (у меня может быть культурное предубеждение против _попытки_, поскольку я не являюсь носителем английского языка), в то время как вместо этого будет использоваться try в случае, если мы ожидаем редких неудач. (мотивация желания уменьшить многословность обработки ошибок) и настроены оптимистично. Кроме того, try в этом предложении фактически _перехватывает_ ошибку, чтобы вернуть ее раньше. Мне нравится предложение pass от @HiImJC.

Помимо имени, я нахожу неудобным иметь return -подобный оператор, теперь спрятанный в середине выражений. Это нарушает стиль потока Go. Это усложнит проверку кода.

В общем, я считаю, что это предложение принесет пользу только ленивому программисту, у которого теперь есть оружие для более короткого кода и еще меньше причин прилагать усилия для оборачивания ошибок. Поскольку это также усложнит обзоры (возврат в середине выражения), я думаю, что это предложение идет вразрез с целью «программирования в масштабе» Go.

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

Мне нравится это предложение в целом. Взаимодействие с defer кажется достаточным, чтобы обеспечить эргономичный способ возврата ошибки, а также добавить дополнительный контекст. Хотя было бы неплохо решить проблему, на которую @josharian указал, как включить исходную ошибку в завернутое сообщение об ошибке.

Чего не хватает, так это эргономичного способа взаимодействия с предложениями по проверке ошибок на столе. Я считаю, что API должны очень внимательно относиться к тому, какие типы ошибок они возвращают, и по умолчанию, вероятно, должно быть «возвращаемые ошибки никоим образом не поддаются проверке». Затем должно быть легко перейти в состояние, в котором ошибки могут быть проверены точным образом, как задокументировано сигнатурой функции («Она сообщает об ошибке вида X в обстоятельстве A и ошибке вида Y в обстоятельстве B»).

К сожалению, на данный момент это предложение делает самый эргономичный вариант самым нежелательным (для меня); слепое прохождение через произвольные виды ошибок. Я думаю, что это нежелательно, потому что побуждает не думать о типах ошибок, которые вы возвращаете, и о том, как пользователи вашего API будут их использовать. Дополнительное удобство этого предложения, безусловно, приятно, но я боюсь, что оно будет способствовать плохому поведению, потому что предполагаемое удобство перевешивает предполагаемую ценность тщательного обдумывания того, какую информацию об ошибках вы предоставляете (или пропускаете).

Повязка была бы, если бы ошибки, возвращаемые try , были бы преобразованы в ошибки, которые не являются "разворачиваемыми". К сожалению, это также имеет довольно серьезные недостатки, поскольку делает так, что любой defer не может сам проверять ошибки. Кроме того, это предотвращает использование, когда try на самом деле возвращает ошибку желаемого типа (то есть случаи использования, когда try используется осторожно, а не небрежно).

Другим решением было бы перепрофилировать (отброшенную) идею наличия необязательного второго аргумента в try для определения/внесения в белый список типов ошибок, которые могут быть возвращены с этого сайта. Это немного проблематично, потому что у нас есть два разных способа определения «типа ошибки»: либо по значению ( io.EOF и т. д.), либо по типу ( *os.PathError , *exec.ExitError ). Легко указать типы ошибок, которые являются значениями, в качестве аргументов функции, но сложнее указать типы. Не уверен, как с этим справиться, но выбрасываю идею.

Проблему, на которую указал @josharian , можно избежать, отложив оценку ошибки:

defer func() { fmt.HandleErrorf(&err, "oops: %v", err) }()

Выглядит не очень, но должно работать. Однако я бы предпочел, чтобы это можно было решить, добавив новый глагол/флаг форматирования для указателей ошибок или, может быть, для указателей в целом, который печатает разыменованное значение, как с обычным %v . Для примера назовем его %*v :

defer fmt.HandleErrorf(&err, "oops: %*v", &err)

Помимо загвоздки, я думаю, что это предложение выглядит многообещающе, но кажется крайне важным держать под контролем эргономику добавления контекста к ошибкам.

Редактировать:

Другой подход заключается в заключении указателя ошибки в структуру, реализующую Stringer :

type wraperr struct{ err *error }
func (w wraperr) String() string { return (*w.err).Error() }

...

defer handleErrorf(&err, "oops: %v", wraperr{&err})

Пара вещей с моей точки зрения. Почему мы так озабочены сохранением нескольких строк кода? Я рассматриваю это в том же духе, что и малые функции, которые считаются вредными .

Кроме того, я считаю, что такое предложение снимает ответственность за правильную обработку ошибки с некоторой «волшебной силой», которая, как я беспокоюсь, будет просто злоупотреблять и поощрять лень, приводящую к плохому качеству кода и ошибкам.

Предложение, как указано, также имеет ряд неясных поведений, так что это уже проблематично, чем _explicit_ дополнительные ~3 строки, которые более понятны.

В настоящее время мы экономно используем шаблон отсрочки дома. Здесь есть статья, которая вызвала столь же неоднозначную реакцию, когда мы ее писали — https://bet365techblog.com/better-error-handling-in-go .

Однако мы использовали его в ожидании продвижения предложения check / handle .

Check/handle был гораздо более комплексным подходом к упрощению обработки ошибок. Его блок handle сохранил ту же область действия функции, что и та, в которой он был определен, в то время как любые операторы defer представляют собой новые контексты с некоторым объемом накладных расходов. Это, казалось, больше соответствовало идиомам go, в том смысле, что если вы хотите, чтобы поведение «просто возвращало ошибку, когда она возникает», вы могли объявить это явно как handle { return err } .

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

try , в данном случае, похоже, не слишком много решает, и я разделяю те же опасения, что и другие, что это просто приведет к ленивым реализациям или тем, которые чрезмерно используют шаблон отсрочки.

Если обработка ошибок на основе отсрочки будет A Thing, то, вероятно, следует добавить что-то вроде этого в пакет ошибок:

        f := try(os.Create(filename))
        defer errors.Deferred(&err, f.Close)

Игнорирование ошибок отложенных операторов Close — довольно распространенная проблема. Должен быть стандартный инструмент, чтобы помочь с этим.

Встроенная функция, которая возвращает результат, сложнее продать, чем ключевое слово, которое делает то же самое.
Я бы хотел, чтобы это было ключевое слово, как в Zig[1].

1. https://ziglang.org/documentation/master/#try

Встроенные функции, сигнатура типа которых не может быть выражена с помощью системы типов языка, и чье поведение искажает то, чем функция обычно является, просто кажутся спасательным люком, который можно использовать многократно, чтобы избежать реальной эволюции языка.

Мы привыкли сразу распознавать операторы возврата (и паники), потому что именно так этот тип потока управления выражается в Go (и многих других языках). Кажется невероятным, что мы также будем распознавать try как изменение потока управления после некоторого привыкания к нему, точно так же, как мы это делаем для return. Не сомневаюсь, что и в этом поможет хорошая поддержка IDE.

Я думаю, что это довольно надумано. В коде, созданном с помощью gofmt, return всегда соответствует /^\t*return / — это очень простой шаблон, который можно обнаружить на глаз без посторонней помощи. try , с другой стороны, может встречаться в любом месте кода, вложенного произвольно глубоко в вызовы функций. Никакое обучение не позволит нам сразу определить весь поток управления в функции без помощи инструментов.

Кроме того, функция, которая зависит от "хорошей поддержки IDE", будет иметь недостатки во всех средах, где нет хорошей поддержки IDE. Сразу приходят на ум инструменты проверки кода — Геррит выделит для меня все попытки? А что насчет людей, которые по разным причинам решили не использовать IDE или причудливую подсветку кода? Начнет ли acme выделять try ?

Языковая функция должна быть проста для понимания сама по себе, а не зависеть от поддержки редактора.

@kungfusheep Мне нравится эта статья. Забота о переносе в один только отложенный код уже немного повышает читабельность без try .

Я нахожусь в лагере, который не считает ошибки в Go действительно проблемой. Тем не менее, if err != nil { return err } может сильно тормозить в некоторых функциях. Я писал функции, которые требовали проверки ошибок почти после каждого оператора, и ни одна из них не требовала какой-либо специальной обработки, кроме переноса и возврата. Иногда просто нет умной структуры Buffer, которая сделает вещи лучше. Иногда это просто один критический шаг за другим, и вам нужно просто закоротить, если что-то пошло не так.

Хотя try , безусловно, сделал бы этот код намного более удобным для чтения, будучи полностью обратно совместимым, я согласен с тем, что try не является критически важной функцией, поэтому, если люди слишком боятся может быть, лучше его не иметь.

Хотя семантика вполне ясна. Каждый раз, когда вы видите try , он либо следует счастливому пути, либо возвращается. Я действительно не могу быть проще, чем это.

Это похоже на специальный макрос.

@dominikh try всегда соответствует /try\(/ , поэтому я не знаю, о чем вы на самом деле говорите. Он одинаково доступен для поиска, и каждый редактор, о котором я когда-либо слышал, имеет функцию поиска.

@qrpnxz Я думаю, что смысл, который он пытался донести, не в том, что вы не можете искать его программно, а в том, что его сложнее искать глазами. Регулярное выражение было просто аналогией с акцентом на /^\t* , что означает, что все возвращаемые значения явно выделяются тем, что находятся в начале строки (игнорируя начальные пробелы).

Если подумать, должно быть несколько общих вспомогательных функций. Возможно, они должны быть в пакете под названием «отложенный».

Обращаясь к предложению для check с форматом, чтобы избежать именования возврата, вы можете просто сделать это с помощью функции, которая проверяет ноль, например так

func Format(err error, message string, args ...interface{}) error {
    if err == nil {
        return nil
    }
    return fmt.Errorf(...)
}

Это можно использовать без именованного возврата, например:

func foo(s string) (int, error) {
    n, err := strconv.Atoi(s)
    try(deferred.Format(err, "bad string %q", s))
    return n, nil
}

Вместо этого предлагаемый fmt.HandleError можно поместить в отложенный пакет, а мою вспомогательную функцию error.Defer можно назвать deferred.Exec , и может быть условный exec для выполнения процедур, только если ошибка не равна нулю.

Собрав это вместе, вы получите что-то вроде

func CopyFile(src, dst string) (err error) {
    defer deferred.Annotate(&err, "copy %s %s", src, dst)

    r := try(os.Open(src))
    defer deferred.Exec(&err, r.Close)

    w := try(os.Create(dst))
    defer deferred.Exec(&err, r.Close)

    defer deferred.Cond(&err, func(){ os.Remove(dst) })
    try(io.Copy(w, r))

    return nil
}

Другой пример:

func (p *pgStore) DoWork() (err error) {
    tx := try(p.handle.Begin())

    defer deferred.Cond(&err, func(){ tx.Rollback() })

    var res int64 
    err = tx.QueryRow(`INSERT INTO table (...) RETURNING c1`, ...).Scan(&res)
    try(deferred.Format(err, "insert table")

    _, err = tx.Exec(`INSERT INTO table2 (...) VALUES ($1)`, res)
    try(deferred.Format(err, "insert table2"))

    return tx.Commit()
}

Это предложение ведет нас от того, чтобы везде иметь if err != nil , к тому, чтобы везде было try . Он сдвигает предложенную проблему и не решает ее.

Хотя я бы сказал, что текущий механизм обработки ошибок не является проблемой для начала. Нам просто нужно улучшить инструментарий и проверить его.

Кроме того, я бы сказал, что if err != nil на самом деле более удобочитаем, чем try , потому что он не загромождает строку языка бизнес-логики, а находится прямо под ней:

file := try(os.OpenFile("thing")) // less readable than, 

file, err := os.OpenFile("thing")
if err != nil {

}

И если Go должен был быть более волшебным в обработке ошибок, почему бы просто не завладеть им полностью. Например, Go может неявно вызывать встроенную функцию try , если пользователь не назначает ошибку. Например:

func getString() (string, error) { ... }

func caller() {
  defer func() {
    if err != nil { ... } // whether `err` must be defined or not is not shown in this example. 
  }

  // would call try internally, because a user is not 
  // assigning an error value. Also, it can add a compile error
  // for "defined and not used err value" if the user does not 
  // handle the error. 
  str := getString()
}

Для меня это на самом деле решило бы проблему избыточности за счет магии и потенциальной читабельности.

Поэтому я предлагаю либо действительно решить «проблему», как в приведенном выше примере, либо сохранить текущую обработку ошибок, но вместо изменения языка для устранения избыточности и переноса мы не меняем язык, а улучшаем инструментарий и проверку . кода, чтобы сделать опыт лучше.

Например, в VSCode есть фрагмент под названием iferr , если вы наберете его и нажмете Enter, он расширится до полной инструкции по обработке ошибок... поэтому написание его никогда не кажется мне утомительным, а чтение позже лучше .

@джошариан

Хотя это не будет «скромным изменением в библиотеке», мы могли бы принять и ошибку func main().

Проблема в том, что не все платформы имеют четкую семантику того, что это значит. Ваше переписывание хорошо работает в «традиционных» программах Go, работающих в полной операционной системе, но как только вы пишете прошивку микроконтроллера или даже просто WebAssembly, не очень ясно, что будет означать os.Exit(1) . В настоящее время os.Exit является библиотечным вызовом, поэтому реализации Go бесплатны только для того, чтобы не предоставлять его. Однако форма main связана с языком.

Вопрос о предложении, на который, вероятно, лучше всего ответить «нет»: как try взаимодействует с вариативными аргументами? Это первый случай функции с переменным числом переменных, у которой нет своих переменных в последнем аргументе. Разрешено ли это:

var e []error
try(e...)

Не говоря уже о том, почему ты это сделал. Я подозреваю, что ответ будет «нет» (иначе продолжением будет «что, если длина расширенного фрагмента равна 0»). Просто упомянул об этом, чтобы в конечном итоге иметь в виду при формулировке спецификации.

• Некоторые из замечательных особенностей Go заключаются в том, что текущие встроенные функции обеспечивают четкий поток управления, явная и поощряемая обработка ошибок, а разработчикам настоятельно не рекомендуется писать «волшебный» код. Предложение try не согласуется с этими основными принципами, поскольку оно будет способствовать сокращению за счет удобочитаемости потока управления.
• Если это предложение будет принято, то, возможно, стоит подумать о том, чтобы сделать встроенный оператор try вместо функции . Затем он более совместим с другими операторами потока управления, такими как if . Кроме того, удаление вложенных скобок незначительно улучшает читаемость.
• Опять же, если предложение будет принято, то, возможно, реализовать его без использования defer или чего-то подобного. Его уже нельзя реализовать в чистом виде (как указывали другие), поэтому он может также использовать более эффективную реализацию под капотом.

Я вижу в этом две проблемы:

1. Он помещает МНОГО кода, вложенного в функции. Это добавляет много дополнительной когнитивной нагрузки, пытаясь разобрать код у себя в голове.

1. Это дает нам места, где код может выйти из середины оператора.

Номер 2, я думаю, намного хуже. Все приведенные здесь примеры — это простые вызовы, которые возвращают ошибку, но вот что гораздо коварнее:

func doit(abc string) error {
    a := fmt.Sprintf("value of something: %s\n", try(getValue(abc)))
    log.Println(a)
    return nil
}

Этот код может выйти в середине этого sprintf, и будет СУПЕР легко пропустить этот факт.

Мой голос - нет. Это не улучшит код go. Это не облегчит чтение. Это не сделает его крепче.

Я говорил это раньше, и это предложение иллюстрирует это — я чувствую, что 90% жалоб на Go — это «я не хочу писать оператор if или цикл». Это убирает некоторые очень простые операторы if, но добавляет когнитивную нагрузку и позволяет легко пропустить точки выхода для функции.

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

func main() {
    f := try(os.Open("foo.txt"))
    defer f.Close()
}

Я не уверен, что попытка паники в main будет приемлемой.

Кроме того, это не было бы особенно полезно в тестах ( func TestFoo(t* testing.T) ), что, к сожалению, :(

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

Я бы предпочел что-то вроде try/catch, которое может выглядеть как

Предполагая, что foo() определяется как

func foo() (int, error) {}

Затем вы могли бы сделать

n := try(foo()) {
    case FirstError:
        // do something based on FirstError
    case OtherError:
        // do something based on OtherError
    default:
        // default behavior for any other error
}

Что переводится как

n, err := foo()
if errors.Is(err, FirstError) {
    // do something based on FirstError
if errors.Is(err, OtherError) {
    // do something based on OtherError
} else {
    // default behavior for any other error
}

Для меня обработка ошибок — одна из самых важных частей кодовой базы.
Уже слишком много кода go if err != nil { return err } , который возвращает ошибку из глубины стека без добавления дополнительного контекста или даже (возможно) хуже, добавляя контекст, маскируя основную ошибку оберткой fmt.Errorf .

Предоставление нового ключевого слова, которое является своего рода волшебством, которое ничего не делает, кроме замены if err != nil { return err } , кажется опасным путем.
Теперь весь код будет просто обернут вызовом try. Это несколько нормально (хотя читабельность отстой) для кода, который имеет дело только с ошибками внутри пакета, такими как:

func foo() error {
  /// stuff
  try(bar())
  // more stuff
}

Но я бы сказал, что данный пример действительно ужасен и в основном оставляет вызывающего абонента, пытающегося понять ошибку, которая действительно глубоко в стеке, очень похоже на обработку исключений.
Конечно, здесь все зависит от разработчика, чтобы поступить правильно, но это дает разработчику отличный способ не заботиться о своих ошибках, возможно, с фразой «мы исправим это позже» (и мы все знаем, как это происходит). ).

Я хотел бы, чтобы мы посмотрели на проблему с другой точки зрения, чем "как мы можем уменьшить повторение" и больше о "как мы можем сделать (правильную) обработку ошибок более простой и продуктивной для разработчиков".
Мы должны подумать о том, как это повлияет на выполнение производственного кода.

*Примечание: на самом деле это не уменьшает количество повторений, а просто изменяет то, что повторяется, при этом делая код менее читаемым, потому что все заключено в try() .

И последнее замечание: чтение предложения сначала кажется приятным, затем вы начинаете разбираться со всеми подводными камнями (по крайней мере, перечисленными), и это просто как «ок, да, это слишком».

Я понимаю, что многое из этого субъективно, но это то, что меня волнует. Эта семантика невероятно важна.
То, что я хочу увидеть, — это способ упростить написание и поддержку кода производственного уровня, чтобы вы могли также делать ошибки «правильно» даже для кода уровня POC/демо.

Поскольку контекст ошибки кажется повторяющейся темой...

Гипотеза: большинство функций Go возвращают (T, error) , а не (T1, T2, T3, error)

Что, если вместо определения try как try(T1, T2, T3, error) (T1, T2, T3) мы определили его как
try(func (args) (T1, T2, T3, error))(T1, T2, T3) ? (это приблизительно)

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

Затем, подобно make , открывается дверь к форме вызова с двумя аргументами, где второй аргумент является контекстом попытки (например, фиксированная строка, строка с %v ).

Это по-прежнему позволяет создавать цепочки для случая (T, error) , но вы больше не можете связывать несколько возвратов, что обычно не требуется IMO.

@ cpuguy83 cpuguy83 Если вы прочитаете предложение, вы увидите, что ничто не мешает вам завернуть ошибку. На самом деле есть несколько способов сделать это, используя try . Хотя многие почему-то так считают.

if err != nil { return err } — это то же самое, что «мы исправим это позже», как и try , за исключением того, что это более раздражает при прототипировании.

Я не знаю, как то, что находится внутри пары скобок, менее читабельно, чем шаги функции, расположенные через каждые четыре строки шаблона.

Было бы неплохо, если бы вы указали на некоторые из этих конкретных «ошибок», которые беспокоили вас, поскольку это тема.

Читабельность кажется проблемой, но как насчет того, чтобы go fmt представила try() так, чтобы он выделялся, например:

f := try(
    os.Open("file.txt")
)

@MrTravisB

Проблема, с которой я столкнулся, заключается в том, что вы всегда хотите просто вернуть ошибку, когда это произойдет.

Я не согласен. Предполагается, что вы хотите делать это достаточно часто, чтобы гарантировать сокращение именно для этого. Если вы этого не сделаете, это не помешает явно обрабатывать ошибки.

Когда, возможно, вы хотите добавить контекст к ошибке и вернуть ее, или, может быть, вы просто хотите вести себя по-другому, когда происходит ошибка.

В предложении описывается шаблон добавления к ошибкам блочного контекста. @josharian указал, что в примерах есть ошибка, и неясно, как лучше всего ее избежать. Я написал пару примеров того, как с этим справиться.

Для более конкретного контекста ошибки, опять же, try делает что-то, и если вам это не нужно, не используйте try .

@boomlinde Совершенно верно . Это предложение пытается решить отдельный вариант использования, а не предоставляет инструмент для решения более крупной проблемы обработки ошибок. Я думаю, что основной вопрос, если именно то, что вы указали.

Предполагается, что вы хотите делать это достаточно часто, чтобы гарантировать сокращение именно для этого.

По моему мнению и опыту, этот вариант использования составляет небольшое меньшинство и не требует сокращенного синтаксиса.

Кроме того, подход с использованием defer для обработки ошибок имеет проблемы, поскольку предполагает, что вы хотите обрабатывать все возможные ошибки одинаково. Операторы defer не могут быть отменены.

defer fmt.HandleErrorf(&err, “foobar”)

n := try(foo())

x : try(foo2())

Что, если мне нужна другая обработка ошибок, которые могут быть возвращены из foo() против foo2() ?

@MrTravisB

Что, если мне нужна другая обработка ошибок, которые могут быть возвращены из foo() по сравнению с foo2()?

Тогда вы используете что-то еще. Это то, к чему стремился @boomlinde .

Возможно, вы нечасто сталкиваетесь с этим вариантом использования, но многие люди его видят, и добавление try на вас особо не повлияет. На самом деле, чем реже используется вариант использования, тем меньше на вас влияет добавление try .

@qrpnxz

f := try(os.Open("/foo"))
data := try(ioutil.ReadAll(f))
try(send(data))

(да я понимаю там ReadFile и что конкретно этот пример не лучший способ копировать данные куда-то, не в этом дело)

Это требует больше усилий для чтения, потому что вам нужно разобрать встроенную попытку. Логика приложения заключена в другом вызове.
Я также утверждаю, что обработчик ошибок defer здесь не годится, за исключением того, что он просто обертывает ошибку новым сообщением... что хорошо, но обработка ошибок заключается не только в том, чтобы упростить ее для пользователя. человек, чтобы прочитать, что произошло.

По крайней мере, в ржавчине оператор представляет собой постфикс ( ? , добавленный в конец вызова), который не создает дополнительной нагрузки для выкапывания фактической логики.

Управление потоком на основе выражений

panic может быть еще одной функцией управления потоком, но она не возвращает значения, что фактически делает ее оператором. Сравните это с выражением try , которое может встречаться где угодно.

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

Я думаю, что эти точки означают, что try значительно усложняет отслеживание потока управления, чего у нас не было раньше, как было указано ранее, но я не видел различия между операторами и выражениями. указал.

Другое предложение

Разрешить такие заявления, как

if err != nil {
    return nil, 0, err
}

для форматирования одной строки на gofmt , когда блок содержит только оператор return , и этот оператор не содержит новых строк. Например:

if err != nil { return nil, 0, err }

Обоснование

• Не требует изменений языка
• Правило форматирования простое и понятное
• Правило может быть разработано таким образом, чтобы в нем gofmt сохраняло новые строки, если они уже существуют (например, структурные литералы). Выбор также позволяет писателю сделать акцент на некоторых обработках ошибок.
• Если это не так, код может быть автоматически перенесен в новый стиль с помощью вызова gofmt
• Это только для операторов return , так что это не будет злоупотреблять кодом для гольфа без необходимости.
• Хорошо взаимодействует с комментариями, описывающими, почему могут возникать некоторые ошибки и почему они возвращаются. Использование множества вложенных выражений try плохо справляется с этой задачей.
• Это уменьшает вертикальное пространство обработки ошибок на 66%.
• Поток управления без выражений
• Код читается гораздо чаще, чем пишется, поэтому его следует оптимизировать для читателя. Повторяющийся код, занимающий меньше места, полезен для читателя, тогда как try больше ориентирован на автора.
• Люди уже предлагали try , существующие на нескольких линиях. Например, этот комментарий или этот комментарий , который вводит такой стиль, как

f, err := os.Open(file)
try(maybeWrap(err))

• Стиль "попробовать на своей строке" устраняет любую двусмысленность в отношении того, какое значение err возвращается. Поэтому я подозреваю, что эта форма будет широко использоваться. Разрешение одного выровненного блока if - это почти то же самое, за исключением того, что в нем также явно указано, какие возвращаемые значения
• Это не способствует использованию именованных возвратов или неясной упаковки на основе defer . Оба повышают барьер для ошибок переноса, а первый может потребовать изменений godoc
• Нет необходимости обсуждать, когда использовать try по сравнению с традиционной обработкой ошибок.
• Не исключает выполнения try или чего-то еще в будущем. Изменение может быть положительным, даже если try принимается
• Нет отрицательного взаимодействия с библиотекой testing или функциями main . На самом деле, если предложение допускает любой однострочный оператор вместо простого возврата, это может уменьшить использование библиотек, основанных на утверждениях. Рассмотреть возможность

value, err := something()
if err != nil { t.Fatal(err) }

• Нет негативного взаимодействия с проверкой конкретных ошибок. Рассмотреть возможность

n, err := src.Read(buf)
if err == io.EOF { return nil }
else if err != nil { return err }

Подводя итог, можно сказать, что это предложение имеет небольшую стоимость, может быть спроектировано так, чтобы его можно было выбрать, не исключает каких-либо дальнейших изменений, поскольку оно чисто стилистическое, и уменьшает боль от чтения подробного кода обработки ошибок, сохраняя при этом все явное. Я думаю, что это следует рассматривать как первый шаг, прежде чем идти ва-банк на try .

Из https://github.com/golang/go/issues/32437#issuecomment-498941435

с попыткой

func NewThing(thingy *foo.Thingy, db *sql.DB, client pb.Client) (*Thing, error) {
        try(dbfile.RunMigrations(db, dbMigrations))
        t := &Thing{
                thingy:  thingy,
                scanner: try(newScanner(thingy, db, client)),
        }
        t.initOtherThing()
        return t, nil
}

С этим

func NewThing(thingy *foo.Thingy, db *sql.DB, client pb.Client) (*Thing, error) {
        err := dbfile.RunMigrations(db, dbMigrations))
        if err != nil { return nil, fmt.Errorf("running migrations: %v", err) }

        t := &Thing{thingy: thingy}
        t.scanner, err = newScanner(thingy, db, client)
        if err != nil { return nil, fmt.Errorf("creating scanner: %v", err) }

        t.initOtherThing()
        return t, nil
}

Он конкурентоспособен в использовании пространства, но при этом позволяет добавлять контекст к ошибкам.

Из https://github.com/golang/go/issues/32437#issuecomment-499007288

с попыткой

func (c *Config) Build() error {
    pkgPath := try(c.load())
    b := bytes.NewBuffer(nil)
    try(emplates.ExecuteTemplate(b, "main", c))
    buf := try(format.Source(b.Bytes()))
    target := fmt.Sprintf("%s.go", filename(pkgPath))
    try(ioutil.WriteFile(target, buf, 0644))
    // ...
}

С этим

func (c *Config) Build() error {
    pkgPath, err := c.load()
    if err != nil { return nil, errors.WithMessage(err, "load config dir") }

    b := bytes.NewBuffer(nil)
    err = templates.ExecuteTemplate(b, "main", c)
    if err != nil { return nil, errors.WithMessage(err, "execute main template") }

    buf, err := format.Source(b.Bytes())
    if err != nil { return nil, errors.WithMessage(err, "format main template") }

    target := fmt.Sprintf("%s.go", filename(pkgPath))
    err = ioutil.WriteFile(target, buf, 0644)
    if err != nil { return nil, errors.WithMessagef(err, "write file %s", target) }
    // ...
}

В исходном комментарии использовалось гипотетическое tryf для прикрепления форматирования, которое было удалено. Неясно, как лучше всего добавить все различные контексты, и, возможно, try даже неприменим.

@cpuguy83
Для меня это более читабельно с try . В этом примере я прочитал «открыть файл, прочитать все байты, отправить данные». При обычной обработке ошибок я бы прочитал «откройте файл, проверьте, была ли ошибка, обработка ошибок делает это, затем прочитайте все байты, теперь проверьте, не произошло ли что-то ...» Я знаю, что вы можете просмотреть err != nil s, но для меня try просто проще, потому что, когда я вижу это, я сразу понимаю поведение: возвращает if err != nil. Если у вас есть филиал, я должен посмотреть, что он делает. Оно могло сделать что угодно.

Я также утверждаю, что отложенный обработчик ошибок здесь не годится, кроме как просто обернуть ошибку новым сообщением.

Я уверен, что есть и другие вещи, которые вы можете делать в отсрочке, но, тем не менее, try в любом случае предназначен для простого общего случая. В любое время, когда вы хотите сделать что-то большее, всегда есть старая добрая обработка ошибок Go. Это не уходит.

@zeebo Да, я в этом заинтересован.
В статье @kungfusheep использовалась такая проверка на ошибку в одну строку, и мне захотелось попробовать ее. Затем, как только я сохранился, gofmt расширил его на три строки, что было грустно. Многие функции в stdlib определены в одной строке, поэтому меня удивило, что gofmt расширяет это.

@qrpnxz

Мне довелось прочитать много кода go. Одна из лучших вещей в этом языке — это простота, которая исходит от того, что большая часть кода следует определенному стилю (спасибо gofmt).
Я не хочу читать кучу кода, завернутого в try(f()) .
Это означает, что будут либо расхождения в стиле/практике кода, либо линтеры вроде «о, вы должны были использовать здесь try() » (что, опять же, мне даже не нравится, и в этом смысл моих и других комментариев по этому предложению).

Объективно это не лучше, чем if err != nil { return err } , просто меньше печатать.

Последняя вещь:

Если вы прочтете предложение, то увидите, что ничто не мешает вам

Можем ли мы воздержаться от такого языка? Конечно, я прочитал предложение. Так уж получилось, что я прочитал это прошлой ночью, а затем прокомментировал сегодня утром, подумав об этом и не объяснив мелочи того, что я имел в виду.
Это невероятно враждебный тон.

@cpuguy83
Мой плохой парень с процессором. Я не это имел в виду.

И я думаю, вы должны указать, что код, который использует try , будет сильно отличаться от кода, который этого не делает, поэтому я могу предположить, что это повлияет на опыт синтаксического анализа этого кода, но я не могу полностью согласиться с этим отличием. в данном случае означает хуже, хотя я понимаю, что лично вам это не нравится так же, как лично мне нравится. Многие вещи в Go именно такие. Что касается того, что линтеры говорят вам делать, это совершенно другой вопрос, я думаю.

Конечно, это не объективно лучше. Я говорил, что так мне удобнее читать. Я тщательно это сформулировал.

Еще раз извините за такой тон. Хотя это аргумент, я не хотел вас раздражать.

https://github.com/golang/go/issues/32437#issuecomment-498908380

Никто не заставит вас использовать try.

Не обращая внимания на бойкость, я думаю, что это довольно неуклюжий способ отмахнуться от критики дизайна.

Конечно, мне не нужно его использовать. Но любой, с кем я пишу код, может использовать его и заставить меня попытаться расшифровать try(try(try(to()).parse().this)).easily()) . Это как сказать

Никто не заставит вас использовать пустой интерфейс{}.

В любом случае, Go довольно строго относится к простоте: gofmt делает весь код одинаковым. Счастливый путь остается левым, и все, что может быть дорогим или неожиданным, является явным . try , как предлагается, это поворот на 180 градусов от этого. Простота! = лаконичность.

По крайней мере, try должно быть ключевым словом с lvalue.

Это не _объективно_ лучше, чем if err != nil { return err } , просто меньше печатать.

Между ними есть одно объективное различие: try(Foo()) — это выражение. Для некоторых эта разница является недостатком (критика try(strconv.Atoi(x))+try(strconv.Atoi(y)) ). Для других эта разница является преимуществом по той же причине. Все еще объективно не лучше или хуже, но я также не думаю, что разницу следует заметать под ковер, и утверждение, что «просто меньше печатать», не оправдывает предложение.

@elagergren-spideroak трудно сказать, что try раздражает видеть на одном дыхании, а затем сказать, что это неявно на следующем. Ты должен выбрать один.

Обычно аргументы функций сначала помещаются во временные переменные. Я уверен, что было бы чаще видеть

this := try(to()).parse().this
that := try(this.easily())

чем ваш пример.

try ничегонеделание — это счастливый путь, так что все выглядит так, как и ожидалось. На несчастливом пути все, что он делает, это возвращается. Чтобы собрать эту информацию, достаточно увидеть try . В возврате из функции тоже нет ничего дорогого, поэтому, судя по этому описанию, я не думаю, что try делает разворот на 180 градусов.

@josharian Что касается вашего комментария в https://github.com/golang/go/issues/32437#issuecomment -498941854, я не думаю, что здесь есть ошибка ранней оценки.

отложить fmt.HandleErrorf(&err, «foobar: %v», ошибка)

Неизмененное значение err передается в HandleErrorf и передается указатель на err . Мы проверяем, является ли err nil (с помощью указателя). Если нет, мы форматируем строку, используя немодифицированное значение err . Затем мы устанавливаем err в форматированное значение ошибки, используя указатель.

@Merovius Это предложение на самом деле является просто макросом синтаксического сахара, поэтому в конечном итоге оно будет касаться того, что люди думают, выглядит лучше или вызовет наименьшие проблемы. Если вы думаете, что нет, пожалуйста, объясните мне. Поэтому лично я за. С моей точки зрения, это хорошее дополнение без добавления каких-либо ключевых слов.

@ianlancetaylor , я думаю, что @josharian прав: «немодифицированное» значение err — это значение в момент помещения defer в стек, а не (предположительно предполагаемое) значение err устанавливается try перед возвратом.

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

this := try(to()).parse().this
that := try(this.easily())

^^ даже это просто ужасно. Первая строка, я должен прыгать туда-сюда, сопоставляя парен в голове. Даже вторую строчку, которая на самом деле довольно проста... действительно трудно читать.
Вложенные функции трудно читать.

parser, err := to()
if err != nil {
    return err
}
this := parser.parse().this
that, err := this.easily()
if err != nil {
    return err
}

^^ Это намного проще и лучше, ИМО. Это супер просто и понятно. да, это намного больше строк кода, мне все равно. Это очень очевидно.

@bcmills @josharian А, конечно, спасибо. Так что это должно быть

defer func() { fmt.HandleErrorf(&err, “foobar: %v”, err) }()

Не так приятно. Возможно, fmt.HandleErrorf все-таки должен неявно передавать значение ошибки в качестве последнего аргумента.

Эта проблема очень быстро получила множество комментариев, и многие из них, как мне кажется, повторяют уже сделанные комментарии. Конечно, не стесняйтесь комментировать, но я хотел бы мягко предложить, чтобы, если вы хотите переформулировать уже высказанную точку зрения, использовать смайлики GitHub, а не повторять ее. Спасибо.

@ianlancetaylor , если fmt.HandleErrorf отправляет ошибку в качестве первого аргумента после формата, тогда реализация будет лучше, и пользователь всегда сможет ссылаться на нее с помощью %[1]v .

@natefinch Абсолютно согласен.

Интересно, будет ли подход в стиле ржавчины более приемлемым?
Обратите внимание, что это не предложение, просто обдумать его...

this := to()?.parse().this
that := this.easily()?

В конце концов, я думаю, что это лучше, но (можно использовать ! или что-то еще...), но все же не решает проблему обработки ошибок.

конечно, ржавчина также имеет try() почти так же, но... другой стиль ржавчины.

Это не _объективно_ лучше, чем if err != nil { return err } , просто меньше печатать.

Между ними есть одно объективное различие: try(Foo()) — это выражение. Для некоторых эта разница является недостатком (критика try(strconv.Atoi(x))+try(strconv.Atoi(y)) ). Для других эта разница является преимуществом по той же причине. Все еще объективно не лучше или хуже, но я также не думаю, что разницу следует заметать под ковер, и утверждение, что «просто меньше печатать», не оправдывает предложение.

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

@MrTravisB

Точно моя точка зрения. Это предложение пытается решить отдельный вариант использования, а не предоставляет инструмент для решения более крупной проблемы обработки ошибок. Я думаю, что основной вопрос, если именно то, что вы указали.

Что конкретно я сказал, что именно это ваша точка зрения? Мне скорее кажется, что вы в корне неправильно поняли мою мысль, если думаете, что мы согласны.

По моему мнению и опыту, этот вариант использования составляет небольшое меньшинство и не требует сокращенного синтаксиса.

В исходнике Go есть тысячи случаев, которые try можно было бы обработать из коробки, даже если бы не было возможности добавить контекст к ошибкам. Если незначительный, это все еще частая причина жалобы.

Кроме того, подход с использованием defer для обработки ошибок имеет проблемы, поскольку он предполагает, что вы хотите обрабатывать все возможные ошибки одинаково. Операторы отсрочки не могут быть отменены.

Точно так же подход с использованием + для обработки арифметики предполагает, что вы не хотите вычитать, поэтому вы этого не сделаете, если не хотите. Интересный вопрос заключается в том, представляет ли контекст ошибки всего блока хотя бы общий шаблон.

Что делать, если мне нужна другая обработка ошибок для ошибок, которые могут быть возвращены из foo() по сравнению с foo2()

Опять же, тогда вы не используете try . Тогда вы ничего не получите от try , но и ничего не потеряете.

@cpuguy83

Интересно, будет ли подход в стиле ржавчины более приемлемым?

В предложении представлен аргумент против этого.

На данный момент я думаю, что try{}catch{} более читабельно :upside_down_face:

1. Использование именованного импорта для обхода угловых случаев defer не только ужасно для таких вещей, как godoc, но, что наиболее важно, очень подвержено ошибкам. Мне все равно, я могу обернуть все это еще одним func() , чтобы обойти проблему, просто мне нужно помнить о других вещах, я думаю, что это поощряет «плохую практику».

2. Никто не заставит вас использовать try.

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

3. Я думаю, что такие примеры, как try(try(try(to()).parse().this)).easily()) , нереалистичны, это уже можно было бы сделать с другими функциями, и я думаю, что было бы справедливо, если бы те, кто просматривает код, попросили его разделить.

4. Что, если у меня есть 3 места, которые могут выдать ошибку, и я хочу обернуть каждое место отдельно? try() делает это очень сложным, на самом деле try() уже препятствует ошибкам переноса, учитывая его сложность, но вот пример того, что я имею в виду:

   func before() error {
     x, err := foo()
     if err != nil {
       wrap(err, "error on foo")
     }
     y, err := bar(x)
     if err != nil {
       wrapf(err, "error on bar with x=%v", x)
     }
     fmt.Println(y)
     return nil
   }
   
   func after() (err error) {
     defer fmt.HandleErrorf(&err, "something failed but I don't know where: %v", err)
     x := try(foo())
     y := try(bar(x))
     fmt.Println(y)
     return nil
   }
   

5. Опять же, тогда вы не используете try . Тогда вы ничего не получите от try , но и ничего не потеряете.

   Предположим, что оборачивать ошибки полезным контекстом является хорошей практикой, try() будет считаться плохой практикой, поскольку не добавляет никакого контекста. Это означает, что try() — это функция, которую никто не хочет использовать, и которая стала функцией, которая используется так редко, что ее, возможно, и не существовало.

   Вместо того, чтобы просто сказать «ну, если вам это не нравится, не используйте это и заткнитесь» (так это читается), я думаю, было бы лучше попытаться исправить то, что многие пользователи считают недостатком. в дизайне. Можем ли мы вместо этого обсудить, что можно было бы изменить в предлагаемом проекте, чтобы наше предприятие лучше справлялось?

@boomlinde Мы согласны с тем, что это предложение пытается решить второстепенный вариант использования, и тот факт, что «если вам это не нужно, не используйте это», является основным аргументом в пользу этого. Как заявил @elagergren-spideroak, этот аргумент не работает, потому что, даже если я не хочу его использовать, другие захотят, что вынудит меня использовать его. По логике вашего аргумента в Go также должен быть тернарный оператор. И если вам не нравятся троичные операторы, не используйте их.

Отказ от ответственности. Я действительно думаю, что в Go должен быть троичный оператор, но, учитывая, что подход Go к функциям языка заключается в том, чтобы не вводить функции, которые могут затруднить чтение кода, этого не следует делать.

Мне приходит в голову еще одна вещь: я вижу много критики, основанной на идее, что наличие try может побудить разработчиков небрежно относиться к ошибкам. Но, на мой взгляд, это более верно для текущего языка; шаблон обработки ошибок раздражает настолько, что побуждает проглатывать или игнорировать некоторые ошибки, чтобы избежать их. Например, я несколько раз писал такие вещи:

func exists(filename string) bool {
  _, err := os.Stat(filename)
  return err == nil
}

чтобы иметь возможность написать if exists(...) { ... } , хотя этот код молча игнорирует некоторые возможные ошибки. Если бы у меня было try , я бы, вероятно, не стал этого делать и просто вернул бы (bool, error) .

Будучи здесь хаотичным, я подкину идею добавления второй встроенной функции с именем catch , которая будет получать функцию, которая принимает ошибку и возвращает перезаписанную ошибку, а затем, если последующая catch вызывается, он перезапишет обработчик. Например:

func catch(handler func(err error) error) {
  // .. impl ..
}

Теперь эта встроенная функция также будет макроподобной функцией, которая будет обрабатывать следующую ошибку, которая будет возвращена try следующим образом:

func wrapf(format string, ...values interface{}) func(err error) error {
  // user defined
  return func(err error) error {
    return fmt.Errorf(format + ": %v", ...append(values, err))
  }
}
func sample() {
  catch(wrapf("something failed in foo"))
  try(foo()) // "something failed in foo: <error>"
  x := try(foo2()) // "something failed in foo: <error>"
  // Subsequent calls for catch overwrite the handler
  catch(wrapf("something failed in bar with x=%v", x))
  try(bar(x)) // "something failed in bar with x=-1: <error>"
}

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

func foo(a, b string) (int64, error) {
  return try(strconv.Atoi(a)) + try(strconv.Atoi(b))
}
func withContext(a, b string) (int64, error) {
  catch(func (err error) error {
    return fmt.Errorf("can't parse a: %s, b: %s, err: %v", a, b, err)
  })
  return try(strconv.Atoi(a)) + try(strconv.Atoi(b))
}
func moreExplicitContext(a, b string) (int64, error) {
  catch(func (err error) error {
    return fmt.Errorf("can't parse a: %s, err: %v", a, err)
  })
  x := try(strconv.Atoi(a))
  catch(func (err error) error {
    return fmt.Errorf("can't parse b: %s, err: %v", b, err)
  })
  y := try(strconv.Atoi(b))
  return x + y
}
func withHelperWrapf(a, b string) (int64, error) {
  catch(wrapf("can't parse a: %s", a))
  x := try(strconv.Atoi(a))
  catch(wrapf("can't parse b: %s", b))
  y := try(strconv.Atoi(b))
  return x + y
}
func before(a, b string) (int64, error) {
  x, err := strconv.Atoi(a)
  if err != nil {
    return 0,  fmt.Errorf("can't parse a: %s, err: %v", a, err)
  }
  y, err := strconv.Atoi(b)
  if err != nil {
    return 0,  fmt.Errorf("can't parse b: %s, err: %v", b, err)
  }
  return x + y
}

И еще о хаотичном настроении (чтобы помочь вам сопереживать) Если вам не нравится catch , вы можете не использовать его.

Теперь... Я не имею в виду последнее предложение, но мне кажется, что оно бесполезно для обсуждения, очень агрессивно, ИМО.
Тем не менее, если бы мы пошли по этому пути, я думаю, что вместо этого мы могли бы также иметь try{}catch(error err){} :stuck_out_tongue:

См. также #27519 — модель ошибки #id/catch.

Никто не заставит вас использовать try.

Не обращая внимания на бойкость, я думаю, что это довольно неуклюжий способ отмахнуться от критики дизайна.

Извините, бойкость не была моей целью.

Я пытаюсь сказать, что try не является 100% решением. Существуют различные парадигмы обработки ошибок, которые плохо обрабатываются try . Например, если вам нужно добавить к ошибке контекст, зависящий от места вызова. Вы всегда можете вернуться к использованию if err != nil { для обработки этих более сложных случаев.

Это, безусловно, правильный аргумент, что try не может обрабатывать X для различных экземпляров X. Но часто обработка случая X означает усложнение механизма. Здесь есть компромисс: обработка X с одной стороны и усложнение механизма для всего остального. Все, что мы делаем, зависит от того, насколько распространен X и насколько сложно будет справиться с X.

Итак, говоря «Никто не заставит вас использовать try», я имею в виду, что я думаю, что рассматриваемый пример относится к 10%, а не к 90%. Это утверждение, безусловно, подлежит обсуждению, и я рад услышать контраргументы. Но в конце концов нам придется где-то подвести черту и сказать: «Да, try не справится с этим случаем. Вам придется использовать обработку ошибок в старом стиле. Извините».

Проблема не в том, что «try не может обработать этот конкретный случай обработки ошибок», а в том, что «try побуждает вас не оборачивать свои ошибки». Идея check-handle заставляла вас писать оператор возврата, поэтому написание обёртки ошибок было довольно тривиальным.

В этом предложении вам нужно использовать именованный возврат с defer , что не интуитивно понятно и кажется очень хакерским.

Идея check-handle заставляла вас писать оператор возврата, поэтому написание обёртки ошибок было довольно тривиальным.

Это неправда — в проекте проекта каждая функция, возвращающая ошибку, имеет обработчик по умолчанию , который просто возвращает ошибку.

Опираясь на озорную точку @Goodwine , вам действительно не нужны отдельные функции, такие как HandleErrorf , если у вас есть одна функция моста, например

func handler(err *error, handle func(error) error) {
  // nil handle is treated as the identity
  if *err != nil && handle != nil {
    *err = handle(*err)
  }
}

который вы бы использовали как

defer handler(&err, func(err error) error {
  if errors.Is(err, io.EOF) {
    return nil
  }
  return fmt.Errorf("oops: %w", err)
})

Вы можете сделать handler полумагической встроенной функцией, такой как try .

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

defer handler(func(err error) error {
  if errors.Is(err, io.EOF) {
    return nil
  }
  return fmt.Errorf("oops: %w", err)
})

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

Поскольку он использует defer , он может вызывать свою функцию handle всякий раз, когда возвращается ненулевая ошибка, что делает ее полезной даже без try , поскольку вы можете добавить

defer handler(wrapErrWithPackageName)

вверху до fmt.Errorf("mypkg: %w", err) всего.

Это дает вам многое из старого предложения check / handle , но работает с отложенным естественным образом (и явно), избавляясь в большинстве случаев от необходимости явно указывать имя err возврат. Как и try , это относительно простой макрос, который (я полагаю) можно полностью реализовать во внешнем интерфейсе.

Это неправда — в проекте проекта каждая функция, возвращающая ошибку, имеет обработчик по умолчанию, который просто возвращает ошибку.

Мой плохой, ты прав.

Я имею в виду, что я думаю, что рассматриваемый пример относится к 10%, а не к 90%. Это утверждение, безусловно, подлежит обсуждению, и я рад услышать контраргументы. Но в конце концов нам придется где-то провести черту и сказать: «Да, попытка не справится с этим случаем. Вам придется использовать обработку ошибок в старом стиле. Извините».

Согласен, мое мнение таково, что эта линия должна быть нарисована при проверке EOF или аналогичного, а не при переносе. Но, возможно, если бы ошибки имели больше контекста, это больше не было бы проблемой.

Может ли try() автоматически переносить ошибки с полезным контекстом для отладки? Например, если xerrors становится errors , ошибки должны иметь что-то похожее на трассировку стека, которую может добавить try() , не так ли? Если да, то этого будет достаточно 🤔

Если цели (читая https://github.com/golang/proposal/blob/master/design/32437-try-builtin.md):

• устранить шаблон
• минимальные языковые изменения
• охватывающий «наиболее распространенные сценарии»
• добавление очень небольшой сложности к языку

Я бы воспринял предложение, дал ему угол и разрешил миграцию кода «небольшими шагами» для всех миллиардов строк кода.

вместо предложенного:

func printSum(a, b string) error {
        defer fmt.HandleErrorf(&err, "sum %s %s: %v", a,b, err) 
        x := try(strconv.Atoi(a))
        y := try(strconv.Atoi(b))
        fmt.Println("result:", x + y)
        return nil
}

Мы можем:

func printSum(a, b string) error {
        var err ErrHandler{HandleFunc : twoStringsErr("printSum",a,b)} 
        x, err.Error := strconv.Atoi(a)
        y,err.Error := strconv.Atoi(b)
        fmt.Println("result:", x + y)
        return nil
}

Что бы мы выиграли?
twoStringsErr может быть встроен в printSum или в общий обработчик, который знает, как перехватывать ошибки (в данном случае с двумя строковыми параметрами), поэтому, если у меня есть одинаковые повторяющиеся сигнатуры func, используемые во многих моих функциях, мне не нужно переписывать обработчик каждый раз. время
таким же образом я могу расширить тип ErrHandler следующим образом:

type ioErrHandler ErrHandler
func (i ErrHandler) Handle() ...{

}

или

type parseErrHandler ErrHandler
func (p parseErrHandler) Handle() ...{

}

или

type str2IntErrHandler ErrHandler
func (s str2IntErrHandler) Handle() ...{

}

и используйте это все вокруг моего кода:

func printSum(a, b string) error {
        var pErr str2IntErrHandler 
        x, err.Error := strconv.Atoi(a)
        y,err.Error := strconv.Atoi(b)
        fmt.Println("result:", x + y)
        return nil
}

Таким образом, на самом деле необходимо разработать триггер, когда для err.Error установлено значение не nil.
С помощью этого метода мы также можем:

func (s str2IntErrHandler) Handle() bool{
   **return false**
}

Что сообщит вызывающей функции о продолжении вместо возврата

И используйте разные обработчики ошибок в одной и той же функции:

func printSum(a, b string) error {
        var pErr str2IntErrHandler 
        var oErr overflowError 
        x, err.Error := strconv.Atoi(a)
        y,err.Error := strconv.Atoi(b)
        fmt.Println("result:", x + y)
        totalAsByte,oErr := sumBytes(x,y)
        sunAsByte,oErr := subtractBytes(x,y)
        return nil
}

и т.п.

Еще раз пробежимся по целям

• убрать шаблон - готово
• минимальные языковые изменения - сделано
• охватывающий «наиболее распространенные сценарии» - больше, чем предлагаемый ИМО
• добавление очень небольшой сложности к языку - сон
  Плюс - более легкий перенос кода из

x, err := strconv.Atoi(a)

к

x, err.Error := strconv.Atoi(a)

и на самом деле - лучшая читаемость (ИМО, опять же)

@guybrand , ты последний приверженец этой повторяющейся темы (которая мне нравится).

См. https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback#recurring -themes

@guybrand Это похоже на совершенно другое предложение; Я думаю, вам следует оформить это как отдельную проблему, чтобы можно было сосредоточиться на обсуждении предложения @griesemer .

@natefinch согласен. Я думаю, что это больше направлено на улучшение опыта при написании Go, а не на оптимизацию для чтения. Интересно, могут ли макросы или фрагменты IDE решить проблему, не становясь при этом особенностью языка.

@Гудвин

Предположим, что оборачивать ошибки полезным контекстом является хорошей практикой, try() будет считаться плохой практикой, поскольку не добавляет никакого контекста. Это означает, что try() — это функция, которую никто не хочет использовать, и которая стала функцией, которая используется так редко, что ее можно было бы считать несуществующей.

Как отмечено в предложении (и показано на примере), try принципиально не мешает вам добавлять контекст. Я бы сказал, что предложенный способ добавления контекста к ошибкам полностью ему ортогонален. Это конкретно рассматривается в разделе часто задаваемых вопросов предложения.

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

Вместо того, чтобы просто сказать «ну, если вам это не нравится, не используйте это и заткнитесь» (так это читается), я думаю, было бы лучше попытаться исправить то, что многие пользователи считают недостатком. в дизайне.

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

Спасибо всем за плодотворную обратную связь; это очень информативно.
Вот моя попытка сделать первоначальное резюме, чтобы лучше понять обратную связь. Заранее приношу извинения всем, кого я пропустил или исказил; Надеюсь, я правильно уловил общую суть.

0) С положительной стороны, @rasky , @adg , @eandre , @dpinela и другие явно выражали удовлетворение по поводу упрощения кода, которое обеспечивает try .

1) Наиболее важной проблемой является то, что try не поощряет хороший стиль обработки ошибок, а вместо этого продвигает «быстрый выход». ( @agnivade , @peterbourgon , @politician , @a8m , @eandre , @prologic , @kungfusheep , @cpuguy и другие выразили свою озабоченность по этому поводу.)

2) Многим людям не нравится идея встроенного или связанный с ним синтаксис функции, потому что он скрывает return . Лучше использовать ключевое слово. ( @sheerun , @Redundancy , @dolmen , @komuw , @RobertGrantEllis , @elagergren-spideroak). try также можно легко не заметить (@peterbourgon), особенно потому, что он может появляться в выражениях, которые могут быть произвольно вложенными. @natefinch обеспокоен тем, что try позволяет «слишком легко сбрасывать слишком много в одну строку», чего мы обычно стараемся избегать в Go. Кроме того, поддержка IDE для try может оказаться недостаточной (@dominikh); try должен «стоять сам по себе».

3) Для некоторых статус-кво явных операторов if не является проблемой, они им довольны ( @bitfield , @marwan-at-work, @natefinch). Лучше иметь только один способ делать что-либо (@gbbr); а явные операторы if лучше, чем неявные операторы return ( @DavexPro , @hmage , @prologic , @natefinch).
В том же духе @mattn обеспокоен «неявной привязкой» результата ошибки к try — связь явно не видна в коде.

4) Использование try усложнит отладку кода; например, может потребоваться переписать выражение try обратно в оператор if только для того, чтобы можно было вставить операторы отладки ( @deanveloper , @typeless , @networkimprov , другие).

5) Есть некоторые опасения по поводу использования именованных возвратов ( @buchanae , @adg).

Несколько человек внесли предложения по улучшению или изменению предложения:

6) Некоторые подхватили идею дополнительного обработчика ошибок (@beoran) или строки формата, предоставляемой try ( @unexge , @a8m , @eandre , @gotwarlost ), чтобы способствовать хорошей обработке ошибок.

7) @pierrec предположил, что gofmt может соответствующим образом форматировать выражения try , чтобы сделать их более заметными.
В качестве альтернативы можно сделать существующий код более компактным, разрешив gofmt форматировать операторы if , проверяющие наличие ошибок в одной строке (@zeebo).

8) @marwan-at-work утверждает, что try просто переносит обработку ошибок с операторов if на выражения try . Вместо этого, если мы действительно хотим решить проблему, Go должен «владеть» обработкой ошибок, сделав ее действительно неявной. Цель должна состоять в том, чтобы упростить (правильную) обработку ошибок и повысить продуктивность разработчиков (@cpuguy).

9) Наконец, некоторым людям не нравится имя try ( @beoran , @HiImJC , @dolmen ) или они предпочитают такой символ, как ? ( @twisted1919 , @leaxoy , другие) .

Некоторые комментарии к этому отзыву (соответственно пронумерованные):

0) Спасибо за положительный отзыв! :-)

1) Было бы хорошо узнать больше об этой проблеме. Текущий стиль кодирования с использованием операторов if для проверки на наличие ошибок настолько явный, насколько это возможно. Очень легко добавить дополнительную информацию к ошибке на индивидуальной основе (для каждого if ). Часто имеет смысл обрабатывать все обнаруженные в функции ошибки единым образом, что можно сделать с помощью defer — это уже сейчас возможно. Тот факт, что у нас уже есть все инструменты для хорошей обработки ошибок в языке, и проблема конструкции обработчика, не являющейся ортогональной defer , заставила нас отказаться от нового механизма исключительно для увеличения ошибок. .

2) Конечно, есть возможность использовать ключевое слово или специальный синтаксис вместо встроенного. Новое ключевое слово не будет обратно совместимым. Новый оператор может, но кажется еще менее заметным. В подробном предложении подробно обсуждаются различные плюсы и минусы. Но, возможно, мы ошибаемся в этом.

3) Причиной этого предложения является то, что обработка ошибок (в частности, связанный шаблонный код) была упомянута сообществом Go как серьезная проблема в Go (наряду с отсутствием дженериков). Это предложение напрямую направлено на проблему стандартного шаблона. Он не делает больше, чем решает самый простой случай, потому что любой более сложный случай лучше обрабатывается тем, что у нас уже есть. Таким образом, в то время как большое количество людей довольны статус-кво, существует (вероятно) столь же большой контингент людей, которые хотели бы более упорядоченного подхода, такого как try , хорошо зная, что это «просто» синтаксический сахар.

4) Точка отладки является обоснованной проблемой. Если есть необходимость добавить код между обнаружением ошибки и return , необходимость переписать выражение try в оператор if может раздражать.

5) Именованные возвращаемые значения: Подробный документ обсуждает это подробно. Если это главная проблема в этом предложении, то, я думаю, мы находимся в хорошем положении.

6) Необязательный аргумент обработчика для try : это также обсуждается в подробном документе. См. раздел «Итерации проекта».

7) Использование gofmt для форматирования выражений try таким образом, чтобы они были более заметными, безусловно, является вариантом. Но это лишит некоторых преимуществ try при использовании в выражении.

8) Мы рассматривали проблему с точки зрения обработки ошибок ( handle ), а не с точки зрения тестирования ошибок ( try ). В частности, мы вкратце рассмотрели только введение понятия обработчика ошибок (по аналогии с первоначальным проектом, представленным на прошлогоднем Gophercon). Мысль заключалась в том, что если (и только если) объявлен обработчик, в присваиваниях с несколькими значениями, где последнее значение имеет тип error , это значение может быть просто опущено в присваивании. Компилятор неявно проверит, не равно ли оно нулю, и если да, то перейдет к обработчику. Это привело бы к полному исчезновению явной обработки ошибок и побудило бы всех вместо этого написать обработчик. Это казалось экстремальным подходом, потому что он был бы полностью неявным — факт проверки был бы невидимым.

9) Могу ли я предложить, чтобы мы не отказывались от имени на этом этапе. Как только все остальные проблемы будут решены, самое время заняться тонкой настройкой имени.

Это не означает, что опасения недействительны — приведенные выше ответы просто излагают наше текущее мышление. В будущем было бы хорошо прокомментировать новые опасения (или новые доказательства в поддержку этих опасений) — просто повторение того, что уже было сказано, не дает нам дополнительной информации.

И, наконец, похоже, что не все, кто комментирует проблему, читали подробный документ. Пожалуйста, сделайте это, прежде чем комментировать, чтобы не повторять то, что уже было сказано. Спасибо.

Это не комментарий к предложению, а сообщение об опечатке. Это не было исправлено с тех пор, как было опубликовано полное предложение, поэтому я решил упомянуть об этом:

func try(t1 T1, t1 T2, … tn Tn, te error) (T1, T2, … Tn)

должно быть:

func try(t1 T1, t2 T2, … tn Tn, te error) (T1, T2, … Tn)

Стоит ли анализировать общедоступный код Go для операторов проверки ошибок, чтобы попытаться выяснить, действительно ли большинство проверок ошибок повторяются или в большинстве случаев несколько проверок в одной и той же функции добавляют разную контекстуальную информацию? Предложение имело бы большой смысл в первом случае, но не помогло бы во втором. В последнем случае люди либо продолжат использовать if err != nil , либо откажутся от добавления дополнительного контекста, будут использовать try() и прибегнут к добавлению общего контекста ошибок для каждой функции, что, по мнению IMO, было бы вредным. Я думаю, что с будущими функциями значений ошибок мы ожидаем, что люди будут чаще оборачивать ошибки дополнительной информацией. Возможно, я неправильно понял предложение, но AFAIU, это помогает уменьшить шаблон только тогда, когда все ошибки одной функции должны быть обернуты ровно одним способом, и не помогает, если функция обрабатывает пять ошибок, которые, возможно, нужно обернуть по-разному. Не уверен, насколько распространены такие случаи в дикой природе (довольно распространены в большинстве моих проектов), но я обеспокоен тем, что try() может побудить людей использовать общие оболочки для каждой функции, даже если имеет смысл оборачивать разные ошибки. по-другому.

Просто быстрый комментарий, подкрепленный данными небольшого выборочного набора:

Мы предлагаем новую встроенную функцию под названием try, разработанную специально для устранения шаблонных операторов if, обычно связанных с обработкой ошибок в Go.

Если это основная проблема, решаемая этим предложением, я обнаружил, что этот «шаблон» составляет только ~ 1,4% моего кода в десятках общедоступных проектов с открытым исходным кодом на общую сумму ~ 60 000 SLOC.

Интересно, есть ли у кого-нибудь еще такая же статистика?

В гораздо большей кодовой базе, такой как сам Go, в общей сложности около ~ 1,6 млн SLOC, это составляет около ~ 0,5% кодовой базы, содержащей строки вроде if err != nil .

Действительно ли это самая серьезная проблема, которую нужно решить с помощью Go 2?

Большое спасибо @griesemer за то, что нашли время, чтобы рассмотреть все идеи и явно изложить мысли. Я думаю, что это действительно помогает с восприятием того, что сообщество услышано в процессе.

1. @pierrec предположил, что gofmt может соответствующим образом отформатировать выражения try, чтобы сделать их более заметными.
   В качестве альтернативы можно сделать существующий код более компактным, разрешив gofmt форматировать операторы if, проверяющие наличие ошибок в одной строке (@zeebo).

1. Использование gofmt для форматирования выражений try таким образом, чтобы они были более заметными, безусловно, является вариантом. Но это лишит некоторых преимуществ try при использовании в выражении.

Это ценные мысли о том, что gofmt требуется для форматирования try , но мне интересно, есть ли какие-либо мысли, в частности, о том, что gofmt разрешает проверку операторов if ошибка в одну строку. Предложение было объединено с форматированием try , но я думаю, что это совершенно ортогональная вещь. Спасибо.

@griesemer спасибо за невероятную работу по просмотру всех комментариев и ответов на большинство, если не на все отзывы 🎉

Одна вещь, которая не была затронута в вашем отзыве, — это идея использовать инструментальную часть языка Go для улучшения обработки ошибок, а не обновлять синтаксис Go.

Например, с появлением нового LSP ( gopls ) кажется, что это идеальное место для анализа подписи функции и заботы о шаблоне обработки ошибок для разработчика, а также с надлежащей оберткой и проверкой.

@griesemer Я уверен, что это не очень хорошо продумано, но я попытался изменить ваше предложение ближе к тому, что мне было бы удобно здесь: https://www.reddit.com/r/golang/comments/bwvyhe /proposal_a_builtin_go_error_check_function_try/eq22bqa?utm_source=share&utm_medium=web2x

@zeebo Было бы легко сделать gofmt формате if err != nil { return ...., err } в одной строке. Предположительно, это будет только для этого конкретного типа шаблона if , а не для всех «коротких» операторов if ?

В том же духе были опасения, что try будет невидимым, потому что он находится в той же строке, что и бизнес-логика. У нас есть все эти варианты:

Текущий стиль:

a, b, c, ... err := BusinessLogic(...)
if err != nil {
   return ..., err
}

Однострочный if :

a, b, c, ... err := BusinessLogic(...)
if err != nil { return ..., err }

try в отдельной строке (!):

a, b, c, ... err := BusinessLogic(...)
try(err)

try как предложено:

a, b, c := try(BusinessLogic(...))

Первая и последняя строки кажутся (мне) самыми ясными, особенно когда кто-то привык распознавать try как то, что это такое. В последней строке явно проверяется наличие ошибки, но поскольку это (обычно) не основное действие, оно немного больше в фоновом режиме.

@ marwan-at-work Я не уверен, что вы предлагаете делать инструменты для вас. Вы предлагаете как-то скрыть обработку ошибок?

@дпинела

@guybrand Это похоже на совершенно другое предложение; Я думаю, вам следует оформить это как отдельную проблему, чтобы можно было сосредоточиться на обсуждении предложения @griesemer .

ИМО мое предложение отличается только синтаксисом, что означает:

• Цели схожи по содержанию и приоритету.
• Идея захвата каждой ошибки в своей строке и, соответственно (если не ноль), выхода из функции при прохождении через функцию обработчика аналогична (псевдо asm - это "jnz" и "call").
• Это даже означает, что количество строк в теле функции (без отсрочки) и поток будут выглядеть точно так же (и, соответственно, AST, вероятно, тоже получится таким же).

поэтому основное различие заключается в том, оборачиваем ли мы исходный вызов функции с помощью try(func()), который всегда будет анализировать последнюю переменную для jnz вызова, или использовать для этого фактическое возвращаемое значение.

Я знаю, что это выглядит иначе, но на самом деле очень похоже на концепцию.
С другой стороны, если вы возьмете обычную попытку .... catch на многих c-подобных языках, это будет совсем другая реализация, другая читабельность и т. Д.

Однако я серьезно думаю о написании предложения, спасибо за идею.

@griesemer

Я не уверен, что вы предлагаете, что инструменты делают для вас. Вы предлагаете как-то скрыть обработку ошибок?

Наоборот: я предлагаю gopls написать для вас шаблон обработки ошибок.

Как вы упомянули в своем последнем комментарии:

Причина этого предложения заключается в том, что обработка ошибок (в частности, соответствующий шаблонный код) была упомянута сообществом Go как серьезная проблема в Go (наряду с отсутствием дженериков).

Итак, суть проблемы в том, что программисту приходится писать много шаблонного кода. Так что проблема в том, чтобы писать, а не читать. Поэтому я предлагаю: пусть компьютер (tooling/gopls) напишет за программиста, проанализировав сигнатуру функции и поместив соответствующие пункты обработки ошибок.

Например:

// user begins to write this function: 
func openFile(path string) ([]byte, error) {
  file, err := os.Open(path)
  defer file.Close()
  bts, err := ioutil.ReadAll(file)
  return bts, nil
}

Затем пользователь запускает инструмент, возможно, просто сохраняя файл (аналогично тому, как обычно работает gofmt/goimports), и gopls просматривает эту функцию, анализирует возвращаемую сигнатуру и дополняет код следующим образом:

// user has triggered the tool (by saving the file, or code action)
func openFile(path string) ([]byte, error) {
  file, err := os.Open(path)
  if err != nil {
    return nil, fmt.Errorf("openFile: %w", err)
  }
  defer file.Close()
  bts, err := ioutil.ReadAll(file)
  if err != nil {
    return nil, fmt.Errorf("openFile: %w", err)
  }
  return bts, nil
}

Таким образом, мы получаем лучшее из обоих миров: мы получаем удобочитаемость/ясность текущей системы обработки ошибок, а программист не пишет никаких шаблонов для обработки ошибок. Более того, пользователь может позже модифицировать блоки обработки ошибок, чтобы добиться другого поведения: gopls может понять, что блок существует, и не будет его изменять.

Как инструмент узнает, что я намерен обработать err позже в функции, а не возвращаться раньше? Хоть и редко, но тем не менее код я написал.

Прошу прощения, если этот вопрос уже поднимался, но я не нашел упоминания об этом.

try(DoSomething()) мне хорошо читается и имеет смысл: код пытается что-то сделать. try(err) , OTOH, с точки зрения семантики кажется немного странным: как можно попробовать ошибку? На мой взгляд, можно было бы _проверить_ или _проверить_ ошибку, но _попробовать_ не кажется правильным.

Я понимаю, что разрешение try(err) важно из соображений согласованности: я полагаю, было бы странно, если бы try(DoSomething()) работало, а err := DoSomething(); try(err) — нет. Тем не менее, кажется, что try(err) выглядит немного неуклюже на странице. Я не могу придумать какие-либо другие встроенные функции, которые можно было бы так легко сделать такими странными.

У меня нет конкретных предложений по этому поводу, но я все же хотел сделать это замечание.

@griesemer Спасибо. Действительно, предложение должно было быть только для return , но я подозреваю, что было бы хорошо, если бы любой отдельный оператор был одной строкой. Например, в тесте можно было бы без изменений в библиотеке тестирования иметь

if err != nil { t.Fatal(err) }

Первая и последняя строки кажутся (мне) самыми ясными, особенно если привыкнуть распознавать попытку как то, что она есть. В последней строке явно проверяется наличие ошибки, но поскольку это (обычно) не основное действие, оно немного больше в фоновом режиме.

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

Мне больше нечего добавить из того, что, как мне кажется, еще не было сказано.

Я не видел, как ответить на этот вопрос в дизайн-документе. Что делает этот код:

func foo() (err error) {
    src := try(getReader())
    if src != nil {
        n, err := src.Read(nil)
        if err == io.EOF {
            return nil
        }
        try(err)
        println(n)
    }
    return nil
}

Насколько я понимаю, это будет обессахариваться в

func foo() (err error) {
    tsrc, te := getReader()
    if err != nil {
        err = te
        return
    }
    src := tsrc

    if src != nil {
        n, err := src.Read(nil)
        if err == io.EOF {
            return nil
        }

        terr := err
        if terr != nil {
            err = terr
            return
        }

        println(n)
    }
    return nil
}

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

@marwan-на-работе

Как вы упомянули в своем последнем комментарии:

Причина этого предложения заключается в том, что обработка ошибок (в частности, соответствующий шаблонный код) была упомянута сообществом Go как серьезная проблема в Go (наряду с отсутствием дженериков).

Итак, суть проблемы в том, что программисту приходится писать много шаблонного кода. Так что проблема в том, чтобы писать, а не читать.

Я думаю, что на самом деле все наоборот - меня больше всего раздражает текущий шаблон обработки ошибок не столько в том, что его нужно печатать, сколько в том, как он разбрасывает счастливый путь функции по вертикали по экрану, что затрудняет понимание в взгляд. Эффект особенно заметен в коде с большим количеством операций ввода-вывода, где между каждыми двумя операциями обычно есть блок шаблона. Даже упрощенная версия CopyFile занимает примерно 20 строк, хотя на самом деле она выполняет всего пять шагов: открыть исходный код, отложить закрытие исходного кода, открыть место назначения, скопировать источник -> место назначения, закрыть место назначения.

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

Мне нравится try в отдельной строке.
И я надеюсь, что он сможет указать функцию handler самостоятельно.

func try(error, optional func(error)error)

func (p *pgStore) DoWork() error {
    tx, err := p.handle.Begin()
    try(err)

    handle := func(err error) error {
        tx.Rollback()
        return err
    }

    var res int64
    _, err = tx.QueryRow(`INSERT INTO table (...) RETURNING c1`, ...).Scan(&res)
    try(err, handle)

    _, err = tx.Exec(`INSERT INTO table2 (...) VALUES ($1)`, res)
    try(err, handle)

    return tx.Commit()
}

@zeebo : примеры , которые я привел, - это переводы 1: 1. Первый (традиционный if ) не обработал ошибку, как и остальные. Если бы первый обрабатывал ошибку, и если бы это было единственное место, где проверяется ошибка в функции, первый пример (с использованием if ) мог бы быть подходящим выбором для написания кода. Если есть несколько проверок ошибок, каждая из которых использует одну и ту же обработку ошибок (оболочку), скажем, потому что все они добавляют информацию о текущей функции, можно использовать оператор defer для обработки всех ошибок в одном месте. При желании можно переписать if в try (или оставить их в покое). Если есть несколько ошибок, которые нужно проверить, и все они обрабатывают ошибки по-разному (что может быть признаком того, что проблема функции слишком широка и, возможно, ее необходимо разделить), использование if способ пойти. Да, одно и то же можно сделать несколькими способами, и правильный выбор зависит как от кода, так и от личного вкуса. Хотя мы стремимся в Go к «одному способу сделать одну вещь», это, конечно, уже не так, особенно для общих конструкций. Например, когда последовательность if - else - if становится слишком длинной, иногда более подходящей может быть последовательность switch . Иногда объявление переменной var x int выражает намерение лучше, чем x := 0 и так далее (хотя не всем это нравится).

Что касается вашего вопроса о «перезаписи»: нет, ошибки компиляции не будет. Обратите внимание, что перезапись происходит внутри (и может быть более эффективной, чем предполагает шаблон кода), и компилятору не нужно жаловаться на теневой возврат. В вашем примере вы объявили локальную переменную err во вложенной области. Конечно, try по-прежнему будет иметь прямой доступ к результирующей переменной err . Под обложкой переписывание может выглядеть так .

[отредактировано] PS: Лучшим ответом было бы: try не является голым возвратом (даже если переписывание выглядит так). В конце концов, один явно дает try аргумент, который содержит (или является) ошибкой, которая возвращается, если не nil . Теневая ошибка для голых возвратов - это ошибка в источнике (а не в базовом переводе источника. Компилятору не нужна ошибка.

Если окончательный тип возвращаемого значения всеобъемлющей функции не является ошибкой типа, можем ли мы паниковать?

Это сделает встроенный более универсальным (например, удовлетворит мою озабоченность в # 32219)

@pjebs Это было рассмотрено и отклонено. Пожалуйста, ознакомьтесь с подробным проектным документом (который явно относится к вашей проблеме по этому вопросу).

Я также хочу отметить, что try() обрабатывается как выражение, хотя он работает как оператор возврата. Да, я знаю, что try — это встроенный макрос, но я думаю, что большинство пользователей будут использовать его как функциональное программирование.

func doSomething() (error, error, error, error, error) {
   ...
}

try(try(try(try(try(doSomething)))))

Дизайн говорит, что вы исследовали использование panic вместо возврата с ошибкой.

Я подчеркиваю тонкое различие:

Делайте именно то, что указано в вашем текущем предложении, за исключением удаления ограничения на то, что всеобъемлющая функция должна иметь окончательный возвращаемый тип типа error .

Если у него нет окончательного возвращаемого типа error => паника
При использовании try для объявлений переменных уровня пакета => паника (устраняет необходимость в соглашении MustXXX( ) )

Для модульных тестов небольшое изменение языка.

@mattn , я очень сомневаюсь, что какое-либо значительное количество людей будет писать такой код.

@pjebs , эта семантика - паника, если в текущей функции нет ошибки - это именно то, что обсуждается в проектном документе на https://github.com/golang/proposal/blob/master/design/32437-try-builtin. md#обсуждение.

Кроме того, в попытке сделать try полезным не только внутри функций с результатом ошибки, семантика try зависела от контекста: если try использовался на уровне пакета или если он вызывался внутри функции без результата ошибки, try будет паниковать при обнаружении ошибки. (Кроме того, из-за этого свойства встроенная функция была названа must, а не try в этом предложении.) Такое контекстно-зависимое поведение try (или must) казалось естественным и весьма полезным: это позволило бы исключить многие пользовательские обязательные вспомогательные функции, используемые в настоящее время в выражениях инициализации переменных на уровне пакета. Это также открыло бы возможность использования try в модульных тестах через тестовый пакет.

Тем не менее, контекстная зависимость try считалась чреватой: например, поведение функции, содержащей вызовы try, могло незаметно измениться (с возможной паники на отсутствие паники и наоборот), если результат ошибки был добавлен или удален из подписи. Это казалось слишком опасным свойством. Очевидным решением было бы разделить функциональность try на две отдельные функции, must и try (очень похоже на то, что предлагается в issue #31442). Но для этого потребовались бы две новые встроенные функции, и только попытка try напрямую связана с неотложной потребностью в лучшей поддержке обработки ошибок.

@pjebs Это именно то, что мы рассмотрели в предыдущем предложении (см. Подробный документ, раздел «Итерации дизайна», 4-й абзац):

Кроме того, в попытке сделать try полезным не только внутри функций с результатом ошибки, семантика try зависела от контекста: если try использовался на уровне пакета или если он вызывался внутри функции без результата ошибки, try будет паниковать при обнаружении ошибки. (Кроме того, из-за этого свойства встроенная функция была вызвана must, а не try в этом предложении.)

Консенсус (внутренний Go Team) заключался в том, что try будет сбивать с толку, если он будет зависеть от контекста и действовать по-разному. Например, добавление результата ошибки к функции (или его удаление) может незаметно изменить поведение функции с паники на отсутствие паники (или наоборот).

@griesemer Спасибо за разъяснения по поводу перезаписи. Я рад, что он скомпилируется.

Я понимаю, что примеры были переводами без аннотаций ошибок. Я попытался доказать, что try затрудняет хорошее аннотирование ошибок в распространенных ситуациях, и что аннотирование ошибок очень важно для сообщества. Большая часть комментариев до сих пор касалась способов улучшения поддержки аннотаций в try .

Что касается необходимости обрабатывать ошибки по-разному, я не согласен, что это признак того, что проблема функции слишком широка. Я переводил некоторые примеры заявленного реального кода из комментариев и помещал их в раскрывающийся список внизу моего исходного комментария , а пример в https://github.com/golang/go/issues/32437#issuecomment - 499007288 Я думаю, хорошо демонстрирует распространенный случай:

func (c *Config) Build() error {
    pkgPath, err := c.load()
    if err != nil { return nil, errors.WithMessage(err, "load config dir") }

    b := bytes.NewBuffer(nil)
    err = templates.ExecuteTemplate(b, "main", c)
    if err != nil { return nil, errors.WithMessage(err, "execute main template") }

    buf, err := format.Source(b.Bytes())
    if err != nil { return nil, errors.WithMessage(err, "format main template") }

    target := fmt.Sprintf("%s.go", filename(pkgPath))
    err = ioutil.WriteFile(target, buf, 0644)
    if err != nil { return nil, errors.WithMessagef(err, "write file %s", target) }
    // ...
}

Цель этой функции — выполнить шаблон для некоторых данных в файл. Я не считаю, что его нужно разделять, и было бы прискорбно, если бы все эти ошибки просто получили строку, на которой они были созданы, из отсрочки. Это может быть хорошо для разработчиков, но гораздо менее полезно для пользователей.

Я думаю, что это также сигнал о том, насколько незаметными были ошибки defer wrap(&err, "message: %v", err) и как они сбивали с толку даже опытных программистов Go.

Подводя итог моему аргументу : я думаю, что аннотация ошибок более важна, чем проверка ошибок на основе выражений, и мы можем немного уменьшить шум, разрешив проверку ошибок на основе операторов в одну строку вместо трех. Спасибо.

@griesemer извините, я прочитал другой раздел, в котором обсуждалась паника, и не видел обсуждения опасностей.

@zeebo Спасибо за этот пример. Похоже, что в этом случае использование оператора if — правильный выбор. Но, если принять во внимание, форматирование if в однострочники может немного упростить это.

Я хотел бы еще раз поднять идею обработчика в качестве второго аргумента для try , но с добавлением того, что аргумент обработчика должен быть _required_, но невозможным. Это делает обработку ошибки по умолчанию, а не исключение. В тех случаях, когда вы действительно хотите передать ошибку без изменений, просто укажите значение nil в обработчике, и try будет вести себя так же, как в исходном предложении, но аргумент nil будет действовать как визуальный сигнал о том, что ошибка ошибка не обрабатывается. Это будет легче поймать во время проверки кода.

file := try(os.Open("my_file.txt"), nil)

Что должно произойти, если обработчик предоставлен, но равен нулю? Следует ли попробовать панику или относиться к ней как к отсутствующему обработчику ошибок?

Как упоминалось выше, try будет вести себя в соответствии с исходным предложением. Не было бы такого понятия, как отсутствующий обработчик ошибок, только нулевой.

Что, если обработчик вызывается с ошибкой, отличной от нуля, а затем возвращает нулевой результат? Означает ли это, что ошибка «сброшена»? Или объемлющая функция должна вернуться с нулевой ошибкой?

Я считаю, что закрывающая функция вернется с нулевой ошибкой. Потенциально было бы очень запутанно, если бы try могла иногда продолжать выполнение даже после того, как она получила ненулевое значение ошибки. Это позволит обработчикам «позаботиться» об ошибке в некоторых случаях. Такое поведение может быть полезно, например, в функции стиля "получить или создать".

func getOrCreateObject(obj *object) error {
    defaultObjectHandler := func(err error) error {
        if err == ObjectDoesNotExistErr {
            *obj = object{}
            return nil
        }
        return fmt.Errorf("getting or creating object: %v", err)
    }

    *obj = try(db.getObject(), defaultObjectHandler)
}

Также было неясно, приведет ли разрешение необязательного обработчика ошибок к тому, что программисты вообще будут игнорировать правильную обработку ошибок. Также было бы легко сделать правильную обработку ошибок везде, но пропустить хотя бы одну попытку. И так далее.

Я считаю, что обе эти проблемы можно уменьшить, сделав обработчик обязательным аргументом, который нельзя использовать. Это требует от программистов сознательного и явного решения, что они не будут обрабатывать свою ошибку.

В качестве бонуса я думаю, что требование обработчика ошибок также препятствует глубоко вложенным try ам, потому что они менее краткие. Кому-то это покажется недостатком, но я считаю, что это преимущество.

@velovix Мне нравится эта идея, но зачем нужен обработчик ошибок? Разве это не может быть nil по умолчанию? Зачем нужна «визуальная подсказка»?

@griesemer Что, если идея @velovix будет принята, но с builtin , содержащей предопределенную функцию, которая преобразует ошибку в панику, И мы удалим требование, чтобы всеобъемлющая функция имела возвращаемое значение ошибки?

Идея состоит в том, что если всеобъемлющая функция не возвращает ошибку, использование try без обработчика ошибок является ошибкой времени компиляции.

Обработчик ошибок также можно использовать для переноса ошибки, которая скоро будет возвращена, с использованием различных библиотек и т. д. в месте ошибки вместо defer вверху, который изменяет именованную возвращенную ошибку.

@pjebs

зачем нужен обработчик ошибок? Разве это не может быть nil по умолчанию? Зачем нужна «визуальная подсказка»?

Это необходимо для устранения опасений, что

1. Предложение try в его нынешнем виде может отбить у людей охоту предоставлять контекст своим ошибкам, поскольку сделать это не так просто.

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

1. Проблема из исходного документа предложения. Я процитировал это в своем первом комментарии:

Также было неясно, приведет ли разрешение необязательного обработчика ошибок к тому, что программисты вообще будут игнорировать правильную обработку ошибок. Также было бы легко сделать правильную обработку ошибок везде, но пропустить хотя бы одну попытку. И так далее.

Необходимость передать явный nil затрудняет забывание правильной обработки ошибки. Вы должны явно решить не обрабатывать ошибку вместо того, чтобы делать это неявно, опуская аргумент.

Думая дальше об условном возврате, кратко упомянутом на https://github.com/golang/go/issues/32437#issuecomment -498947603.
Похоже на то
return if f, err := os.Open("/my/file/path"); err != nil
будет более соответствовать тому, как выглядит существующий if в Go.

Если мы добавим правило для оператора return if , которое
когда последнее выражение условия (например, err != nil ) отсутствует,и последняя переменная объявления в операторе return if имеет тип error ,тогда значение последней переменной будет автоматически сравниваться с nil как неявное условие.

Тогда оператор return if можно сократить до:
return if f, err := os.Open("my/file/path")

Что очень близко к соотношению сигнал-шум, которое обеспечивает try .
Если мы изменим return if на try , получится
try f, err := os.Open("my/file/path")
Это снова становится похожим на другие предложенные варианты try в этой теме, по крайней мере, синтаксически.
Лично я все еще предпочитаю return if try в этом случае, потому что это делает точки выхода функции очень явными. Например, при отладке я часто выделяю ключевое слово return в редакторе, чтобы определить все точки выхода большой функции.

К сожалению, похоже, это также недостаточно помогает с неудобствами вставки журнала отладки.
Если мы также не разрешим блок body для return if , например
Оригинал:

        return if f, err := os.Open("my/path") 

При отладке:

-       return if f, err := os.Open("my/path") 
+       return if f, err := os.Open("my/path") {
+               fmt.Printf("DEBUG: os.Open: %s\n", err)
+       }

Я полагаю, что смысл блока тела return if очевиден. Он будет выполнен до defer и завершится.

Тем не менее, у меня нет претензий к существующему подходу к обработке ошибок в Go.
Меня больше беспокоит то, как добавление новой обработки ошибок повлияет на нынешнее совершенство Go.

@velovix Нам очень понравилась идея try с явной функцией обработчика в качестве второго аргумента. Но было слишком много вопросов, на которые не было очевидных ответов, как говорится в дизайн-документе. На некоторые из них вы ответили так, как вам кажется разумным. Вполне вероятно (и это был наш опыт в Go Team), что кто-то другой думает, что правильный ответ совсем другой. Например, вы заявляете, что аргумент обработчика всегда должен предоставляться, но он может быть nil , чтобы сделать его явным, мы не заботимся об обработке ошибки. Что произойдет, если вы предоставите значение функции (а не литерал nil ), и это значение функции (хранящееся в переменной) окажется равным нулю? По аналогии с явным значением nil никакой обработки не требуется. Но другие могут возразить, что это ошибка в коде. Или, в качестве альтернативы, можно разрешить аргументы обработчика с нулевым значением, но тогда функция может непоследовательно обрабатывать ошибки в некоторых случаях, а не в других, и это не обязательно очевидно из кода, который делает, потому что кажется, что обработчик всегда присутствует . Другим аргументом было то, что лучше иметь объявление обработчика ошибок на верхнем уровне, потому что это ясно показывает, что функция действительно обрабатывает ошибки. Отсюда defer . Там, вероятно, больше.

Было бы хорошо узнать больше об этой проблеме. Текущий стиль кодирования с использованием операторов if для проверки на наличие ошибок настолько явный, насколько это возможно. Добавить дополнительную информацию к ошибке на индивидуальной основе (для каждого if) очень просто. Часто имеет смысл обрабатывать все обнаруженные в функции ошибки единым образом, что можно сделать с помощью отложенного — это уже сейчас возможно. Тот факт, что у нас уже есть все инструменты для хорошей обработки ошибок в языке, и проблема конструкции обработчика, не являющейся ортогональной для отсрочки, заставили нас отказаться от нового механизма исключительно для увеличения ошибок.

@griesemer - IIUC, вы говорите, что для контекстов ошибок, зависящих от места вызова, текущий оператор if подходит. Принимая во внимание, что эта новая функция try полезна в случаях, когда полезна обработка нескольких ошибок в одном месте.

Я полагаю, что проблема заключалась в том, что, хотя простое выполнение if err != nil { return err} в некоторых случаях может быть уместным, обычно рекомендуется декорировать ошибку перед возвратом. И это предложение, кажется, касается предыдущего и мало что делает для последнего. По сути, это означает, что людям будет предложено использовать шаблон легкого возврата.

@agnivade Вы правы, это предложение никак не помогает с оформлением ошибок (но рекомендует использовать defer ). Одна из причин заключается в том, что языковые механизмы для этого уже существуют. Как только требуется декорирование ошибок, особенно для отдельных ошибок, дополнительный объем исходного текста для кода оформления делает if менее обременительным по сравнению с ним. Это случаи, когда украшение не требуется или украшение всегда одно и то же, когда шаблон становится видимой неприятностью и затем отвлекает от важного кода.

Людям уже рекомендуется использовать шаблон с легким возвратом, try или нет try , просто писать меньше. Подумайте об этом, _единственный способ поощрения оформления ошибок - это сделать его обязательным_, потому что независимо от того, какой язык доступен, оформление ошибок потребует больше работы.

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

Я не уверен, что мы хотим зайти так далеко. Позвольте мне еще раз заявить, что большое количество прекрасного кода, скажем, внутренностей библиотеки, не нужно украшать ошибки повсюду. Например, можно просто распространять ошибки и украшать их непосредственно перед тем, как они покинут точки входа API. (На самом деле, приукрашивание их повсюду приведет только к чрезмерно украшенным ошибкам, которые, когда истинные виновники скрыты, затрудняют поиск важных ошибок; очень похоже на то, что чрезмерно подробное ведение журнала может затруднить понимание того, что происходит на самом деле).

Я думаю, мы также можем добавить функцию catch , которая будет хорошей парой, поэтому:

func a() int {
  x := randInt()
  // let's assume that this is what recruiters should "fix" for us
  // or this happens in 3rd-party package.
  if x % 1337 != 0 {
    panic("not l33t enough")
  }
  return x
}

func b() error {
  // if a() panics, then x = 0, err = error{"not l33t enough"}
  x, err := catch(a())
  if err != nil {
    return err
  }
  sendSomewhereElse(x)
  return nil
}

// which could be simplified even further

func c() error {
  x := try(catch(a()))
  sendSomewhereElse(x)
  return nil
}

в этом примере catch() будет recover() паникой и return ..., panicValue .
конечно, у нас есть очевидный крайний случай, когда у нас есть функция, которая также возвращает ошибку. в этом случае, я думаю, было бы удобно просто передать значение ошибки.

так что, по сути, вы можете затем использовать catch() для фактического восстановления паники() и превращения их в ошибки.
это выглядит довольно забавно для меня, потому что Go на самом деле не имеет исключений, но в этом случае у нас есть довольно аккуратный шаблон try()-catch(), который также не должен взорвать всю вашу кодовую базу чем-то вроде Java ( catch(Throwable) в Main + throws LiterallyAnything ). вы можете легко обрабатывать чьи-то паники, как это были обычные ошибки. В настоящее время у меня около 6 миллионов LoC в Go в моем текущем проекте, и я думаю, что это упростит ситуацию, по крайней мере, для меня.

@griesemer Спасибо за подведение итогов обсуждения.

Я заметил, что здесь не хватает одного момента: некоторые люди утверждали, что нам следует подождать с этой функцией, пока у нас не появятся дженерики, которые, как мы надеемся, позволят нам решить эту проблему более элегантным способом.

Кроме того, мне также нравится предложение @velovix , и хотя я понимаю, что это поднимает несколько вопросов, как описано в спецификации, я думаю, что на них можно легко ответить разумным образом, как это уже сделал @velovix .

Например:

• Что произойдет, если предоставить значение функции (не нулевой литерал), и это значение функции (хранящееся в переменной) окажется равным нулю? => Не обрабатывать ошибку, и точка. Это полезно, если обработка ошибок зависит от контекста, а переменная обработчика устанавливается в зависимости от того, требуется ли обработка ошибок. Это не баг, а скорее фича. :)

• Другим аргументом было то, что лучше иметь объявление обработчика ошибок на верхнем уровне, потому что это ясно показывает, что функция действительно обрабатывает ошибки. => Итак, определите обработчик ошибок в верхней части функции как именованную функцию закрытия и используйте ее, чтобы также было совершенно ясно, что ошибка должна быть обработана. Это не серьезная проблема, скорее требование стиля.

Какие еще опасения были? Я почти уверен, что на все они можно ответить одинаково разумным образом.

Наконец, как вы говорите, «одним из способов подсластить сделку было бы разрешить что-то вроде try (или любую аналогичную нотацию быстрого доступа) только в том случае, если где-то указан явный (возможно, пустой) обработчик». Я думаю, что если мы собираемся продолжить работу над этим предложением, нам действительно следует зайти так далеко, чтобы поощрить правильную обработку ошибок "явное лучше, чем неявное".

@griesemer

Что произойдет, если вы предоставите значение функции (не нулевой литерал), и это значение функции (хранящееся в переменной) окажется равным нулю? По аналогии с явным значением nil никакой обработки не требуется. Но другие могут возразить, что это ошибка в коде.

Теоретически это кажется потенциальной ошибкой, хотя мне трудно осмыслить разумную ситуацию, когда обработчик случайно окажется равным нулю. Я предполагаю, что обработчики чаще всего будут либо исходить из служебной функции, определенной в другом месте, либо как замыкание, определенное в самой функции. Ни один из них, вероятно, не станет нулевым неожиданно. Теоретически у вас может быть сценарий, в котором функции-обработчики передаются в качестве аргументов другим функциям, но, на мой взгляд, это кажется довольно надуманным. Возможно, есть такая закономерность, о которой я не знаю.

Другим аргументом было то, что лучше иметь объявление обработчика ошибок на верхнем уровне, потому что это ясно показывает, что функция действительно обрабатывает ошибки. Следовательно, defer .

Как упомянул @beoran , определение обработчика как закрытия в верхней части функции будет выглядеть очень похоже по стилю, и я лично ожидаю, что люди будут использовать обработчики чаще всего. Хотя я ценю ясность, полученную благодаря тому факту, что все функции, обрабатывающие ошибки, будут использовать defer , это может стать менее ясным, когда функция должна изменить свою стратегию обработки ошибок на полпути вниз по функции. Затем будет два defer , на которые нужно посмотреть, и читателю придется рассуждать о том, как они будут взаимодействовать друг с другом. Это ситуация, когда я считаю, что аргумент обработчика был бы более понятным и эргономичным, и я действительно думаю, что это будет _относительно_ распространенный сценарий.

Можно ли заставить его работать без скобок?

То есть что-то вроде:
a := try func(some)

@Cyberax - Как уже упоминалось выше, очень важно внимательно прочитать проектную документацию перед публикацией. Так как это тема с большим трафиком, на которую подписано много людей.

В документе подробно обсуждаются операторы и функции.

Мне это нравится намного больше, чем августовская версия.

Я думаю, что большую часть негативных отзывов, которые не являются прямым противодействием возврату без ключевого слова return , можно резюмировать в двух пунктах:

1. людям не нравятся именованные параметры результата, которые в большинстве случаев потребуются
2. не рекомендуется добавлять подробный контекст к ошибкам

См., например:

• https://github.com/golang/go/issues/32437#issuecomment-498937169
• https://github.com/golang/go/issues/32437#issuecomment-498967099
• https://github.com/golang/go/issues/32437#issuecomment-499194787
• https://github.com/golang/go/issues/32437#issuecomment-499309304

Опровержение этих двух возражений соответственно:

1. «мы решили, что [названные параметры результата] в порядке»
2. "Никто не заставит вас использовать try " / это не подходит для 100% случаев

Мне действительно нечего сказать о 1 (я не очень сильно к этому отношусь). Но в отношении 2 я хотел бы отметить, что в августовском предложении этой проблемы не было, большинство встречных предложений также не имеют этой проблемы.

В частности, ни встречное предложение tryf (которое было опубликовано независимо дважды в этой теме), ни встречное предложение try(X, handlefn) (которое было частью итераций дизайна) не имели этой проблемы.

Я думаю, трудно спорить с тем, что try как есть оттолкнет людей от декорирования ошибок соответствующим контекстом и приведет к единому общему оформлению ошибки для каждой функции.

По этим причинам я думаю, что стоит попытаться решить эту проблему, и я хочу предложить возможное решение:

1. В настоящее время параметр defer может быть только вызовом функции или метода. Разрешить defer также иметь имя функции или функциональный литерал, т.е.

defer func(...) {...}
defer packageName.functionName

1. Когда panic или deferreturn сталкиваются с этим типом отсрочки, они вызывают функцию, передающую нулевое значение для всех своих параметров.

2. Разрешить try иметь более одного параметра

3. Когда try встречает новый тип отсрочки, она вызывает функцию, передавая указатель на значение ошибки в качестве первого параметра, за которым следуют все собственные параметры try , кроме первого.

Например, учитывая:

func errorfn() error {
    return errors.New("an error")
}


func f(fail bool) {
    defer func(err *error, a, b, c int) {
        fmt.Printf("a=%d b=%d c=%d\n", a, b, c)
    }
    if fail {
        try(errorfn, 1, 2, 3)
    }
}

произойдет следующее:

f(false)        // prints "a=0 b=0 c=0"
f(true)         // prints "a=1 b=2 c=3"

Код в https://github.com/golang/go/issues/32437#issuecomment -499309304 @zeebo можно было бы переписать как:

func (c *Config) Build() error {
    defer func(err *error, msg string, args ...interface{}) {
        if *err == nil || msg == "" {
            return
        }
        *err = errors.WithMessagef(err, msg, args...)
    }
    pkgPath := try(c.load(), "load config dir")

    b := bytes.NewBuffer(nil)
    try(templates.ExecuteTemplate(b, "main", c), "execute main template")

    buf := try(format.Source(b.Bytes()), "format main template")

    target := fmt.Sprintf("%s.go", filename(pkgPath))
    try(ioutil.WriteFile(target, buf, 0644), "write file %s", target)
    // ...
}

И определение ErrorHandlef как:

func HandleErrorf(err *error, format string, args ...interface{}) {
        if *err != nil && format != "" {
                *err = fmt.Errorf(format + ": %v", append(args, *err)...)
        }
}

предоставит всем столь востребованный tryf бесплатно, не вытягивая строки формата в стиле fmt в основной язык.

Эта функция обратно совместима, поскольку defer не допускает использования функциональных выражений в качестве аргумента. Он не вводит новые ключевые слова.
Изменения, которые необходимо внести для его реализации, в дополнение к описанным в https://github.com/golang/proposal/blob/master/design/32437-try-builtin.md :

1. научить парсер новому виду отсрочки
2. измените проверку типов, чтобы проверить, что внутри функции все отсрочки, которые имеют функцию в качестве параметра (вместо вызова), также имеют одинаковую сигнатуру
3. измените средство проверки типов, чтобы убедиться, что параметры, переданные в try , соответствуют сигнатуре функций, переданных в defer
4. изменить бэкэнд (?), чтобы сгенерировать соответствующий вызов deferproc
5. изменить реализацию try , чтобы копировать его аргументы в аргументы отложенного вызова, когда он встречает вызов, отложенный новым видом отложенного вызова.

После сложностей чернового проекта check/handle я был приятно удивлен, увидев, что это гораздо более простое и прагматичное предложение получило распространение, хотя я разочарован тем, что против него было так много возражений.

По общему признанию, большая часть возражений исходит от людей, которые вполне довольны нынешним многословием (вполне разумная позиция) и которые, по-видимому, не приветствовали бы никакие предложения по его смягчению. Для всех остальных, я думаю, это предложение идеально подходит для того, чтобы быть простым и похожим на Go, не пытаться сделать слишком много и хорошо согласовываться с существующими методами обработки ошибок, к которым вы всегда можете вернуться, если try не сделал именно то, что вы хотели.

Что касается некоторых конкретных моментов:

1. Единственное, что мне не нравится в этом предложении, это необходимость иметь именованный параметр возврата ошибки при использовании defer , но, сказав это, я не могу придумать никакого другого решения, которое не противоречило бы как работает остальная часть языка. Поэтому я думаю, что нам просто придется согласиться с этим, если предложение будет принято.

2. Жаль, что try плохо работает с пакетом тестирования для функций, которые не возвращают значение ошибки. Мое собственное предпочтительное решение этой проблемы состояло бы в том, чтобы иметь вторую встроенную функцию (возможно, ptry или must ), которая всегда паниковала, а не возвращалась при обнаружении ненулевой ошибки и, следовательно, могла быть используется с вышеупомянутыми функциями (включая main ). Хотя эта идея была отклонена в текущей итерации предложения, у меня сложилось впечатление, что это был «близкий вызов», и поэтому он может подлежать пересмотру.

3. Я думаю, что людям было бы трудно понять, что делают go try(f) или defer try(f) , и поэтому лучше просто запретить их вообще.

4. Я согласен с теми, кто думает, что существующие методы обработки ошибок выглядели бы менее многословными, если бы go fmt не переписывал однострочные операторы if . Лично я бы предпочел простое правило, согласно которому это будет разрешено для _любого_ одиночного оператора if , связанного с обработкой ошибок или нет. На самом деле я никогда не мог понять, почему в настоящее время это не разрешено при написании однострочных функций, где тело помещается в ту же строку, что и объявление.

В случае ошибок декорирования

func myfunc()( err error){
try(thing())
defer func(){
err = errors.Wrap(err,"more context")
}()
}

Это кажется значительно более многословным и болезненным, чем существующие парадигмы, и не таким лаконичным, как проверка/обработка. Вариант try() без упаковки более лаконичен, но создается впечатление, что люди в конечном итоге будут использовать сочетание try и возвращать простые ошибки. Я не уверен, что мне нравится идея смешивания попыток и простых возвратов ошибок, но я полностью увлекся декорированием ошибок (и с нетерпением жду Is/As). Заставьте меня думать, что, хотя это синтаксически аккуратно, я не уверен, что хотел бы на самом деле использовать его. check/handle чувствовал что-то, что я бы принял более тщательно.

Мне очень нравится простота этого и подход «делай одно дело хорошо». В моем интерпретаторе GoAWK это было бы очень полезно — у меня есть около 100 конструкций if err != nil { return nil } , которые можно было бы упростить и привести в порядок, и это в довольно небольшой кодовой базе.

Я прочитал обоснование предложения сделать его встроенным, а не ключевым словом, и оно сводится к тому, что не нужно настраивать синтаксический анализатор. Но разве это не относительно небольшая проблема для разработчиков компиляторов и инструментальных средств, в то время как лишние скобки и проблемы с читабельностью типа «это выглядит как функция, но не является читабельностью» будут чем-то, что все программисты Go и код- Читателям приходится терпеть. На мой взгляд, аргумент (извините? :-) о том, что «но panic() управляет потоком», не работает, потому что panic и recovery по своей природе исключительны , тогда как try() будут быть нормальной обработкой ошибок и потоком управления.

Я был бы определенно признателен, даже если бы это осталось как есть, но я бы предпочел, чтобы нормальный поток управления был понятным, т. Е. Выполнялся с помощью ключевого слова.

Я за это предложение. Это позволяет избежать моей самой большой оговорки по поводу предыдущего предложения: неортогональности handle по отношению к defer .

Я хотел бы упомянуть два аспекта, которые, как мне кажется, не были освещены выше.

Во-первых, несмотря на то, что это предложение не упрощает добавление контекстно-зависимого текста ошибки к ошибке, оно _делает_ упрощает добавление к ошибке информации для отслеживания ошибок фрейма стека: https://play.golang.org/p /YL1MoqR08E6

Во-вторых, try , возможно, является справедливым решением большинства проблем, лежащих в основе https://github.com/golang/go/issues/19642. Чтобы взять пример из этой проблемы, вы можете использовать try , чтобы каждый раз не записывать все возвращаемые значения. Это также потенциально полезно при возврате типов структур по значению с длинными именами.

func (f *Font) viewGlyphData(b *Buffer, x GlyphIndex) (buf []byte, offset, length uint32, err error) {
    xx := int(x)
    if f.NumGlyphs() <= xx {
        try(ErrNotFound)
    }
    i := f.cached.locations[xx+0]
    j := f.cached.locations[xx+1]
    if j < i {
        try(errInvalidGlyphDataLength)
    }
    if j-i > maxGlyphDataLength {
        try(errUnsupportedGlyphDataLength)
    }
    buf, err = b.view(&f.src, int(i), int(j-i))
    return buf, i, j - i, err
}

Мне тоже нравится это предложение.

И у меня есть просьба.

Как и make , можем ли мы позволить try принимать переменное количество параметров

• попробовать (ф):
  как указано выше.
  возвращаемое значение ошибки является обязательным (как последний возвращаемый параметр).
  НАИБОЛЕЕ РАСПРОСТРАНЕННАЯ МОДЕЛЬ
• try(f, doPanic bool):
  как указано выше, но если doPanic, то вместо возврата будет panic(err).
  В этом режиме нет необходимости возвращать значение ошибки.
• попробуйте (ф, фн):
  как указано выше, но вызовите fn(err) перед возвратом.
  В этом режиме нет необходимости возвращать значение ошибки.

Таким образом, это одна встроенная функция, которая может обрабатывать все варианты использования, оставаясь при этом явной. Его преимущества:

• всегда явно - не нужно делать вывод, следует ли паниковать или установить ошибку и вернуться
• поддерживает контекстно-зависимый обработчик (но без цепочки обработчиков)
• поддерживает варианты использования, в которых нет возвращаемой переменной ошибки
• поддерживает семантику must(...)

Хотя повторяющиеся if err !=nil { return ... err } — это, безусловно, уродливое заикание, я с такими
которые думают, что предложение try() очень плохо читается и несколько неясно.
Использование именованных возвратов также проблематично.

Если такая уборка необходима, почему бы не использовать try(err) в качестве синтаксического сахара для
if err !=nil { return err } :

file, err := os.Open("file.go")
try(err)

для

file, err := os.Open("file.go")
if err != nil {
   return err
}

И если есть более одного возвращаемого значения, try(err) может return t1, ... tn, err
где t1, ... tn — нулевые значения других возвращаемых значений.

Это предложение может устранить необходимость в именованных возвращаемых значениях и быть,
на мой взгляд, проще для понимания и читабельнее.

Еще лучше, я думаю, будет:

file, try(err) := os.Open("file.go")

Или даже

file, err? := os.Open("file.go")

Это последнее обратно совместимо (? в настоящее время не разрешено в идентификаторах).

(Это предложение связано с https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback#recurring-themes. Но примеры повторяющихся тем кажутся другими, потому что это было на этапе, когда явный дескриптор все еще обсуждался вместо того, чтобы оставить это к отсрочке.)

Спасибо команде go за это продуманное и интересное предложение.

Комментарий @rogpeppe , если try автоматически добавляет кадр стека, а не я, я согласен с тем, что это препятствует добавлению контекста.

@aarzilli - Итак, согласно вашему предложению, является ли предложение отсрочки обязательным каждый раз, когда мы даем дополнительные параметры tryf ?

Что произойдет, если я сделаю

try(ioutil.WriteFile(target, buf, 0644), "write file %s", target)

и не писать функцию отсрочки?

@агниваде

Что произойдет, если я сделаю (...) и не напишу функцию отсрочки?

ошибка проверки типа.

На мой взгляд, использование try , чтобы избежать записи всех возвращаемых значений, на самом деле является еще одним ударом по нему.

func (f *Font) viewGlyphData(b *Buffer, x GlyphIndex) (buf []byte, offset, length uint32, err error) {
    xx := int(x)
    if f.NumGlyphs() <= xx {
        try(ErrNotFound)
    }
    //...

Я полностью понимаю желание избежать необходимости выписывать return nil, 0, 0, ErrNotFound , но я бы предпочел решить это каким-то другим способом.

Слово try не означает «возврат». И вот как это используется здесь. На самом деле я бы предпочел, чтобы предложение изменилось так, чтобы try не могло принимать значение error напрямую, потому что я не хочу, чтобы кто-либо когда-либо писал такой код ^^ . Неправильно читается. Если бы вы показали этот код новичку, он бы понятия не имел, что делает эта попытка.

Если нам нужен способ просто вернуть значения по умолчанию и значение ошибки, давайте решим это отдельно. Может быть, другой встроенный, как

return default(ErrNotFound)

По крайней мере, это читается с какой-то логикой.

Но не будем злоупотреблять try для решения какой-то другой задачи.

@natefinch , если встроенная функция try названа check , как в исходном предложении, это будет check(err) , что читается значительно лучше, imo.

Отложив это в сторону, я не знаю, действительно ли злоупотреблением является написать try(err) . Он выпадает из определения начисто. Но, с другой стороны, это также означает, что это законно:

a, b := try(1, f(), err)

Я думаю, моя главная проблема с try заключается в том, что на самом деле это просто panic , который поднимается только на один уровень... за исключением того, что в отличие от паники, это выражение, а не оператор, поэтому вы можете скрыть это где-то в середине заявления. Это почти хуже , чем паника.

@natefinch Если вы представляете это как панику, которая поднимается на один уровень, а затем делает другие вещи, это кажется довольно грязным. Однако я осмысливаю это по-другому. Функции, которые возвращают ошибки в Go, фактически возвращают Result, если использовать терминологию Rust. try — это утилита, которая распаковывает результат и либо возвращает «результат ошибки», если error != nil , либо распаковывает часть T результата, если error == nil .

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

@ugorji Вариант try(f, bool) , который вы предлагаете, звучит как must из #32219.

@ugorji Вариант try(f, bool) , который вы предлагаете, звучит как must из #32219.

Да это так. Я просто чувствовал, что все 3 случая можно обработать с помощью единственной встроенной функции и элегантно удовлетворить все варианты использования.

Поскольку try() уже является волшебным и знает о возвращаемом значении ошибки, можно ли его расширить, чтобы он также возвращал указатель на это значение при вызове в нулевой (нулевой аргумент) форме? Это устранило бы необходимость в именованных возвратах и, я полагаю, помогло бы визуально сопоставить, откуда ожидается появление ошибки в операторах отсрочки. Например:

func foo() error {
  defer fmt.HandleErrorf(try(), "important foo context info")
  try(bar())
  try(baz())
  try(etc())
}

@угоржи
Я думаю, что логическое значение в try(f, bool) затруднит чтение и легко пропустит. Мне нравится ваше предложение, но в случае паники я думаю, что пользователям можно было бы оставить возможность написать это внутри обработчика из вашего третьего маркера, например try(f(), func(err error) { panic('at the disco'); }) , это делает его более явным для пользователей, чем скрытый try(f(), true) , которую легко не заметить, и я не думаю, что встроенные функции должны вызывать панику.

@угоржи
Я думаю, что логическое значение в try(f, bool) затруднит чтение и легко пропустит. Мне нравится ваше предложение, но в случае паники я думаю, что пользователям можно было бы оставить возможность написать это внутри обработчика из вашего третьего маркера, например try(f(), func(err error) { panic('at the disco'); }) , это делает его более явным для пользователей, чем скрытый try(f(), true) , которую легко не заметить, и я не думаю, что встроенные функции должны вызывать панику.

При дальнейшем размышлении я склонен согласиться с вашей позицией и вашими рассуждениями, и это все еще выглядит элегантно, как острота.

@patrick-nyt является еще одним сторонником _синтаксиса присваивания_ для запуска нулевого теста, в https://github.com/golang/go/issues/32437#issuecomment -499533464.

Эта концепция появляется в 13 отдельных ответах на предложение проверить/обработать
https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback#recurring -темы

f, ?return := os.Open(...)
f, ?panic  := os.Open(...)

Почему? Потому что он читается как Go 1, а try() и check — нет.

https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md#draft-дизайн

Одно из возражений против try , по-видимому, состоит в том, что это выражение. Вместо этого предположим, что существует унарный постфиксный оператор ? , который означает возврат, если не nil. Вот стандартный пример кода (при условии, что предложенный мной отложенный пакет добавлен):

func CopyFile(src, dst string) error {
    var err error // Don't need a named return because err is explicitly named
    defer deferred.Annotate(&err, "copy %s %s", src, dst)

    r, err := os.Open(src)
    err?
    defer deferred.AnnotatedExec(&err, r.Close)

    w, err := os.Create(dst)
    err?
    defer deferred.AnnotatedExec(&err, r.Close)

    defer deferred.Cond(&err, func(){ os.Remove(dst) })
    _, err = io.Copy(w, r)

    return err
}

Пример pgStore:

func (p *pgStore) DoWork() error {
    tx, err := p.handle.Begin()
    err?

    defer deferred.Cond(&err, func(){ tx.Rollback() })

    var res int64 
    err = tx.QueryRow(`INSERT INTO table (...) RETURNING c1`, ...).Scan(&res)
    // tricky bit: this would not change the value of err 
    // but the deferred.Cond would still be triggered by err being set before
    deferred.Format(err, "insert table")?

    _, err = tx.Exec(`INSERT INTO table2 (...) VALUES ($1)`, res)
    deferred.Format(err, "insert table2")?

    return tx.Commit()
}

Мне нравится это от @jargv :

Поскольку try() уже является волшебным и знает о возвращаемом значении ошибки, можно ли его расширить, чтобы он также возвращал указатель на это значение при вызове в нулевой форме (нулевой аргумент)? Это устранило бы необходимость в именованных возвратах

Но вместо того, чтобы перегружать имя try на основе количества аргументов, я думаю, что может быть другая встроенная магия, скажем, reterr или что-то в этом роде.

Я ознакомился с некоторыми очень часто используемыми пакетами, ища код go, который "страдает" от обработки ошибок, но, должно быть, был хорошо продуман перед написанием, пытаясь понять, что "магия" могла бы сделать предложенная функция try().
В настоящее время, если я не понял предложение неправильно, многие из них (например, не сверхбазовая обработка ошибок) не получат многого или должны будут остаться со «старым» стилем обработки ошибок.
Пример из сети/http/request.go:

func (r *Request) write(w io.Writer, usingProxy bool, extraHeaders Header, waitForContinue func() bool) (err error) {
`

trace := httptrace.ContextClientTrace(r.Context())
if trace != nil && trace.WroteRequest != nil {
    defer func() {
        trace.WroteRequest(httptrace.WroteRequestInfo{
            Err: err,
        })
    }()
}

// Find the target host. Prefer the Host: header, but if that
// is not given, use the host from the request URL.
//
// Clean the host, in case it arrives with unexpected stuff in it.
host := cleanHost(r.Host)
if host == "" {
    if r.URL == nil {
        return errMissingHost
    }
    host = cleanHost(r.URL.Host)
}

// According to RFC 6874, an HTTP client, proxy, or other
// intermediary must remove any IPv6 zone identifier attached
// to an outgoing URI.
host = removeZone(host)

ruri := r.URL.RequestURI()
if usingProxy && r.URL.Scheme != "" && r.URL.Opaque == "" {
    ruri = r.URL.Scheme + "://" + host + ruri
} else if r.Method == "CONNECT" && r.URL.Path == "" {
    // CONNECT requests normally give just the host and port, not a full URL.
    ruri = host
    if r.URL.Opaque != "" {
        ruri = r.URL.Opaque
    }
}
if stringContainsCTLByte(ruri) {
    return errors.New("net/http: can't write control character in Request.URL")
}
// TODO: validate r.Method too? At least it's less likely to
// come from an attacker (more likely to be a constant in
// code).

// Wrap the writer in a bufio Writer if it's not already buffered.
// Don't always call NewWriter, as that forces a bytes.Buffer
// and other small bufio Writers to have a minimum 4k buffer
// size.
var bw *bufio.Writer
if _, ok := w.(io.ByteWriter); !ok {
    bw = bufio.NewWriter(w)
    w = bw
}

_, err = fmt.Fprintf(w, "%s %s HTTP/1.1\r\n", valueOrDefault(r.Method, "GET"), ruri)
if err != nil {
    return err
}

// Header lines
_, err = fmt.Fprintf(w, "Host: %s\r\n", host)
if err != nil {
    return err
}
if trace != nil && trace.WroteHeaderField != nil {
    trace.WroteHeaderField("Host", []string{host})
}

// Use the defaultUserAgent unless the Header contains one, which
// may be blank to not send the header.
userAgent := defaultUserAgent
if r.Header.has("User-Agent") {
    userAgent = r.Header.Get("User-Agent")
}
if userAgent != "" {
    _, err = fmt.Fprintf(w, "User-Agent: %s\r\n", userAgent)
    if err != nil {
        return err
    }
    if trace != nil && trace.WroteHeaderField != nil {
        trace.WroteHeaderField("User-Agent", []string{userAgent})
    }
}

// Process Body,ContentLength,Close,Trailer
tw, err := newTransferWriter(r)
if err != nil {
    return err
}
err = tw.writeHeader(w, trace)
if err != nil {
    return err
}

err = r.Header.writeSubset(w, reqWriteExcludeHeader, trace)
if err != nil {
    return err
}

if extraHeaders != nil {
    err = extraHeaders.write(w, trace)
    if err != nil {
        return err
    }
}

_, err = io.WriteString(w, "\r\n")
if err != nil {
    return err
}

if trace != nil && trace.WroteHeaders != nil {
    trace.WroteHeaders()
}

// Flush and wait for 100-continue if expected.
if waitForContinue != nil {
    if bw, ok := w.(*bufio.Writer); ok {
        err = bw.Flush()
        if err != nil {
            return err
        }
    }
    if trace != nil && trace.Wait100Continue != nil {
        trace.Wait100Continue()
    }
    if !waitForContinue() {
        r.closeBody()
        return nil
    }
}

if bw, ok := w.(*bufio.Writer); ok && tw.FlushHeaders {
    if err := bw.Flush(); err != nil {
        return err
    }
}

// Write body and trailer
err = tw.writeBody(w)
if err != nil {
    if tw.bodyReadError == err {
        err = requestBodyReadError{err}
    }
    return err
}

if bw != nil {
    return bw.Flush()
}
return nil

}
`

или как используется в тщательном тесте, таком как pprof/profile/profile_test.go:
`
func checkAggregation(prof *Profile, a *aggTest) error {
// Проверяем, что общее количество выборок для строк сохранилось.
всего: = int64 (0)

samples := make(map[string]bool)
for _, sample := range prof.Sample {
    tb := locationHash(sample)
    samples[tb] = true
    total += sample.Value[0]
}

if total != totalSamples {
    return fmt.Errorf("sample total %d, want %d", total, totalSamples)
}

// Check the number of unique sample locations
if a.rows != len(samples) {
    return fmt.Errorf("number of samples %d, want %d", len(samples), a.rows)
}

// Check that all mappings have the right detail flags.
for _, m := range prof.Mapping {
    if m.HasFunctions != a.function {
        return fmt.Errorf("unexpected mapping.HasFunctions %v, want %v", m.HasFunctions, a.function)
    }
    if m.HasFilenames != a.fileline {
        return fmt.Errorf("unexpected mapping.HasFilenames %v, want %v", m.HasFilenames, a.fileline)
    }
    if m.HasLineNumbers != a.fileline {
        return fmt.Errorf("unexpected mapping.HasLineNumbers %v, want %v", m.HasLineNumbers, a.fileline)
    }
    if m.HasInlineFrames != a.inlineFrame {
        return fmt.Errorf("unexpected mapping.HasInlineFrames %v, want %v", m.HasInlineFrames, a.inlineFrame)
    }
}

// Check that aggregation has removed finer resolution data.
for _, l := range prof.Location {
    if !a.inlineFrame && len(l.Line) > 1 {
        return fmt.Errorf("found %d lines on location %d, want 1", len(l.Line), l.ID)
    }

    for _, ln := range l.Line {
        if !a.fileline && (ln.Function.Filename != "" || ln.Line != 0) {
            return fmt.Errorf("found line %s:%d on location %d, want :0",
                ln.Function.Filename, ln.Line, l.ID)
        }
        if !a.function && (ln.Function.Name != "") {
            return fmt.Errorf(`found file %s location %d, want ""`,
                ln.Function.Name, l.ID)
        }
    }
}

return nil

}
`
Это два примера, которые я могу придумать, в которых можно было бы сказать: «Мне нужен лучший вариант обработки ошибок».

Может ли кто-нибудь продемонстрировать, как это улучшится с помощью try() ?

Я в основном за это предложение.

Моя главная проблема, которую я разделяю со многими комментаторами, связана с именованными параметрами результата. Текущее предложение, безусловно, поощряет более широкое использование именованных параметров результата, и я думаю, что это было бы ошибкой. Я не думаю, что это просто вопрос стиля, как говорится в предложении: именованные результаты — это тонкая особенность языка, которая во многих случаях делает код более подверженным ошибкам или менее понятным. После примерно 8 лет чтения и написания кода Go я действительно использую именованные параметры результата только для двух целей:

• Документирование параметров результата
• Манипулирование значением результата (обычно error ) внутри отсрочки

Чтобы рассмотреть эту проблему с нового направления, вот идея, которая, как мне кажется, не совсем согласуется с чем-либо, что обсуждалось в проектном документе или в этой ветке комментариев к проблеме. Назовем это «отсрочка ошибок»:

Разрешить использование defer для вызова функций с неявным параметром ошибки.

Итак, если у вас есть функция

func f(err error, t1 T1, t2 T2, ..., tn Tn) error

Затем в функции g , где последний результирующий параметр имеет тип error (т. е. любая функция, в которой может использоваться try ), вызов f может быть отложено следующим образом:

func g() (R0, R0, ..., error) {
    defer f(t0, t1, ..., tn) // err is implicit
}

Семантика error-defer:

1. Отложенный вызов f вызывается с последним параметром результата g в качестве первого входного параметра f
2. f вызывается только в том случае, если эта ошибка не равна нулю
3. Результат f присваивается последнему параметру результата g

Таким образом, чтобы использовать пример из старого документа по разработке обработки ошибок, используя error-defer и try, мы могли бы сделать

func printSum(a, b string) error {
    defer func(err error) error {
        return fmt.Errorf("printSum(%q + %q): %v", a, b, err)
    }()
    x := try(strconv.Atoi(a))
    y := try(strconv.Atoi(b))
    fmt.Println("result:", x+y)
    return nil
}

Вот как будет работать HandleErrorf:

func printSum(a, b string) error {
    defer handleErrorf("printSum(%q + %q)", a, b)
    x := try(strconv.Atoi(a))
    y := try(strconv.Atoi(b))
    fmt.Println("result:", x+y)
    return nil
}

func handleErrorf(err error, format string, args ...interface{}) error {
    return fmt.Errorf(format+": %v", append(args, err)...)
}

Один крайний случай, который необходимо проработать, — это то, как обрабатывать случаи, когда неоднозначно, какую форму отсрочки мы используем. Я думаю, что это происходит только с (очень необычными) функциями с такими сигнатурами:

func(error, ...error) error

Кажется разумным сказать, что этот случай обрабатывается без отсрочки ошибок (и это сохраняет обратную совместимость).

Если подумать об этой идее последние пару дней, то это немного волшебно, но отказ от именованных параметров результата является большим преимуществом в ее пользу. Поскольку try поощряет более широкое использование defer для манипулирования ошибками, есть некоторый смысл в том, что defer можно расширить, чтобы он лучше подходил для этой цели. Кроме того, существует определенная симметрия между try и задержкой ошибок.

Наконец, отложенные ошибки сегодня полезны даже без попытки, поскольку они заменяют использование именованных параметров результата для управления возвратами ошибок. Например, вот отредактированная версия реального кода:

// GetMulti retrieves multiple files through the cache at once and returns its
// results as a slice parallel to the input.
func (c *FileCache) GetMulti(keys []string) (_ []*File, err error) {
    files := make([]*file, len(keys))

    defer func() {
        if err != nil {
            // Return any successfully retrieved files.
            for _, f := range files {
                if f != nil {
                    c.put(f)
                }
            }
        }
    }()

    // ...
}

С отсрочкой ошибки это становится:

// GetMulti retrieves multiple files through the cache at once and returns its
// results as a slice parallel to the input.
func (c *FileCache) GetMulti(keys []string) ([]*File, error) {
    files := make([]*file, len(keys))

    defer func(err error) error {
        // Return any successfully retrieved files.
        for _, f := range files {
            if f != nil {
                c.put(f)
            }
        }
        return err
    }()

    // ...
}

@beoran Что касается вашего комментария о том, что нам следует подождать дженериков. Здесь дженерики не помогут — читайте FAQ .

Что касается ваших предложений по поведению @velovix с двумя аргументами try по умолчанию: как я уже говорил , ваше представление о том, что является очевидно разумным выбором, является чьим-то кошмаром.

Могу ли я предложить продолжить эту дискуссию после того, как будет достигнут широкий консенсус в отношении того, что try с явным обработчиком ошибок является лучшей идеей, чем текущая минимальная try . В этот момент имеет смысл обсудить тонкости такой конструкции.

(Если на то пошло, мне нравится иметь обработчик. Это одно из наших предыдущих предложений. И если мы примем try как есть, мы все равно сможем перейти к try с обработчиком в прямом направлении. -совместимый способ - по крайней мере, если обработчик необязателен. Но давайте пошагово.)

@aarzilli Спасибо за ваше предложение .

Пока ошибки декорирования необязательны, люди будут склоняться к тому, чтобы их не делать (в конце концов, это дополнительная работа). См. также мой комментарий здесь .

Итак, я не думаю, что предложенный try _отпугивает_ людей от ошибок декорирования (они уже отговариваются даже с if по вышеуказанной причине); дело в том, что try не _поощряет_ это.

(Один из способов поощрения этого состоит в том, чтобы связать его с try : try можно использовать только в том случае, если вы также украшаете ошибку или явно отказываетесь от нее.)

Но вернемся к вашим предложениям: я думаю, вы вводите здесь гораздо больше механизмов. Изменение семантики defer просто для того, чтобы она лучше работала для try , не является чем-то, что мы хотели бы рассматривать, если только эти изменения defer не будут полезны в более общем плане. Кроме того, ваше предложение связывает defer вместе с try и, таким образом, делает оба этих механизма менее ортогональными; то, чего мы хотели бы избежать.

Но что более важно, я сомневаюсь, что вы захотите заставить всех писать defer только для того, чтобы они могли использовать try . Но без этого мы возвращаемся к исходной точке: люди склоняются к тому, чтобы не украшать ошибки.

(Если уж на то пошло, мне нравится иметь обработчик. Это одно из наших предыдущих предложений. И если мы примем попытку как есть, мы все равно сможем перейти к попытке с обработчиком, совместимому с предыдущими версиями — по крайней мере, если обработчик необязательно. Но давайте пошагово.)

Конечно, возможно, многоэтапный подход — это путь. Если в будущем мы добавим необязательный аргумент обработчика, можно будет создать инструментарий для предупреждения автора о необработанном try в том же духе, что и инструмент errcheck . В любом случае, я ценю ваши отзывы!

@alanfo Спасибо за положительный отзыв .

По пунктам, которые вы подняли:

1) Если единственная проблема с try заключается в том, что нужно указать имя возврата ошибки, чтобы мы могли декорировать ошибку через defer , я думаю, что у нас все хорошо. Если именование результата окажется реальной проблемой, мы могли бы решить эту проблему. Простым механизмом, который я могу придумать, будет предварительно объявленная переменная, которая является псевдонимом для результата ошибки (представьте, что это содержит ошибку, которая вызвала самый последний try ). Могут быть лучшие идеи. Мы не предлагали этого, потому что в языке уже есть механизм, который должен назвать результат.
2) try и тестирование: это можно решить и заставить работать. См. подробный документ.
3) Это явно рассматривается в подробном документе.
4) Подтверждено.

@benhoyt Спасибо за положительный отзыв .

Если основным аргументом против этого предложения является тот факт, что try является встроенным, мы находимся в отличном положении. Использование встроенного - это просто прагматичное решение проблемы обратной совместимости (это не требует дополнительной работы для синтаксического анализатора, инструментов и т. д. - но это просто приятное дополнительное преимущество, а не основная причина). Есть также некоторые преимущества в том, чтобы писать круглые скобки, это подробно обсуждается в документации по дизайну (раздел «Свойства предлагаемого дизайна»).

Все это говорит о том, что если использование встроенного является остановкой, мы должны рассмотреть ключевое слово try . Он не будет обратно совместим с существующим кодом, поскольку ключевое слово может конфликтовать с существующими идентификаторами.

(Чтобы быть полным, есть также вариант оператора, такого как ? , который был бы обратно совместим. Однако это не кажется мне лучшим выбором для такого языка, как Go. Но опять же, если это все, что нужно, чтобы сделать try вкусными, возможно, нам следует это рассмотреть.)

@ugorji Спасибо за положительный отзыв .

try можно расширить, чтобы получить дополнительный аргумент. Мы бы предпочли взять только функцию с сигнатурой func (error) error . Если вы хотите паниковать, легко предоставить однострочную вспомогательную функцию:

func doPanic(err error) error { panic(err) }

Лучше сделать дизайн try простым.

@ patrick-nyt Что вы предлагаете :

file, err := os.Open("file.go")
try(err)

будет возможно с текущим предложением.

@dpinela , @ugorji Пожалуйста, прочтите также дизайн-документ на тему must против try . Лучше сделать try максимально простым. must является распространенным «шаблоном» в выражениях инициализации, но нет необходимости срочно «исправлять» это.

@jargv Спасибо за ваше предложение . Это интересная идея (см. также мой комментарий здесь на эту тему). Обобщить:

• try(x) работает как предложено
• try() возвращает *error , указывающий на результат ошибки

Это был бы действительно еще один способ получить результат без необходимости называть его.

@cespare Предложение @jargv кажется мне намного проще, чем то, что предлагаете вы. Это решает ту же проблему доступа к ошибке результата. Как вы думаете?

Согласно https://github.com/golang/go/issues/32437#issuecomment -499320588:

func doPanic(err error) error { паника(err) }

Я предполагаю, что эта функция будет довольно распространена. Может ли это быть предопределено во «встроенном» (или где-то еще в стандартном пакете, например, errors )?

Жаль, что вы не ожидаете достаточно мощных дженериков для реализации
попробовать, я на самом деле надеялся, что это будет возможно сделать.

Да, это предложение могло бы стать первым шагом, хотя я не вижу особой пользы в
это я сам в том виде, в каком он есть сейчас.

Конечно, в этом выпуске, возможно, слишком много внимания уделяется подробным альтернативам,
но это говорит о том, что многие участники не совсем довольны
Это. Чего, кажется, не хватает, так это широкого консенсуса по поводу этого предложения...

Оп вр 7 июн. 2019 01:04 schreef pj уведомления@github.com :

Аспер #32437 (комментарий)
https://github.com/golang/go/issues/32437#issuecomment-499320588 :

func doPanic(err error) error { паника(err) }

Я предполагаю, что эта функция будет довольно распространена. Может ли это быть предопределено
во "встроенном"?

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/golang/go/issues/32437?email_source=notifications&email_token=AAARM6OOOLLYO5ZCE6VVL2TPZGJWRA5CNFSM4HTGCZ72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXEMYZY#issuecomment8 , 7919
или заглушить тему
https://github.com/notifications/unsubscribe-auth/AAARM6K5AOR2DES4QDTNLSTPZGJWRANCNFSM4HTGCZ7Q
.

@pjebs , я десятки раз писал эквивалентную функцию. Обычно я называю это «orDie» или «check». Это настолько просто, что нет необходимости делать его частью стандартной библиотеки. Кроме того, разные люди могут захотеть вести журнал или что-то еще до прекращения.

@beoran Возможно, вы могли бы расширить связь между дженериками и обработкой ошибок. Когда я думаю о них, они кажутся двумя разными вещами. Обобщения — это не все, что может решить все проблемы с языком. Это возможность написать одну функцию, которая может работать с несколькими типами.

Это конкретное предложение по обработке ошибок пытается уменьшить количество шаблонов, вводя предварительно объявленную функцию try , которая в некоторых случаях изменяет управление потоком. Дженерики никогда не изменят поток управления. Так что я действительно не вижу связи.

Моя первоначальная реакция на это была 👎, так как я предполагал, что обработка нескольких вызовов, вызывающих ошибки, внутри функции сделает обработку ошибки defer запутанной. Прочитав все предложение, я изменил свою реакцию на ❤️ и 👍, поскольку узнал, что этого все еще можно достичь с относительно низкой сложностью.

@carlmjohnson Да, это просто, но...

Я писал эквивалентную функцию десятки раз.

Преимущества предварительно объявленной функции:

1. Мы можем сделать это одной строкой
2. Нам не нужно повторно объявлять функцию err => panic в каждом используемом нами пакете или сохранять для нее общее местоположение. Так как он, вероятно, является общим для всех в сообществе Go, «стандартный пакет» — это _ обычное место для него.

@griesemer Благодаря варианту исходного предложения try с обработчиком ошибок требование всеобъемлющей функции для возврата ошибки больше не требуется.

Когда я впервые спросил об этом, ошибка => паника, мне указали, что предложение рассматривало это, но считало это слишком опасным (по уважительной причине). Но если мы используем try() без обработчика ошибок в сценарии, где всеобъемлющая функция не возвращает ошибку, преобразование ее в ошибку времени компиляции снимает проблему, обсуждаемую в предложении.

@pjebs Требование всеобъемлющей функции для возврата ошибки не требовалось в исходном дизайне, _если_ был предоставлен обработчик ошибок. Но это просто еще одно усложнение try . _намного_ лучше, чтобы все было просто. Вместо этого было бы понятнее иметь отдельную функцию must , которая всегда паникует при ошибке (но в остальном похожа try ). Тогда понятно, что происходит в коде, и не нужно смотреть на контекст.

Главная привлекательность такого must заключается в том, что его можно использовать с модульными тестами; особенно если пакет testing был соответствующим образом скорректирован, чтобы восстанавливаться после паники, вызванной must , и сообщать о них как об ошибках теста в приятной форме. Но зачем добавлять еще один новый языковой механизм, если мы можем просто настроить тестовый пакет так, чтобы он также принимал тестовую функцию вида TestXxx(t *testing.T) error ? Если они вернут ошибку, что в конце концов кажется вполне естественным (возможно, мы должны были сделать это с самого начала), то try будет работать нормально. Локальные тесты потребуют немного больше работы, но это, вероятно, выполнимо.

Другое относительно распространенное использование must — это глобальные выражения инициализации ( must(regexp.Compile... и т. д.). Если бы было «приятно иметь», но это не обязательно поднимает его до уровня, необходимого для новой языковой функции.

@griesemer Учитывая, что must имеет неопределенное отношение к try , и учитывая, что импульс направлен на реализацию try , не думаете ли вы, что неплохо рассмотреть must в то же время - даже если это просто "приятно иметь".

Скорее всего, если это не будет обсуждаться в этом раунде, это просто не будет реализовано/серьезно рассмотрено, по крайней мере, в течение 3 с лишним лет (или, возможно, никогда). Перекрытие в обсуждениях также было бы хорошо, а не начинать с нуля и повторять обсуждения.

Многие люди утверждают, что must try .

@pjebs Определенно не похоже, что прямо сейчас есть какой-либо «импульс к реализации try » ... - И мы также только что опубликовали это два дня назад. Тоже ничего не решено. Давайте дадим этому некоторое время.

От нас не ускользнуло, что must прекрасно сочетается с try , но это не то же самое, что сделать его частью языка. Мы только начали исследовать это пространство с более широкой группой людей. Мы действительно еще не знаем, что может прийти в поддержку или против него. Спасибо.

Потратив несколько часов на чтение всех комментариев и подробного документа по дизайну, я хотел добавить свое мнение к этому предложению.

Я сделаю все возможное, чтобы уважать просьбу @ianlancetaylor не просто повторять предыдущие пункты , а вместо этого добавлять новые комментарии к обсуждению. Однако я не думаю, что смогу сделать новые комментарии, не ссылаясь на предыдущие комментарии.

Обеспокоенность

Неудачная перегрузка отсрочки

Предпочтение перегружать очевидную и прямолинейную природу defer вызывает тревогу. Если я напишу defer closeFile(f) , то мне будет просто и очевидно, что происходит и почему; в конце функции, которая будет вызываться. И хотя использование defer вместо panic() и recover() менее очевидно, я редко использую его, если вообще когда-либо использую, и почти никогда не вижу его при чтении чужого кода.

Spoo для перегрузки defer для обработки ошибок не является очевидным и запутанным. Почему ключевое слово defer ? Разве defer не означает _"Сделать позже"_ вместо _"Может быть, позже?"_

Также есть опасения, упомянутые командой Go по поводу производительности defer . Учитывая это, кажется вдвойне прискорбным, что defer рассматривается для потока кода _"горячего пути"_.

Нет статистики, подтверждающей значительный вариант использования

Как упоминал @prologic , это предложение try() основано на большом проценте кода, который будет использовать этот вариант использования, или вместо этого оно основано на попытке успокоить тех, кто жаловался на обработку ошибок Go?

Хотел бы я знать, как предоставить вам статистику из моей кодовой базы, не просматривая каждый файл и не делая заметок; Я не знаю, как @prologic смог, хотя рад, что он это сделал.

Но, как ни странно, я был бы удивлен, если бы try() адресовал 5% моих вариантов использования и подозревал, что он решит менее 1%. Знаете ли вы наверняка, что у других результаты сильно отличаются? Вы взяли подмножество стандартной библиотеки и попытались посмотреть, как оно будет применяться?

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

Облегчает разработчикам игнорирование ошибок

Это полное повторение того, что комментируют другие, но то, что в основном дает try() , во многих отношениях аналогично простому восприятию следующего как идоматического кода, и это код, который никогда не найдет своего пути ни в какой другой код. - относительно кораблей разработчиков:

f, _ := os.Open(filename)

Я знаю, что могу быть лучше в своем собственном коде, но я также знаю, что многие из нас зависят от щедрости других разработчиков Go, которые публикуют чрезвычайно полезные пакеты, но из того, что я видел в _"Other People's Code(tm)"_ лучшие практики обработки ошибок часто игнорируются.

А если серьезно, действительно ли мы хотим облегчить разработчикам игнорирование ошибок и позволить им засорять GitHub ненадежными пакетами?

Может (в основном) уже реализовать try() в пространстве пользователя

Если я неправильно понимаю предложение — что я, вероятно, понимаю — вот try() в Go Playground, реализованном в userland , хотя и с одним (1) возвращаемым значением и возвращающим интерфейс вместо ожидаемого типа:

package main

import (
    "errors"
    "fmt"
    "strings"
)
func main() {
    defer func() {
        r := recover()
        if r != nil && strings.HasPrefix(r.(string),"TRY:") {
            fmt.Printf("Ouch! %s",strings.TrimPrefix(r.(string),"TRY: "))
        }
    }()
    n := try(badjuju()).(int)
    fmt.Printf("Just chillin %dx!",n)   
}
func badjuju() (int,error) {
    return 10, errors.New("this is a really bad error")
}
func try(args ...interface{}) interface{} {
    err,ok := args[1].(error)
    if ok && err != nil {
        panic(fmt.Sprintf("TRY: %s",err.Error()))
    }
    return args[0]
}

Таким образом, пользователь может добавить try2() , try3() и так далее в зависимости от того, сколько возвращаемых значений ему нужно вернуть.

Но Go потребуется только одна (1) простая _ , но универсальная _ языковая функция, чтобы позволить пользователям, которые хотят try() , реализовать собственную поддержку, хотя и требующую явного утверждения типа. Добавьте возможность _(полностью обратной совместимости)_ для Go func , чтобы возвращать переменное количество возвращаемых значений, например:

func try(args ...interface{}) ...interface{} {
    err,ok := args[1].(error)
    if ok && err != nil {
        panic(fmt.Sprintf("TRY: %s",err.Error()))
    }
    return args[0:len(args)-2]
}

И если вы сначала обратитесь к дженерикам, то утверждения типа даже не понадобятся _ (хотя я думаю, что варианты использования для дженериков должны быть сокращены путем добавления встроенных функций для адресации вариантов использования дженериков, а не добавлять сбивающую с толку семантику и синтаксический салат дженериков. из Явы и др.)_

Отсутствие очевидности

Изучая код предложения, я обнаружил, что его поведение неочевидно, и о нем довольно трудно рассуждать.

Когда я вижу, что try() оборачивает выражение, что произойдет, если будет возвращена ошибка?

Будет ли ошибка просто игнорироваться? Или он перейдет к первому или самому последнему defer , и если это так, он автоматически установит переменную с именем err внутри замыкания или передаст ее как параметр _(I не видите параметр?)_. И если не имя автоматической ошибки, то как мне его назвать? Означает ли это, что я не могу объявить свою собственную переменную err в своей функции, чтобы избежать конфликтов?

И будет ли он вызывать все defer s? В обратном порядке или в обычном порядке?

Или он вернется как из закрытия, так и из func , где была возвращена ошибка? _(Что-то я бы никогда не подумал, если бы не прочитал здесь слова, которые подразумевают это.)_

Прочитав предложение и все комментарии, я до сих пор, честно говоря, не знаю ответов на поставленные выше вопросы. Мы хотим добавить такую ​​функцию в язык, сторонники которого позиционируют себя как «Капитан Очевидность»?

Недостаток контроля

Используя defer , кажется, что единственный элемент управления, который разработчикам будет предоставлен, - это переход к _(самому последнему?)_ defer . Но по моему опыту с любыми методами, кроме тривиального func , обычно это сложнее.

Часто я находил полезным делиться аспектами обработки ошибок в пакете func — или даже в пакете package — но при этом иметь более конкретную обработку, совместно используемую в одном или нескольких других пакетах.

Например, я могу вызвать пять (5) вызовов func , которые возвращают error() из другого func ; обозначим их как A() , B() , C() , D() и E() . Мне может понадобиться C() для собственной обработки ошибок, A() , B() , D() и E() для совместной обработки ошибок, и B() и E() для специальной обработки.

Но я не думаю, что это было бы возможно сделать с этим предложением. По крайней мере, не легко.

Однако по иронии судьбы в Go уже есть языковые функции, обеспечивающие высокий уровень гибкости, который не нужно ограничивать небольшим набором вариантов использования; func s и замыкания. Итак, мой риторический вопрос:

_ "Почему мы не можем просто добавить небольшие усовершенствования в существующий язык для решения этих задач и не добавлять новые встроенные функции или принимать запутанную семантику?" _

Это риторический вопрос, потому что в качестве альтернативы я планирую представить предложение, которое я придумал в ходе изучения этого предложения и с учетом всех его недостатков.

Но я отвлекся, это будет позже, и этот комментарий касается того, почему текущее предложение необходимо пересмотреть.

Отсутствие заявленной поддержки break

Может показаться, что это выходит из поля зрения, поскольку большинство людей используют ранние возвраты для обработки ошибок, но я обнаружил, что предпочтительнее использовать break для обработки ошибок, обертывая большую часть или всю функцию до return .

Я использовал этот подход некоторое время, и его преимущества в упрощении рефакторинга сами по себе делают его более предпочтительным, чем ранний return , но у него есть несколько других преимуществ, включая единую точку выхода и возможность преждевременного завершения раздела функции, но все же способен запустить очистку _ (вероятно, поэтому я так редко использую defer , о чем мне труднее рассуждать с точки зрения потока программы.)_

Чтобы использовать break вместо раннего возврата, используйте цикл for range "1" {...} , чтобы создать блок для выхода из break из _ (на самом деле я создаю пакет с именем only , который содержит только константу называется Once со значением "1" ):_

func (me *Config) WriteFile() (err error) {
    for range only.Once {
        var j []byte
        j, err = json.MarshalIndent(me, "", "    ")
        if err != nil {
            err = fmt.Errorf("unable to marshal config; %s", 
                err.Error(),
            )
            break
        }
        err = me.MaybeMakeDir(me.GetDir(), os.ModePerm)
        if err != nil {
            err = fmt.Errorf("unable to make directory'%s'; %s", 
                me.GetDir(), 
                err.Error(),
            )
            break
        }
        err = ioutil.WriteFile(string(me.GetFilepath()), j, os.ModePerm)
        if err != nil {
            err = fmt.Errorf("unable to write to config file '%s'; %s", 
                me.GetFilepath(), 
                err.Error(),
            )
            break
        }
    }
    return err
}

В ближайшем будущем я планирую подробно рассказать об этом паттерне в блоге и обсудить несколько причин, по которым я обнаружил, что он работает лучше, чем ранние возвраты.

Но я отвлекся. Причина, по которой я поднимаю это здесь, заключается в том, что мне нужно, чтобы Go реализовал обработку ошибок, которая предполагает ранние return s и игнорирует использование break для обработки ошибок.

Мое мнение err == nil проблематично

В качестве дальнейшего отступления я хочу поднять вопрос о том, что меня беспокоит идиоматическая обработка ошибок в Go. Хотя я твердо верю в то, что философия Go заключается в обработке ошибок по мере их возникновения, а не в использовании обработки исключений, я чувствую, что использование nil для указания на отсутствие ошибок проблематично, потому что я часто обнаруживаю, что хотел бы вернуть сообщение об успешном завершении подпрограмма — для использования в ответах API — и не только возвращает значение, отличное от нуля, только при возникновении ошибки.

Поэтому для Go 2 мне бы очень хотелось, чтобы Go рассмотрел возможность добавления нового встроенного типа status и трех встроенных функций iserror() , iswarning() , issuccess() . status может реализовать error , что обеспечивает большую обратную совместимость, а значение nil , переданное в issuccess() , вернет true , но status будет иметь дополнительное внутреннее состояние для уровня ошибки, чтобы проверка уровня ошибки всегда выполнялась с помощью одной из встроенных функций и, в идеале, никогда не с проверкой nil . Это позволило бы использовать что-то вроде следующего подхода:

func (me *Config) WriteFile() (sts status) {
    for range only.Once {
        var j []byte
        j, sts = json.MarshalIndent(me, "", "    ")
        if iserror(sts) {
            sts.AddMessage("unable to marshal config")
            break
        }
        sts = me.MaybeMakeDir(me.GetDir(), os.ModePerm)
        if iserror(sts) {
            sts.AddMessage("unable to make directory'%s'", me.GetDir())
            break
        }
        sts = ioutil.WriteFile(string(me.GetFilepath()), j, os.ModePerm)
        if iserror(sts) {
            sts.AddMessage("unable to write to config file '%s'", 
                me.GetFilepath(), 
            )
            break
        }
        sts = fmt.Status("config file written")
    }
    return sts
}

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

Если вы считаете, что при таком подходе есть вероятность развития идиоматического кода Go, примите это во внимание при реализации обработки ошибок, в том числе при рассмотрении этого предложения try() .

_"Не для всех"_ обоснование

Одним из ключевых ответов команды Go было: «Опять же, это предложение не пытается решить все ситуации обработки ошибок».
И это, вероятно, самая тревожная проблема с точки зрения управления.

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

И разве это не то же самое оправдание, по которому члены основной команды отклоняли многочисленные просьбы сообщества? Ниже приводится прямая цитата из комментария, сделанного членом команды Go в типичном ответе на запрос функции, отправленный около 2 лет назад _ (я не называю имя человека или конкретный запрос функции, потому что это обсуждение не должно быть в состоянии народ, а вместо этого про язык):_

_ «Новая языковая функция требует убедительных примеров использования. Все языковые функции полезны, иначе никто не предложил бы их; вопрос в том, достаточно ли они полезны, чтобы оправдать усложнение языка и необходимость изучения новых концепций всеми? случаи здесь? Как люди будут их использовать? Например, рассчитывают ли люди, что смогут... и если да, то как они это сделают? Делает ли это предложение больше, чем позволяет вам...?"_
— Член основной команды Go

Честно говоря, когда я увидел эти ответы, я испытал одно из двух чувств:

1. Негодование, если это особенность, с которой я согласен, или
2. Восторг, если это функция, с которой я не согласен.

Но в любом случае мои чувства были/остаются неуместными; Я понимаю и согласен с тем, что отчасти причина, по которой Go является языком, на котором многие из нас выбирают для разработки, заключается в том, что ревностно охраняет чистоту языка.

И именно поэтому это предложение меня так беспокоит, потому что основная команда Go, похоже, копается в этом предложении на том же уровне, что и тот, кто догматически хочет эзотерическую функцию, которую сообщество Go ни за что не потерпит.

_(И я искренне надеюсь, что команда не будет стрелять в мессенджера и воспримет это как конструктивную критику от кого-то, кто хочет, чтобы Go продолжал быть лучшим, чем он может быть для всех нас, поскольку я должен был бы считаться «персоной нон грата» со стороны основная команда.)_

Если требование убедительного набора реальных вариантов использования является планкой для всех предложений функций, созданных сообществом, не должно ли это также быть той же планкой для _ всех _ предложений функций?

Вложенность try()

Это тоже обсуждалось некоторыми, но я хочу провести сравнение между try() и продолжающимся запросом тернарных операторов. Цитата из комментариев другого члена команды Go около 18 месяцев назад:

_"при "программировании в больших масштабах" (большие базы кода с большими командами в течение длительных периодов времени) код читается ГОРАЗДО чаще, чем пишется, поэтому мы оптимизируем для удобства чтения, а не для записи."_

Одной из _основных_ заявленных причин отказа от добавления тернарных операторов является то, что их трудно читать и/или легко неправильно читать, когда они вложены. Однако то же самое можно сказать и о вложенных операторах try() , таких как try(try(try(to()).parse().this)).easily()) .

Дополнительные причины возражений против тернарных операторов заключались в том, что они являются _"выражениями"_ с тем аргументом, что вложенные выражения могут добавить сложности. Но разве try() тоже не создает вложенное выражение?

Теперь кто-то здесь сказал: «Я думаю, что примеры вроде [вложенных try() s] нереалистичны»_, и это утверждение не оспаривалось.

Но если люди принимают как постулат, что разработчики не будут вкладывать try() , то почему такое же почтение не уделяется тернарным операторам, когда люди говорят: «Я думаю, что глубоко вложенные тернарные операторы нереалистичны?»_

В итоге я думаю, что если аргументы против тернарных операторов действительно действительны, то их также следует считать действительными аргументами против этого предложения try() .

В итоге

На момент написания этой статьи 58% проголосовало против, а 42% проголосовало за. Я думаю, что одного этого должно быть достаточно, чтобы указать, что это предложение вызывает достаточно разногласий и пора вернуться к чертежной доске по этому вопросу.

между прочим

PS Если говорить более иронично, я думаю, что мы должны следовать перефразированной мудрости Йоды:

_"Нет try() . Только do() ."_

@ianlancetaylor

@beoran Возможно, вы могли бы расширить связь между дженериками и обработкой ошибок.

Не говоря о @beoran, но в моем комментарии несколько минут назад вы увидите, что если бы у нас были дженерики _(плюс вариативные возвращаемые параметры)_, то мы могли бы создать свои собственные try() .

Однако — и я повторю то, что сказал выше о дженериках здесь, где это будет легче увидеть:

_ "Я думаю, что варианты использования дженериков должны быть сокращены путем добавления встроенных функций для решения вариантов использования дженериков, а не добавления запутанной семантики и синтаксиса дженериков из Java и др.)"_

@ianlancetaylor

Пытаясь сформулировать ответ на ваш вопрос, я попытался реализовать функцию try в Go как есть, и, к моему удовольствию, на самом деле уже можно эмулировать что-то очень похожее:

func try(v interface{}, err error) interface{} {
   if err != nil { 
     panic(err)
   }
   return v
}

Посмотрите здесь, как его можно использовать: https://play.golang.org/p/Kq9Q0hZHlXL

Недостатками такого подхода являются:

1. Требуется отложенное спасение, но с try , как в этом предложении, также необходим отложенный обработчик, если мы хотим правильно обрабатывать ошибки. Так что я считаю, что это не серьезный недостаток. Было бы даже лучше, если бы в Go была какая-то встроенная функция super(arg1, ..., argn) , заставляющая вызывающую сторону вызывающей стороны, на один уровень вверх по стеку вызовов, возвращаться с заданными аргументами arg1,...argn, что-то вроде супервозврата. если вы будете.
2. Этот try , который я реализовал, может работать только с функцией, которая возвращает один результат и ошибку.
3. Вы должны ввести assert для возвращаемых результатов интерфейса emtpy.

Достаточно мощные дженерики могут решить проблему 2 и 3, оставив только 1, которую можно решить, добавив super() . С этими двумя функциями мы могли бы получить что-то вроде:

func (T ... interface{})try(T, err error) super {
   if err != nil { 
      super(err)
   }
  super(T...)
}

И тогда отложенное спасение было бы уже не нужно. Это преимущество будет доступно, даже если в Go не будут добавлены дженерики.

На самом деле идея встроенной функции super() настолько мощная и интересная, что я мог бы опубликовать предложение по ней отдельно.

@beoran Приятно видеть, что мы независимо друг от друга пришли к одним и тем же ограничениям в отношении реализации try() в пространстве пользователя, за исключением суперчасти, которую я не включил, потому что хотел поговорить о чем-то подобном в альтернативном предложении. :-)

Мне нравится это предложение, но тот факт, что вам пришлось явно указать, что defer try(...) и go try(...) запрещены, заставил меня подумать, что что-то не так... Ортогональность - хорошее руководство по проектированию. При дальнейшем чтении и просмотре таких вещей, как
x = try(foo(...)) y = try(bar(...))
Интересно, может быть, try должен быть контекстом ! Рассмотреть возможность:
try ( x = foo(...) y = bar(...) )
Здесь foo() и bar() возвращают два значения, второе из которых равно error . Попробуйте использовать семантику только для вызовов в блоке try , где возвращаемое значение ошибки опускается (нет получателя), а не игнорируется (получатель _ ). Вы даже можете обрабатывать некоторые ошибки между вызовами foo и bar .

Резюме:
а) проблема запрета try для go и defer отпадает в силу синтаксиса.
б) обработка ошибок нескольких функций может быть исключена.
в) его магическая природа лучше выражается в виде специального синтаксиса, чем в виде вызова функции.

Если try является контекстом, то мы только что создали блоки try/catch, которых мы специально пытаемся избежать (и не зря).

Нет никакого улова. Будет сгенерирован точно такой же код, как если бы текущее предложение
x = try(foo(...)) y = try(bar(...))
Это просто другой синтаксис, а не семантика.
````

Думаю, я сделал несколько предположений об этом, чего не должен был делать, хотя у него все еще есть пара недостатков.

Что, если foo или bar не возвращают ошибку, можно ли их также поместить в контекст try? Если нет, то кажется, что было бы некрасиво переключаться между функциями ошибок и функциями без ошибок, и если они могут, то мы возвращаемся к проблемам с блоками try в старых языках.

Во-вторых, обычно синтаксис keyword ( ... ) означает, что вы ставите префикс ключевого слова в каждой строке. Итак, для импорта, var, const и т. д.: каждая строка начинается с ключевого слова. Делать исключение из этого правила не кажется хорошим решением

Вместо использования функции было бы более идиоматично использовать специальный идентификатор?

У нас уже есть пустой идентификатор _ , который игнорирует значения.
У нас может быть что-то вроде # , которое можно использовать только в функциях, которые имеют последнее возвращаемое значение типа error.

func foo() (error) {
    f, # := os.Open()
    defer f.Close()
    _, # = f.WriteString("foo")
    return nil
}

когда ошибка присваивается # , функция немедленно возвращается с полученной ошибкой. Что касается других переменных, их значения будут следующими:

• если они не названы нулевым значением
• значение, присвоенное именованным переменным, в противном случае

@deanveloper семантика блока try имеет значение только для функций, которые возвращают значение ошибки и которым значение ошибки не присваивается. Таким образом, последний пример настоящего предложения также может быть записан как
try(x = foo(...)) try(y = bar(...))
размещение обоих операторов в одном блоке аналогично тому, что мы делаем для повторяющихся операторов import , const и var .

Теперь, если у вас есть, например
try( x = foo(...)) go zee(...) defer fum() y = bar(...) )
Это эквивалентно написанию
try(x = foo(...)) go zee(...) defer fum() try(y = bar(...))
Факторизация всего этого в одном блоке try делает его менее загруженным.

Рассмотреть возможность
try(x = foo())
Если foo() не возвращает значение ошибки, это эквивалентно
x = foo()

Рассмотреть возможность
try(f, _ := os.open(filename))
Поскольку возвращаемое значение ошибки игнорируется, это эквивалентно просто
f, _ := os.open(filename)

Рассмотреть возможность
try(f, err := os.open(filename))
Поскольку возвращаемое значение ошибки не игнорируется, это эквивалентно
f, err := os.open(filename) if err != nil { return ..., err }
Как в настоящее время указано в предложении.

И это также красиво убирает вложенные попытки!

Вот ссылка на альтернативное предложение, о котором я упоминал выше:

• https://github.com/golang/go/issues/32473

Он требует добавления двух (2) небольших, но общих языковых функций для решения тех же вариантов использования, что и try()

1. Возможность вызова func /замыкания в операторе присваивания.
2. Возможность break , continue или return более чем на один уровень.

С этими двумя функциями они не будут _"волшебными"_, и я полагаю, что их использование приведет к созданию кода Go, который будет легче понять и будет больше соответствовать идиоматичному коду Go, с которым мы все знакомы.

Я прочитал предложение, и мне очень нравится, куда идет попытка.

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

Рассмотрим карты. Это действительно:

v := m[key]

как это:

v, ok := m[key]

Что, если мы обработаем ошибки именно так, как предлагает try, но удалим встроенный. Итак, если мы начали с:

v, err := fn()

Вместо того, чтобы писать:

v := try(fn())

Вместо этого мы могли бы написать:

v := fn()

Когда значение ошибки не фиксируется, оно обрабатывается точно так же, как и попытка. Потребуется некоторое время, чтобы привыкнуть, но это очень похоже на v, ok := m[key] и v, ok := x.(string) . По сути, любая необработанная ошибка приводит к возврату функции и установке значения ошибки.

Вернемся к выводам проектной документации и требованиям к реализации:

• Синтаксис языка сохраняется, новые ключевые слова не вводятся.
• Это по-прежнему синтаксический сахар, как и try, и, надеюсь, его легко объяснить.
• Не требует нового синтаксиса
• Он должен быть полностью обратно совместим.

Я предполагаю, что это будет иметь почти те же требования к реализации, что и попытка, поскольку основное отличие заключается не во встроенной функции, запускающей синтаксический сахар, а в отсутствии поля err.

Таким образом, используя пример CopyFile из предложения вместе с defer fmt.HandleErrorf(&err, "copy %s %s", src, dst) , мы получаем:

func CopyFile(src, dst string) (err error) {
        defer fmt.HandleErrorf(&err, "copy %s %s", src, dst)

        r := os.Open(src)
        defer r.Close()

        w := os.Create(dst)
        defer func() {
                err := w.Close()
                if err != nil {
                        os.Remove(dst) // only if a “try” fails
                }
        }()

        io.Copy(w, r)
        w.Close()
        return nil
}

@savaki Мне это нравится, и я думал о том, что нужно сделать, чтобы Go перевернул обработку ошибок, всегда обрабатывая ошибки по умолчанию и позволяя программисту указывать, когда этого не делать (путем записи ошибки в переменную), но полное отсутствие каких-либо идентификатор сделал бы код трудным для понимания, поскольку невозможно было бы увидеть все точки возврата. Может быть соглашение об именах функций, которые могут возвращать ошибку по-разному, могло бы работать (например, использование общедоступных идентификаторов с заглавной буквы). Может быть, если функция вернула ошибку, она всегда должна заканчиваться, скажем, на ? . Тогда Go всегда сможет неявно обработать ошибку и автоматически вернуть ее вызывающей функции, как и try. Это делает его очень похожим на некоторые предложения, предлагающие использовать идентификатор ? вместо try, но важным отличием является то, что здесь ? будет частью имени функции, а не дополнительным идентификатором. На самом деле функция, возвращающая error в качестве последнего возвращаемого значения, даже не скомпилируется, если не будет иметь суффикс ? . Конечно, ? является произвольным и может быть заменено чем-либо еще, что делает намерение более явным. operation?() было бы эквивалентно обертыванию try(someFunc()) , но ? было бы частью имени функции, и его единственная цель состояла бы в том, чтобы указать, что функция может возвращать ошибку так же, как капитализация первая буква переменной.

На первый взгляд это очень похоже на другие предложения, предлагающие заменить try на ? , но критическое отличие состоит в том, что обработка ошибок делается неявной (автоматической), а вместо этого делается явным игнорирование (или перенос) ошибок, которые в любом случае это лучшая практика. Самая очевидная проблема с этим, конечно, заключается в том, что он не имеет обратной совместимости, и я уверен, что их гораздо больше.

Тем не менее, мне было бы очень интересно посмотреть, как Go может обрабатывать ошибки по умолчанию / неявный случай, автоматизируя его и позволяя программисту написать немного дополнительного кода, чтобы игнорировать / переопределять обработку. Проблема, на мой взгляд, заключается в том, как сделать все точки возврата очевидными в этом случае, потому что без этого ошибки станут больше похожими на исключения в том смысле, что они могут появиться откуда угодно, поскольку ход программы не сделает их очевидными. Можно сказать, что сделать ошибки неявными с помощью визуального индикатора — это то же самое, что реализовать try и сделать errcheck ошибкой компилятора.

Можем ли мы сделать что-то вроде исключений C++ с декораторами для старых функций?

func some_old_test() (int, error){
    return 0, errors.New("err1")
}
func some_new_test() (int){
        if true {
             return 1
        }
    throw errors.New("err2")
}
func throw_res(int, e error) int {
    if e != nil {
        throw e
    }
    return int
}
func main() {
    fmt.Println("Hello, playground")
    try{
        i := throw_res(some_old_test())
        fmt.Println("i=", i + some_new_test())
    } catch(err io.Error) {
        return err
    } catch(err error) {
        fmt.Println("unknown err", err)
    }
}

@owais Я думал, что семантика будет точно такой же, как и попытка, поэтому, по крайней мере, вам нужно будет объявить тип ошибки. Итак, если мы начали с:

func foo() error {
  _, err := fn() 
  if err != nil {
    return err
  }

  return nil
} 

Если я понимаю предложение try, просто сделайте следующее:

func foo() error {
  _  := fn() 
  return nil
} 

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

Тогда это будет работать:

func foo() (err error) {
  _  := fn() 
  return nil
} 

почему бы просто не обработать случай ошибки, которая не назначена переменной.

• удалить необходимость в именованных возвратах, компилятор может сделать все это самостоятельно.
• позволяет добавлять контекст.
• обрабатывает общий вариант использования.
• обратная совместимость
• не странно взаимодействует с отсрочкой, циклами или переключателями.

неявный возврат для случая if err != nil, компилятор может сгенерировать имя локальной переменной для возврата, если необходимо, чтобы программист не мог получить к нему доступ.
лично мне не нравится этот конкретный случай с точки зрения читабельности кода

f := os.Open("foo.txt")

предпочитаете явный возврат, следует, что код читается больше, чем написанная мантра

f := os.Open("foo.txt") else return

интересно, что мы могли бы принимать обе формы, а gofmt автоматически добавлял бы возврат else.

добавление контекста, а также локальное наименование переменной. return становится явным, потому что мы хотим добавить контекст.

f := os.Open("foo.txt") else err {
  return errors.Wrap(err, "some context")
}

добавление контекста с несколькими возвращаемыми значениями

f := os.Open("foo.txt") else err {
  return i, j, errors.Wrap(err, "some context")
}

вложенные функции требуют, чтобы внешние функции обрабатывали все результаты в одном и том же порядке
минус последняя ошибка.

bits := ioutil.ReadAll(os.Open("foo")) else err {
  // either error ends up here.
  return i, j, errors.Wrap(err, "some context")
}

компилятор отказывается от компиляции из-за отсутствия возвращаемого значения ошибки в функции

func foo(s string) int {
   i := strconv.Atoi(s) // cannot implicitly return error due to missing error return value for foo.
   return i * 2
}

успешно компилируется, потому что ошибка явно игнорируется.

func foo(s string) int {
   i, _ := strconv.Atoi(s)
   return i * 2
} 

компилятор доволен. он игнорирует ошибку, как и в настоящее время, потому что не происходит присваивания или суффикса.

func foo() error {
  return errors.New("whoops")
}

func bar() {
  foo()
}

внутри цикла вы можете использовать continue.

for _, s := range []string{"1","2","3","4","5","6"} {
  i := strconv.Atoi(s) else continue
}

изменить: заменить ; на else

@savaki Я думаю, что понял ваш первоначальный комментарий, и мне нравится идея обработки ошибок Go по умолчанию, но я не думаю, что это жизнеспособно без добавления некоторых дополнительных изменений синтаксиса, и как только мы это сделаем, оно станет поразительно похоже на текущее предложение.

Самый большой недостаток того, что вы предлагаете, заключается в том, что он не раскрывает все точки, из которых функция может вернуться, в отличие от текущей if err != nil {return err} или функции try, представленной в этом предложении. Несмотря на то, что под капотом он будет работать точно так же, визуально код будет выглядеть совсем иначе. При чтении кода невозможно было узнать, какие вызовы функций могут возвращать ошибку. В конечном итоге это будет хуже, чем исключения IMO.

Возможно, обработка ошибок может быть сделана неявной, если компилятор навязывает некоторые семантические соглашения функциям, которые могут возвращать ошибки. Например, они должны начинаться или заканчиваться определенной фразой или символом. Это сделало бы все точки возврата очень очевидными, и я думаю, что это было бы лучше, чем ручная обработка ошибок, но не уверен, насколько лучше, учитывая, что уже есть проверки ворса, которые выкрикивают загрузку, когда обнаруживают, что ошибка игнорируется. Было бы очень интересно посмотреть, может ли компилятор заставить функции называться определенным образом в зависимости от того, могут ли они возвращать возможные ошибки.

Основным недостатком этого подхода является то, что параметр результата ошибки должен быть назван, что может привести к менее красивым API (но см. FAQ по этому вопросу). Мы верим, что привыкнем к этому, как только этот стиль утвердится.

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

func example() error {
        var err *error = funcerror() // always return a non-nil pointer
        fmt.Print(*err) // always nil if the return parameters are not named and not in a defer

        defer func() {
                err := funcerror()
                fmt.Print(*err) // "x"
        }

        return errors.New("x")
}

func exampleNamed() (err error) {
        funcErr := funcerror()
        fmt.Print(*funcErr) // "nil"

        err = errors.New("x")
        fmt.Print(*funcErr) // "x", named return parameter is reflected even before return is called

        *funcErr = errors.New("y")
        fmt.Print(err) // "y", unfortunate side effect?

        defer func() {
                funcErr := funcerror()
                fmt.Print(*funcErr) // "z"
                fmt.Print(err) // "z"
        }

        return errors.New("z")
}

использование с попыткой:

func CopyFile(src, dst string) (error) {
        defer func() {
                err := funcerror()
                if *err != nil {
                        *err = fmt.Errorf("copy %s %s: %v", src, dst, err)
                }
        }()
        // one liner alternative
        // defer fmt.HandleErrorf(funcerror(), "copy %s %s", src, dst)

        r := try(os.Open(src))
        defer r.Close()

        w := try(os.Create(dst))
        defer func() {
                w.Close()
                err := funcerror()
                if *err != nil {
                        os.Remove(dst) // only if a “try” fails
                }
        }()

        try(io.Copy(w, r))
        try(w.Close())
        return nil
}

В качестве альтернативы funcerror (название находится в стадии разработки :D) может возвращать nil, если не вызывается внутри defer.

Другой альтернативой является то, что funcerror возвращает интерфейс «Errorer», чтобы сделать его доступным только для чтения:

type interface Errorer() {
        Error() error
}

@savaki Мне действительно нравится ваше предложение опустить try() и позволить ему больше походить на тестирование карты или утверждения типа. Это больше похоже на _"Go"._

Тем не менее, я все еще вижу одну вопиющую проблему, и ваше предложение предполагает, что все ошибки, использующие этот подход, вызовут return и покинут функцию. Чего он не рассматривает, так это выпуска break из текущих for или continue за текущие for .

Ранние return — это кувалда, когда во многих случаях скальпель — лучший выбор.

Поэтому я утверждаю, что break и continue должны быть допустимыми стратегиями обработки ошибок, и в настоящее время ваше предложение предполагает только return , тогда как try() предполагает, что это или вызов ошибки обработчик, который сам может только return , но не break или continue .

Похоже, у нас с Саваки были похожие идеи, я просто добавил семантику блока для обработки ошибки, если это необходимо. Например, добавление comtext для петель, где вы хотите закоротить и т. д.

@mikeschinkel посмотри мое расширение, у нас с ним были похожие идеи, я просто расширил его с помощью необязательного оператора блока

@Джеймс-Лоуренс

@mikesckinkel посмотри мое расширение, у нас с ним были похожие идеи, я просто расширил его с помощью необязательного оператора блока

Взяв ваш пример:

f := os.Open("foo.txt"); err {
  return errors.Wrap(err, "some context")
}

Что можно сравнить с тем, что мы делаем сегодня:

f,err := os.Open("foo.txt"); 
if err != nil {
  return errors.Wrap(err, "some context")
}

Однозначно предпочтительнее для меня. За исключением нескольких проблем:

1. err кажется _"магическим"_ объявленным. Магию нужно свести к минимуму, не так ли? Итак, объявим это:

f, err := os.Open("foo.txt"); err {
  return errors.Wrap(err, "some context")
}

1. Но это все еще не работает, потому что Go не интерпретирует значения nil как false и значения указателя как true , поэтому это должно быть:

f, err := os.Open("foo.txt"); err != nil {
  return errors.Wrap(err, "some context")
}

И то, что это работает, начинает казаться, что столько же работы и много синтаксиса в одной строке, так что я мог бы продолжать делать по-старому для ясности.

Но что, если бы Go добавил две (2) встроенные функции; iserror() и error() ? Тогда мы могли бы сделать это, что мне кажется не таким уж плохим:

f := os.Open("foo.txt"); iserror() {
  return errors.Wrap(error(), "some context")
}

Или лучше _(что-то вроде):_

f := os.Open("foo.txt"); iserror() {
  return error().Extend("some context")
}

Что думаете вы и другие?

Кстати, проверьте правильность написания моего имени пользователя. Меня бы не уведомили о вашем упоминании, если бы я все равно не обращал внимания...

@mikeschinkel извините за имя, которое было на моем телефоне, а github не предлагал автоматически.

err кажется «волшебным образом» объявленным. Магию нужно свести к минимуму, не так ли? Итак, объявим это:

мда, сама идея автоматической вставки возврата волшебна. вряд ли это самое волшебное, что происходит во всем этом предложении. Плюс я бы сказал, что ошибка была объявлена; только в конце внутри контекста блока с ограниченной областью, предотвращая загрязнение родительской области, сохраняя при этом все хорошие вещи, которые мы обычно получаем с помощью операторов if.

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

_"сама идея автоматической вставки возврата волшебна."_

Никаких аргументов от меня вы не получите.

_"это вряд ли самое волшебное, что происходит во всем этом предложении."_

Наверное, я пытался доказать, что «вся магия проблематична».

_ "Кроме того, я бы сказал, что ошибка была объявлена; только в конце внутри контекста блока с областью действия..."_

Так что, если бы я хотел назвать это err2 , это тоже сработало бы?

f := os.Open("foo.txt"); err2 {
  return errors.Wrap(err, "some context")
}

Поэтому я предполагаю, что вы также предлагаете обработку специального случая err / err2 после точки с запятой, то есть предполагается, что это либо nil , либо не nil вместо bool , как при проверке карты?

if _,ok := m[a]; !ok {
   print("there is no 'a' in 'm'")
}

В целом я очень доволен обработкой ошибок go с предстоящими дополнениями к пакету ошибок.

Я тоже доволен обработкой ошибок в сочетании с break и continue _(но не return .)_

Как бы то ни было, я считаю это предложение try() скорее вредным, чем полезным, и предпочитаю не видеть ничего, кроме предложенного варианта реализации. #jmtcw.

@beoran @mikeschinkel Ранее я предположил, что мы не можем реализовать эту версию try с помощью дженериков, потому что это изменяет поток управления. Если я правильно понимаю, вы оба предполагаете, что мы могли бы использовать дженерики для реализации try , вызывая panic . Но эта версия try явно не panic . Поэтому мы не можем использовать дженерики для реализации этой версии try .

Да, мы могли бы использовать дженерики (версия дженериков, значительно более мощная, чем версия в черновике дизайна на https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md) для написания функции. который паникует при ошибке. Но паника при ошибке — это не та обработка ошибок, которую программисты Go пишут сегодня, и мне это не кажется хорошей идеей.

Специальная обработка @mikeschinkel заключается в том, что блок выполняется только при возникновении ошибки.
```
f := os.Open('foo'); err { return err } // здесь err всегда будет ненулевым.

@ianlancetaylor

_"Да, мы могли бы использовать дженерики... Но паника при ошибке - это не тот способ обработки ошибок, который программисты Go пишут сегодня, и мне это не кажется хорошей идеей."_

Я на самом деле полностью согласен с вами в этом, поэтому, похоже, вы могли неправильно истолковать цель моего комментария. Я вовсе не предполагал, что команда Go будет реализовывать обработку ошибок с использованием panic() — конечно, нет.

Вместо этого я пытался последовать вашему примеру из многих ваших прошлых комментариев по другим вопросам и предложил избегать внесения каких-либо изменений в Go, которые не являются абсолютно необходимыми, поскольку вместо этого они возможны в пространстве пользователя . Таким образом, _если_ дженерики были адресованы, _тогда_ люди, которые хотели бы получить try() , могли бы реализовать их сами, хотя и используя panic() . И это будет на одну функцию меньше, которую команде нужно будет добавить и задокументировать для Go.

Чего я не делал — и, возможно, это было неясно, — так это отстаивал то, что люди действительно используют panic() для реализации try() , просто они могли бы, если бы действительно захотели, и у них были особенности дженерики.

Это проясняет?

Для меня вызов panic , как бы это ни было сделано, сильно отличается от этого предложения для try . Поэтому, хотя я думаю, что понимаю, о чем вы говорите, я не согласен с тем, что они эквивалентны. Даже если бы у нас были дженерики, достаточно мощные, чтобы реализовать версию try , вызывающую панику, я думаю, все равно было бы разумное желание использовать версию try , представленную в этом предложении.

@ianlancetaylor Подтверждено. Опять же, я искал причину, по которой try() не нужно было бы добавлять, а не находил способ добавить его. Как я уже сказал выше, я бы предпочел не иметь ничего нового для обработки ошибок, чем иметь try() , как предлагается здесь.

Лично мне более раннее предложение check понравилось больше, чем это, основанное исключительно на визуальных аспектах; check имеет ту же мощность, что и этот try() , но bar(check foo()) для меня более удобочитаем, чем bar(try(foo())) (мне просто понадобилась секунда, чтобы сосчитать скобки!).

Что еще более важно, моя главная претензия к handle / check заключалась в том, что это не позволяло оборачивать отдельные чеки по-разному — и теперь это предложение try() имеет тот же недостаток, при вызове хитрых редко используемых функций отложенных и именованных возвратов, сбивающих с толку новичков. И с handle , по крайней мере, у нас была возможность использовать области для определения блоков дескрипторов, с defer даже это невозможно.

Насколько я понимаю, это предложение проигрывает более раннему предложению handle / check во всех отношениях.

Вот еще одна проблема с использованием отсрочек для обработки ошибок.

try — это контролируемый/преднамеренный выход из функции. отсрочки выполняются всегда, включая неконтролируемые/непреднамеренные выходы из функций. Это несоответствие может вызвать путаницу. Вот воображаемый сценарий:

func someHTTPHandlerGuts() (err error) {
  defer func() {
    recordMetric("db call failed")
    return fmt.HandleErrorf("db unavailable: %v", err)
  }()
  data := try(makeDBCall)
  // some code that panics due to a bug
  return nil
}

Вспомните, что net/http восстанавливается после паники, и представьте себе отладку производственной проблемы, связанной с паникой. Вы бы посмотрели на свои инструменты и увидели всплеск сбоев вызовов db из вызовов recordMetric . Это может скрыть истинную проблему, а именно панику в следующей строке.

Я не уверен, насколько серьезна эта проблема на практике, но это (к сожалению) еще одна причина думать, что отсрочка не является идеальным механизмом для обработки ошибок.

Вот модификация, которая может помочь с некоторыми поднятыми проблемами: относитесь к try как к goto , а не как к return . Выслушай меня. :)

Вместо этого try будет синтаксическим сахаром для:

t1, … tn, te := f()  // t1, … tn, te are local (invisible) temporaries
if te != nil {
        err = te   // assign te to the error result parameter
        goto error // goto "error" label
}
x1, … xn = t1, … tn  // assignment only if there was no error

Преимущества:

• defer не требуется для оформления ошибок. (Однако именованные возвраты по-прежнему необходимы.)
• Наличие метки error: является визуальным признаком того, что где-то в функции есть try .

Это также предоставляет механизм для добавления обработчиков, который обходит проблемы обработчика как функции: используйте метки в качестве обработчиков. try(fn(), wrap) будет goto wrap вместо goto error . Компилятор может подтвердить, что wrap: присутствует в функции. Обратите внимание, что наличие обработчиков также помогает при отладке: вы можете добавить/изменить обработчик, чтобы указать путь отладки.

Образец кода:

func CopyFile(src, dst string) (err error) {
    r := try(os.Open(src))
    defer r.Close()

    w := try(os.Create(dst))
    defer func() {
        w.Close()
        if err != nil {
            os.Remove(dst) // only if a “try” fails
        }
    }()

    try(io.Copy(w, r), copyfail)
    try(w.Close())
    return nil

error:
    return fmt.Errorf("copy %s %s: %v", src, dst, err)

copyfail:
    recordMetric("copy failure") // count incidents of this failure
    return fmt.Errorf("copy %s %s: %v", src, dst, err)
}

Другие комментарии:

• Мы могли бы потребовать, чтобы любой метке, используемой в качестве цели try , предшествовал завершающий оператор. На практике это заставит их завершить функцию и может помешать некоторому спагетти-коду. С другой стороны, это может помешать разумному и полезному использованию.
• try можно использовать для создания цикла. Я думаю, что это подпадает под лозунг «если больно, не делай этого», но я не уверен.
• Это потребует исправления https://github.com/golang/go/issues/26058.

Предоставлено: я считаю, что вариант этой идеи был впервые предложен @griesemer лично на GopherCon в прошлом году.

@josharian Здесь важно думать о взаимодействии с panic , и я рад, что вы упомянули об этом, но ваш пример кажется мне странным. В следующем коде мне непонятно, что отсрочка всегда записывает метрику "db call failed" . Это будет ложная метрика, если someHTTPHandlerGuts завершится успешно и вернет nil . defer выполняется во всех случаях выхода, а не только в случаях ошибки или паники, поэтому код кажется неправильным, даже если паники нет.

func someHTTPHandlerGuts() (err error) {
  defer func() {
    recordMetric("db call failed")
    return fmt.HandleErrorf("db unavailable: %v", err)
  }()
  data := try(makeDBCall)
  // some code that panics due to a bug
  return nil
}

@josharian Да, это более или менее точная версия, которую мы обсуждали в прошлом году (за исключением того, что мы использовали check вместо try ). Я думаю, что было бы крайне важно, чтобы нельзя было перейти «назад» в остальную часть тела функции, как только мы достигнем метки error . Это гарантировало бы, что goto несколько "структурирован" (код спагетти невозможен). Одна из проблем, которая была поднята, заключалась в том, что метка обработчика ошибок ( error: ) всегда оказывалась в конце функции (иначе ее пришлось бы как-то обходить). Лично мне нравится код обработки ошибок в конце (в конце), но другие считают, что он должен быть виден с самого начала.

@mikeshenkel Я считаю возвращение из цикла скорее плюсом, чем минусом. Я предполагаю, что это побудит разработчиков либо использовать отдельную функцию для обработки содержимого цикла, либо явно использовать err, как мы это делаем сейчас. Оба этих результата кажутся мне хорошими.

С моей точки зрения я не чувствую, что этот синтаксис try должен обрабатывать каждый вариант использования, точно так же, как я не чувствую, что мне нужно использовать

В, ок:= м[ключ]

Форма от чтения с карты

Вы можете избежать меток goto, заставляющих обработчики дойти до конца функции, воскресив предложение handle / check в упрощенной форме. Что, если бы мы использовали синтаксис handle err { ... } , но просто не позволяли цепочке обработчиков, вместо этого использовался только последний. Это значительно упрощает это предложение и очень похоже на идею goto, за исключением того, что обработка приближается к точке использования.

func CopyFile(src, dst string) (err error) {
    handle err {
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }
    r := check os.Open(src)
    defer r.Close()

    w := check os.Create(dst)
    defer func() {
        w.Close()
        if err != nil {
            os.Remove(dst) // only if a “check” fails
        }
    }()

    {
        // handlers are scoped, after this scope the original handle is used again.
        // as an alternative, we could have repeated the first handle after the io.Copy,
        // or come up with a syntax to name the handlers, though that's often not useful.
        handle err {
            recordMetric("copy failure") // count incidents of this failure
            return fmt.Errorf("copy %s %s: %v", src, dst, err)
        }
        check io.Copy(w, r)
    }
    check w.Close()
    return nil
}

В качестве бонуса у этого есть будущий путь к тому, чтобы разрешить цепочку обработчиков, поскольку все существующие варианты использования будут иметь возврат.

@josharian @griesemer , если вы введете именованные обработчики (которые требуют много ответов для проверки/обработки, см. повторяющиеся темы ), существуют параметры синтаксиса, предпочтительные для try(f(), err) :

try.err f()
try?err f()
try#err f()

?err    f() // because 'try' is redundant
?return f() // no handler
?panic  f() // no handler

(?err f()).method()

f?err() // lead with function name, instead of error handling
f?err().method()

file, ?err := os.Open(...) // many check/handle responses also requested this style

Что мне больше всего нравится в Go, так это то, что его синтаксис относительно свободен от пунктуации и его можно читать вслух без особых проблем. Я бы очень не хотел, чтобы Go закончился как $#@!perl .

Для меня создание "попробовать" встроенную функцию и включение цепочек имеет 2 проблемы:

• Это несовместимо с остальной частью потока управления в go (например, с ключевыми словами for/if/return/etc).
• Это делает код менее читаемым.

Я бы предпочел сделать это заявление без скобок. Примеры в предложении потребуют нескольких строк, но станут более читабельными (т. е. отдельные экземпляры «попробовать» будет труднее пропустить). Да, это нарушит работу внешних парсеров, но я предпочитаю сохранять согласованность.

Тернарный оператор — это еще одно место, где go не имеет чего-то и требует больше нажатий клавиш, но в то же время улучшает читаемость/обслуживаемость. Добавление «попробовать» в этой более ограниченной форме лучше сбалансирует выразительность и удобочитаемость, ИМО.

FWIW, panic влияет на поток управления и имеет скобки, но go и defer также влияют на поток и не влияют. Я склонен думать, что try больше похожа на defer тем, что это необычная потоковая операция, и усложнение ее выполнения try (try os.Open(file)).Read(buf) — это хорошо, потому что мы хотим препятствовать однострочникам. так или иначе, но что угодно. Любой в порядке.

Предложение, которое всем не понравится из-за неявного имени для переменной, возвращающей окончательную ошибку: $err . Это лучше, чем try() IMO. :-)

@griesemer

_"Лично мне нравится, когда код обработки ошибок убран (в конце)"_

+1 к этому!

Я считаю, что обработка ошибок, реализованная _до_ возникновения ошибки, гораздо сложнее обосновать, чем обработка ошибок, реализованная _после_ возникновения ошибки. Необходимость мысленно отскочить назад и заставить следовать логическому потоку кажется, будто я вернулся в 1980-е, пишу Basic с GOTO.

Позвольте мне предложить еще один потенциальный способ обработки ошибок, снова используя CopyFile() в качестве примера:

func CopyFile(src, dst string) (err error) {

    r := os.Open(src)
    defer r.Close()

    w := os.Create(dst)
    defer w.Close()

    io.Copy(w, r)
    w.Close()

    for err := error {
        switch err.Source() {
        case w.Close:
            os.Remove(dst) // only if a “try” fails
            fallthrough
        case os.Open, os.Create, io.Copy:
            err = fmt.Errorf("copy %s %s: %v", src, dst, err)
        default:
            err = fmt.Errorf("an unexpected error occurred")
        }
    }

    return err
}

Требуемые языковые изменения:

1. Разрешить конструкцию for error{} , аналогичную конструкции for range{} , но вводимую только при ошибке и выполняемую только один раз.

2. Разрешить пропуск захвата возвращаемых значений, которые реализуют <object>.Error() string , но только если конструкция for error{} существует в том же func .

3. Вызывает переход потока управления программой к первой строке конструкции for error{} , когда func возвращает _"ошибку"_ в своем последнем возвращаемом значении.

4. При возврате _"ошибки"_ Go добавляет ссылку на функцию, которая вернула ошибку, которую можно получить с помощью <error>.Source()

Что такое _"ошибка"_?

В настоящее время _"ошибка"_ определяется как любой объект, который реализует Error() string и, конечно же, не является nil .

Однако часто возникает необходимость расширить ошибку _даже при успехе_, чтобы позволить возвращать значения, необходимые для успешных результатов RESTful API. Поэтому я бы попросил команду Go не предполагать автоматически, что err!=nil означает _"ошибку"_, а вместо этого проверить, реализует ли объект ошибки IsError() и возвращает ли IsError() true , прежде чем предположить, что любое значение, отличное nil , является _"ошибкой"._

_(Я не обязательно говорю о коде в стандартной библиотеке, но в первую очередь, если вы выбираете свой поток управления для ветвления при _"ошибке"_. Если вы посмотрите только на err!=nil , мы будем очень ограничены в том, что мы можно сделать с точки зрения возвращаемых значений в наших функциях.)_

Кстати, позволить каждому тестировать _"ошибку"_ таким же образом, вероятно, проще всего было бы сделать, добавив новую встроенную функцию iserror() :

type ErrorIser interface {
    IsError() bool
}
func iserror(err error) bool {
    if err == nil { 
        return false
    }
    if _,ok := err.(ErrorIser); !ok {
        return true
    }
    return err.IsError()
}

Побочные преимущества разрешения отсутствия захвата _"ошибок"_

Обратите внимание, что разрешение не захватывать последнюю _"error"_ из вызовов func позволит последующему рефакторингу возвращать ошибки из func , которым изначально не нужно было возвращать ошибки. И это позволит провести этот рефакторинг без нарушения какого-либо существующего кода , который использует эту форму исправления ошибок и вызывает указанные func s.

Для меня это решение «Должен ли я возвращать ошибку или отказаться от обработки ошибок ради простоты?» — одно из самых больших затруднений при написании кода на Go. Разрешение не захвата _"ошибок"_ выше почти устранило бы это затруднение.

На самом деле я пытался реализовать эту идею как Go-переводчик около полугода назад. У меня нет твердого мнения, следует ли добавлять эту функцию как встроенную в Go, но позвольте мне поделиться опытом (хотя я не уверен, что это полезно).

https://github.com/rhysd/trygo

Я назвал расширенный язык TryGo и реализовал транслятор TryGo to Go.

С переводчиком код

func CreateFileInSubdir(subdir, filename string, content []byte) error {
    cwd := try(os.Getwd())

    try(os.Mkdir(filepath.Join(cwd, subdir)))

    p := filepath.Join(cwd, subdir, filename)
    f := try(os.Create(p))
    defer f.Close()

    try(f.Write(content))

    fmt.Println("Created:", p)
    return nil
}

можно перевести на

func CreateFileInSubdir(subdir, filename string, content []byte) error {
    cwd, _err0 := os.Getwd()
    if _err0 != nil {
        return _err0
    }

    if _err1 := os.Mkdir(filepath.Join(cwd, subdir)); _err1 != nil {
        return _err1
    }

    p := filepath.Join(cwd, subdir, filename)
    f, _err2 := os.Create(p)
    if _err2 != nil {
        return _err2
    }
    defer f.Close()

    if _, _err3 := f.Write(content); _err3 != nil {
        return _err3
    }

    fmt.Println("Created:", p)
    return nil
}

Из-за ограничения языка я не мог реализовать общий вызов try() . Это ограничено

• RHS определения
• RHS оператора присвоения
• Заявление о вызове

но я мог бы попробовать это с моим небольшим проектом. Мой опыт был

• в основном он отлично работает и сохраняет несколько строк
• именованное возвращаемое значение на самом деле непригодно для err , поскольку возвращаемое значение его функции определяется как присваиванием, так и специальной функцией try() . очень запутанный
• в этой функции try() отсутствовала функция «ошибки переноса», как обсуждалось выше.

_"И то, и другое кажется мне хорошим результатом."_

Мы должны согласиться не согласиться здесь.

_ "этот синтаксис try (не обязательно) обрабатывает каждый вариант использования"_

Этот мем, наверное, самый тревожный. По крайней мере, учитывая, насколько сопротивлялась команда/сообщество Go любым изменениям в прошлом, которые не имеют широкого применения.

Если мы допускаем это оправдание здесь, почему мы не можем вернуться к прошлым предложениям, которые были отклонены, потому что они не были широко применимы?

И готовы ли мы теперь спорить об изменениях в Go, которые полезны только для отдельных пограничных случаев?

По моему мнению, создание этого прецедента не приведет к хорошим результатам в долгосрочной перспективе...

_"@mikeshenkel"_

PS Сначала не увидел твоего сообщения из-за опечатки. _(это меня не оскорбляет, я просто не получаю уведомления, когда мое имя пользователя пишется с ошибкой...)_

Я ценю приверженность обратной совместимости, которая побуждает вас сделать try встроенной, а не ключевой фразой, но после борьбы с полной _странностью_ наличия часто используемой функции, которая может изменить поток управления ( panic и recover встречаются крайне редко), мне стало интересно: кто-нибудь проводил масштабный анализ частотности try в качестве идентификатора в кодовых базах с открытым исходным кодом? Мне было любопытно и скептически, поэтому я провел предварительный поиск по следующему:

• https://github.com/google/go-github
• https://github.com/cockreachdb/таракан
• https://github.com/golang/net
• https://github.com/exercism/xgo
• https://github.com/GoogleCloudPlatform/kubernetes
• https://github.com/syncthing/syncthing
• https://github.com/mitchellh/упаковщик
• https://github.com/дрон/дрон
• https://github.com/coreos/etcd
• https://github.com/докер/докер
• https://github.com/sjwhitworth/golearn
• https://github.com/bitly/nsq
• https://github.com/smartystreets/goconvey
• https://github.com/golang/tools
• https://github.com/coreos/fleet
• https://github.com/limetext/лайм
• https://github.com/flynn/flynn
• https://github.com/dropbox/godropbox
• https://github.com/hashicorp/consul
• https://github.com/hashicorp/терраформ

Среди 11 108 770 значимых строк Go, живущих в этих репозиториях, только 63 экземпляра try использовались в качестве идентификатора. Конечно, я понимаю, что эти кодовые базы (несмотря на то, что они большие, широко используемые и важные сами по себе) представляют лишь часть существующего кода Go, и, кроме того, у нас нет возможности напрямую анализировать частные кодовые базы, но это, безусловно, интересный результат.

Более того, поскольку try , как и любое ключевое слово, пишется в нижнем регистре, вы никогда не найдете его в общедоступном API пакета. Добавление ключевых слов повлияет только на внутреннюю часть пакета.

Это все предисловие к нескольким идеям, которые я хотел добавить в смесь, которые выиграют от try в качестве ключевого слова.

Я бы предложил следующие конструкции.

1) Нет обработчика

// The existing proposal, but as a keyword rather than builtin.  When an error is 
// "caught", the function returns all zero values plus the error.  Nothing 
// particularly new here.
func doSomething() (int, error) {
    try SomeFunc()
    a, b := try AnotherFunc()

    // ...

    return 123, nil
}

2) Обработчик

Обратите внимание, что обработчики ошибок представляют собой простые блоки кода, предназначенные для встраивания, а не функции. Подробнее об этом ниже.

func doSomething() (int, error) {
    // Inline error handler
    a, b := try SomeFunc() else err {
        return 0, errors.Wrap(err, "error in doSomething:")
    }

    // Named error handlers
    handler logAndContinue err {
        log.Errorf("non-critical error: %v", err)
    }
    handler annotateAndReturn err {
        return 0, errors.Wrap(err, "error in doSomething:")
    }

    c, d := try SomeFunc() else logAndContinue
    e, f := try OtherFunc() else annotateAndReturn

    // ...

    return 123, nil
}

Предлагаемые ограничения:

• Вы можете только try вызвать функцию. Нет try err .
• Если вы не укажете обработчик, вы можете использовать только try внутри функции, которая возвращает ошибку как самое правое возвращаемое значение. Нет никаких изменений в поведении try в зависимости от контекста. Он никогда не паникует (как обсуждалось намного раньше в ветке).
• Не существует никакой "цепочки обработчиков". Обработчики — это просто встроенные блоки кода.

Преимущества:

• Синтаксис try / else можно тривиально превратить в существующее «составное условие if»:
  go a, b := try SomeFunc() else err { return 0, errors.Wrap(err, "error in doSomething:") }
  становится
  go if a, b, err := SomeFunc(); err != nil { return 0, errors.Wrap(err, "error in doSomething:") }
  На мой взгляд, составные if всегда казались скорее запутанными, чем полезными по очень простой причине: условные операторы обычно появляются _после_ операции и как-то связаны с обработкой ее результатов. Если операция втиснута внутрь условного оператора, просто менее очевидно, что она происходит. Глаз отвлекается. Кроме того, область видимости определенных переменных не так очевидна, как если бы они были самыми левыми в строке.
• Обработчики ошибок намеренно не определяются как функции (и не имеют ничего похожего на функциональную семантику). Это делает несколько вещей для нас:
  
  
  
  • Компилятор может просто встроить именованный обработчик везде, где на него ссылаются. Это больше похоже на простой шаблон макроса/codegen, чем на вызов функции. Среде выполнения даже не нужно знать, что обработчики существуют.
  
  
  • Мы не ограничены в том, что мы можем делать внутри обработчика. Мы обходим критику check / handle то, что «эта структура обработки ошибок хороша только для спасения». Мы также обходим критику «цепочки обработчиков». Любой произвольный код может быть помещен внутрь одного из этих обработчиков, и никакой другой поток управления не подразумевается.
  
  
  • Нам не нужно перехватывать return внутри обработчика, чтобы он означал super return . Перехват ключевого слова чрезвычайно сбивает с толку. return просто означает return , и нет реальной необходимости в super return .
  
  
  • defer не нужно подрабатывать в качестве механизма обработки ошибок. Мы можем продолжать думать об этом в основном как о способе очистки ресурсов и т. д.
  
  
• Что касается добавления контекста к ошибкам:
  
  
  
  • Добавление контекста с помощью обработчиков чрезвычайно просто и очень похоже на существующие блоки if err != nil
  
  
  • Несмотря на то, что конструкция «попробовать без обработчика» напрямую не поощряет добавление контекста, ее очень просто преобразовать в форму обработчика. Его предполагаемое использование в первую очередь будет во время разработки, и было бы очень просто написать проверку на go vet , чтобы выделить необработанные ошибки.
  
  

Извините, если эти идеи очень похожи на другие предложения — я старался не отставать от них всех, но, возможно, многое упустил.

@brynbellomy Спасибо за анализ ключевых слов - это очень полезная информация. Кажется, что try в качестве ключевого слова может подойти. (Вы говорите, что API не затронуты - это правда, но try может по-прежнему отображаться как имя параметра или что-то подобное - поэтому документацию, возможно, придется изменить. Но я согласен, что это не повлияет на клиентов этих пакетов.)

Что касается вашего предложения: оно будет прекрасно работать даже без именованных обработчиков, не так ли? (Это упростило бы предложение без потери мощности. Можно было бы просто вызвать локальную функцию из встроенного обработчика.)

Что касается вашего предложения: оно будет прекрасно работать даже без именованных обработчиков, не так ли? (Это упростило бы предложение без потери мощности. Можно было бы просто вызвать локальную функцию из встроенного обработчика.)

@griesemer В самом деле, мне было довольно прохладно включать их. Конечно, больше Go-ish без.

С другой стороны, кажется, что люди хотят иметь возможность выполнять однострочную обработку ошибок, включая однострочные, которые return . Типичным случаем будет log, затем return . Если мы раскошелимся на локальную функцию в предложении else , мы, вероятно, потеряем это:

a, b := try SomeFunc() else err {
    someLocalFunc(err)
    return 0, err
}

(Хотя я все же предпочитаю это составным если)

Тем не менее, вы все равно можете получить однострочный возврат, который добавляет контекст ошибки, реализовав простую настройку gofmt , обсуждавшуюся ранее в этой ветке:

a, b := try SomeFunc() else err { return 0, errors.Wrap(err, "bad stuff!") }

Нужно ли новое ключевое слово в приведенном выше предложении? Почему бы нет:

SomeFunc() else return
a, b := SomeOtherFunc() else err { return 0, errors.Wrap(err, "bad stuff!") }

@griesemer , если обработчики снова на столе, я предлагаю вам создать новую проблему для обсуждения try/handle или try/_label_. В этом предложении специально исключены обработчики, и существует бесчисленное множество способов их определения и вызова.

Любой, кто предлагает обработчики, должен сначала прочитать вики обратной связи проверки/обработки. Велика вероятность, что все, что вы придумаете, там уже описано :-)
https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback

@smonkewitz нет, в этой версии нет необходимости в новом ключевом слове, поскольку оно связано с операторами присваивания, которые до сих пор упоминались несколько раз в различном синтаксисе.

https://github.com/golang/go/issues/32437#issuecomment-499808741
https://github.com/golang/go/issues/32437#issuecomment-499852124
https://github.com/golang/go/issues/32437#issuecomment-500095505

@ianlancetaylor , команда go уже рассматривала этот особый вариант обработки ошибок? Его не так просто реализовать, как предлагаемый встроенный try, но он кажется более идиоматичным. ~ненужное заявление, извините.~

Я хотел бы повторить то, что сказал @deanveloper и еще несколько человек, но с собственным акцентом. В https://github.com/golang/go/issues/32437#issuecomment-498939499 @deanveloper сказал:

try — это условный возврат. И поток управления, и возврат в Go поддерживаются на пьедестале. Весь поток управления внутри функции имеет отступ, и все возвращаемые значения начинаются с return . Смешивание обеих этих концепций вместе в вызове функции, который легко пропустить, кажется немного странным.

Кроме того, в этом предложении try — это функция, возвращающая значения, поэтому ее можно использовать как часть более крупного выражения.

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

1. Паника не условна; он всегда прерывает вызывающую функцию.
2. Panic не возвращает никаких значений и поэтому может отображаться только как отдельная инструкция, что увеличивает ее видимость.

Попробуйте с другой стороны:

1. является условным; он может возвращаться или не возвращаться из вызывающей функции.
2. Возвращает значения и может появляться в составном выражении, возможно, несколько раз, в одной строке, потенциально за правым полем моего окна редактора.

По этим причинам я думаю, что try кажется больше, чем «откусил», я думаю, что это существенно вредит читабельности кода.

Сегодня, когда мы впервые сталкиваемся с кодом Go, мы можем быстро просмотреть его, чтобы найти возможные точки выхода и контрольные точки потока. Я считаю, что это очень ценное свойство кода Go. Используя try , становится слишком легко писать код, в котором отсутствует это свойство.

Я допускаю, что вполне вероятно, что разработчики Go, которые ценят читаемость кода, сойдутся на идиомах использования для try , которые избегают этих ловушек читабельности. Я надеюсь, что это произойдет, поскольку читабельность кода, похоже, является основной ценностью для многих разработчиков Go. Но для меня не очевидно, что try добавляет достаточно ценности по сравнению с существующими идиомами кода, чтобы нести вес добавления новой концепции к языку для всех, чтобы выучить, и это может так легко повредить читабельности.

````
если это != "сломал" {
не исправлять (это)
}

@ChrisHines К вашему замечанию (которое повторяется в другом месте этой темы), давайте добавим еще одно ограничение:

• любой оператор try (даже без обработчика) должен располагаться на отдельной строке.

Вы все равно выиграете от значительного снижения визуального шума. Затем у вас есть гарантированный возврат, аннотированный return , и условный возврат, аннотированный try , и эти ключевые слова всегда стоят в начале строки (или, в худшем случае, сразу после присваивания переменной).

Так что без всякой ерунды:

try EmitEvent(try (try DecodeMsg(m)).SaveToDB())

а скорее вот это:

dm := try DecodeMsg(m)
um := try dm.SaveToDB()
try EmitEvent(um)

что все еще кажется более ясным, чем это:

dm, err := DecodeMsg(m)
if err != nil {
    return nil, err
}

um, err := dm.SaveToDB()
if err != nil {
    return nil, err
}

err = EmitEvent(um)
if err != nil {
    return nil, err
}

Что мне нравится в этом дизайне, так это то, что невозможно молча игнорировать ошибки, не аннотируя их при этом. В то время как прямо сейчас вы иногда видите x, _ := SomeFunc() (что такое игнорируемое возвращаемое значение? ошибка? что-то еще?), теперь вам нужно четко аннотировать:

x := try SomeFunc() else err {}

Со времени моего предыдущего поста в поддержку этого предложения я увидел две идеи, опубликованные @jagv (без параметров try возвращает *error ) и @josharian (помеченные обработчики ошибок), которые, как мне кажется, слегка измененная форма значительно улучшила бы предложение.

Объединив эти идеи с еще одной, которую я придумал сам, у нас будет четыре версии try :

1. пытаться()
2. попробовать (параметры)
3. попытка (параметры, метка)
4. попытка (параметры, паника)

1 просто вернул бы указатель на параметр возврата ошибки (ERP) или ноль, если его не было (только #4). Это обеспечило бы альтернативу именованной ERP без необходимости добавления дополнительных встроенных модулей.

2 будет работать точно так, как предполагается в настоящее время. Ненулевая ошибка будет возвращена немедленно, но может быть украшена оператором defer .

3 будет работать, как предложил @josharian , т.е. при ненулевой ошибке код будет переходить к метке. Однако не будет метки обработчика ошибок по умолчанию, так как этот случай теперь выродится в № 2.

Мне кажется, что обычно это лучший способ оформления ошибок (или обработки их локально, а затем возврата nil), чем defer , так как это проще и быстрее. Любой, кому это не нравилось, все еще мог использовать № 2.

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

Таким образом, нормальная метка и поведение goto будут применяться (как сказал @josharian ) к # 26058, исправленному в первую очередь, но я думаю, что это все равно должно быть исправлено.

Название ярлыка не может быть panic , так как это будет противоречить #4.

4 немедленно panic вместо возврата или ветвления. Следовательно, если бы это была единственная версия try , используемая в конкретной функции, ERP не потребовалось бы.

Я добавил это, чтобы пакет тестирования мог работать так, как сейчас, без необходимости дополнительных встроенных или других изменений. Однако это может быть полезно и в других _фатальных_ сценариях.

Это должна быть отдельная версия try , так как альтернатива перехода к обработчику ошибок, а затем паника, все равно потребует ERP.

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

Например, @deanveloper очень хорошо выразил эту озабоченность в https://github.com/golang/go/issues/32437#issuecomment -498932961, что, я думаю, является комментарием, получившим наибольшее количество голосов.

@dominikh написал в https://github.com/golang/go/issues/32437#issuecomment -499067357:

В коде, созданном с помощью gofmt, return всегда соответствует /^\t*return / — это очень простой шаблон, который можно обнаружить на глаз без посторонней помощи. try, с другой стороны, может встречаться в любом месте кода, вложенного произвольно глубоко в вызовы функций. Никакое обучение не позволит нам сразу определить весь поток управления в функции без помощи инструментов.

Чтобы помочь с этим, @brynbellomy предложил вчера:

любой оператор try (даже без обработчика) должен располагаться на отдельной строке.

Принимая это во внимание, try может потребоваться в качестве начала строки даже для присваивания.

Так что это может быть:

try dm := DecodeMsg(m)
try um := dm.SaveToDB()
try EmitEvent(um)

а не следующее (из примера @brynbellomy ):

dm, err := DecodeMsg(m)
if err != nil {
    return nil, err
}

um, err := dm.SaveToDB()
if err != nil {
    return nil, err
}

err = EmitEvent(um)
if err != nil {
    return nil, err
}

Кажется, это сохранит достаточную видимость даже без какого-либо редактора или помощи IDE, при этом уменьшив шаблон.

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

Предложение включает в себя этот пример:

info := try(try(os.Open(file)).Stat())    // proposed try built-in

Вместо этого может быть:

try f := os.Open(file)
try info := f.Stat()

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

@elagergren-spideroak предоставил этот пример:

try(try(try(to()).parse().this)).easily())

Я думаю, что это несоответствие скобок, что, возможно, является преднамеренным замечанием или тонким юмором, поэтому я не уверен, предназначен ли этот пример для 2 try или 3 try . В любом случае, возможно, было бы лучше потребовать распространения на 2-3 строки, начинающиеся с try .

@thepudds , это то, что я имел в виду в своем предыдущем комментарии. За исключением того, что дано

try f := os.Open(file)
try info := f.Stat()

Очевидно, что нужно думать о try как о блоке try, в котором в круглых скобках может быть заключено более одного предложения. Таким образом, вышеизложенное может стать

try (
    f := os.Open(file)
    into := f.Stat()
)

Если компилятор знает, как с этим справиться, то же самое работает и для вложенности. Итак, теперь вышеизложенное может стать

try info := os.Open(file).Stat()

Из сигнатур функций компилятор знает, что Open может возвращать значение ошибки, и, поскольку он находится в блоке try, ему необходимо сгенерировать обработку ошибок, а затем вызвать Stat() для основного возвращаемого значения и так далее.

Следующее, что нужно сделать, это разрешить операторы, в которых либо не генерируется значение ошибки, либо обрабатывается локально. Итак, теперь вы можете сказать

try (
    f := os.Open(file)
    debug("f: %v\n", f) // debug returns nothing
    into := f.Stat()
)

Это позволяет развивать код без перестановки блоков try. Но по какой-то странной причине люди думают, что обработка ошибок должна быть явно прописана! Они хотят

try(try(try(to()).parse()).this)).easily())

Пока меня все устраивает

try to().parse().this().easily()

Хотя в обоих случаях может быть сгенерирован один и тот же код проверки ошибок. Я считаю, что вы всегда можете написать специальный код для обработки ошибок, если вам это нужно. try (или как бы вы это ни называли) просто упорядочивает обработку ошибок по умолчанию (то есть направляет ее вызывающей стороне).

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

Меня несколько беспокоила удобочитаемость программ, в которых try появляется внутри других выражений. Поэтому я запустил grep "return .*err$" в стандартной библиотеке и начал читать блоки случайным образом. Всего 7214 результатов, я прочитал только пару сотен.

Первое, что следует отметить, это то, что там, где применяется try , почти все эти блоки становятся немного более читабельными.

Во-вторых, очень немногие из них, менее 1 из 10, поместили бы try в другое выражение. Типичным случаем являются операторы вида x := try(...) или ^try(...)$ .

Вот несколько примеров, когда try появляется внутри другого выражения:

текст/шаблон

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        lessOrEqual, err := le(arg1, arg2)
        if err != nil {
                return false, err
        }
        return !lessOrEqual, nil
}

становится:

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        return !try(le(arg1, arg2)), nil
}

текст/шаблон

func index(item reflect.Value, indices ...reflect.Value) (reflect.Value, error) {
...
        switch v.Kind() {
        case reflect.Map:
                index, err := prepareArg(index, v.Type().Key())
                if err != nil {
                        return reflect.Value{}, err
                }
                if x := v.MapIndex(index); x.IsValid() {
                        v = x
                } else {
                        v = reflect.Zero(v.Type().Elem())
                }
        ...
        }
}

становится

func index(item reflect.Value, indices ...reflect.Value) (reflect.Value, error) {
        ...
        switch v.Kind() {
        case reflect.Map:
                if x := v.MapIndex(try(prepareArg(index, v.Type().Key()))); x.IsValid() {
                        v = x
                } else {
                        v = reflect.Zero(v.Type().Elem())
                }
        ...
        }
}

(это самый сомнительный пример, который я видел)

регулярное выражение/синтаксис:

regexp/syntax/parse.go

func Parse(s string, flags Flags) (*Regexp, error) {
        ...
        if c, t, err = nextRune(t); err != nil {
                return nil, err
        }
        p.literal(c)
        ...
}

становится

func Parse(s string, flags Flags) (*Regexp, error) {
        ...
        c, t = try(nextRune(t))
        p.literal(c)
        ...
}

Это не пример try внутри другого выражения, но я хочу вызвать его, потому что это улучшает читабельность. Здесь гораздо легче увидеть, что значения c и t находятся за пределами действия оператора if.

сеть/http

сеть/http/request.go:readRequest

        mimeHeader, err := tp.ReadMIMEHeader()
        if err != nil {
                return nil, err
        }
        req.Header = Header(mimeHeader)

становится:

        req.Header = Header(try(tp.ReadMIMEHeader())

база данных/sql

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                connector, err := driverCtx.OpenConnector(dataSourceName)
                if err != nil {
                        return nil, err
                }
                return OpenDB(connector), nil
        }

становится

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                return OpenDB(try(driverCtx.OpenConnector(dataSourceName))), nil
        }

база данных/sql

        si, err := ctxDriverPrepare(ctx, dc.ci, query)
        if err != nil {
                return nil, err
        }
        ds := &driverStmt{Locker: dc, si: si}

становится

        ds := &driverStmt{
                Locker: dc,
                si: try(ctxDriverPrepare(ctx, dc.ci, query)),
        }

сеть/http

        if http2isconnectioncloserequest(req) && dialonmiss {
                // it gets its own connection.
                http2tracegetconn(req, addr)
                const singleuse = true
                cc, err := p.t.dialclientconn(addr, singleuse)
                if err != nil {
                        return nil, err
                }
                return cc, nil
        }

становится

        if http2isconnectioncloserequest(req) && dialonmiss {
                // it gets its own connection.
                http2tracegetconn(req, addr)
                const singleuse = true
                return try(p.t.dialclientconn(addr, singleuse))
        }

сеть/http

func (f *http2Framer) endWrite() error {
        ...
        n, err := f.w.Write(f.wbuf)
        if err == nil && n != len(f.wbuf) {
                err = io.ErrShortWrite
        }
        return err
}

становится

func (f *http2Framer) endWrite() error {
        ...
        if try(f.w.Write(f.wbuf) != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

(Этот мне очень нравится.)

сеть/http

        if f, err := fr.ReadFrame(); err != nil {
                return nil, err
        } else {
                hc = f.(*http2ContinuationFrame) // guaranteed by checkFrameOrder
        }

становится

        hc = try(fr.ReadFrame()).(*http2ContinuationFrame)// guaranteed by checkFrameOrder

}

(Тоже приятно.)

сеть :

        if ctrlFn != nil {
                c, err := newRawConn(fd)
                if err != nil {
                        return err
                }
                if err := ctrlFn(fd.ctrlNetwork(), laddr.String(), c); err != nil {
                        return err
                }
        }

становится

        if ctrlFn != nil {
                try(ctrlFn(fd.ctrlNetwork(), laddr.String(), try(newRawConn(fd))))
        }

может быть, это слишком много, и вместо этого должно быть:

        if ctrlFn != nil {
                c := try(newRawConn(fd))
                try(ctrlFn(fd.ctrlNetwork(), laddr.String(), c))
        }

В целом, мне очень нравится эффект try на код стандартной библиотеки, который я читаю.

И последнее замечание: использование try для чтения кода помимо нескольких примеров в предложении было поучительным. Я думаю, что стоит подумать о написании инструмента для автоматического преобразования кода для использования try (где это не меняет семантику программы). Было бы интересно прочитать образец различий, созданных с популярными пакетами на github, чтобы увидеть, выдержит ли то, что я нашел в стандартной библиотеке. Выходные данные такой программы могли бы дать дополнительное представление о влиянии предложения.

@crawshaw спасибо за это, было здорово увидеть это в действии. Но увидев его в действии, я более серьезно отнесся к аргументам против встроенной обработки ошибок, которые до сих пор отвергал.

Поскольку это было так близко к интересному предложению @thepudds сделать try оператором, я переписал все примеры, используя этот синтаксис, и нашел его намного яснее, чем выражение- try или статус-кво, не требуя слишком много дополнительных строк:

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        try lessOrEqual := le(arg1, arg2)
        return !lessOrEqual, nil
}

func index(item reflect.Value, indices ...reflect.Value) (reflect.Value, error) {
        ...
        switch v.Kind() {
        case reflect.Map:
                try index := prepareArg(index, v.Type().Key())
                if x := v.MapIndex(index); x.IsValid() {
                        v = x
                } else {
                        v = reflect.Zero(v.Type().Elem())
                }
        ...
        }
}

func Parse(s string, flags Flags) (*Regexp, error) {
        ...
        try c, t = nextRune(t)
        p.literal(c)
        ...
}

        try mimeHeader := tp.ReadMIMEHeader()
        req.Header = Header(mimeHeader)

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                try connector := driverCtx.OpenConnector(dataSourceName)
                return OpenDB(connector), nil
        }

Это, возможно, было бы лучше с выражением - try , если бы было несколько полей, которые должны были быть try -ed, но я все же предпочитаю баланс этого компромисса.

        try si := ctxDriverPrepare(ctx, dc.ci, query)
        ds := &driverStmt{Locker: dc, si: si}

Это в основном наихудший случай для этого, и он выглядит нормально:

        if http2isconnectioncloserequest(req) && dialonmiss {
                // it gets its own connection.
                http2tracegetconn(req, addr)
                const singleuse = true
                try cc := p.t.dialclientconn(addr, singleuse)
                return cc, nil
        }

Я спорил с собой, будет ли if try законным или должен быть законным, но я не мог найти разумного объяснения, почему это не должно быть, и здесь это работает довольно хорошо:

func (f *http2Framer) endWrite() error {
        ...
        if try n := f.w.Write(f.wbuf); n != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

        try f := fr.ReadFrame()
        hc = f.(*http2ContinuationFrame) // guaranteed by checkFrameOrder

        if ctrlFn != nil {
                try c := newRawConn(fd)
                try ctrlFn(fd.ctrlNetwork(), laddr.String(), c)
        }

Просматривая примеры @crawshaw , я только больше убеждаюсь, что поток управления часто делается достаточно загадочным, чтобы быть еще более осторожным в дизайне. Связывание даже небольшой сложности становится трудным для чтения и легко испортить. Я рад рассмотреть варианты, но усложнение потока управления в таком защищенном языке кажется исключительно нехарактерным.

func (f *http2Framer) endWrite() error {
        ...
        if try(f.w.Write(f.wbuf) != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

Кроме того, try ничего не "пытается". Это «защитное реле». Если базовая семантика предложения отключена, я не удивлен, что полученный код также проблематичен.

func (f *http2Framer) endWrite() error {
        ...
        relay n := f.w.Write(f.wbuf)
        return checkShortWrite(n, len(f.wbuf))
}

Если вы делаете оператор try, вы можете использовать флаг, чтобы указать, какое возвращаемое значение и какое действие:

try c, @      := newRawConn(fd) // return
try c, <strong i="6">@panic</strong> := newRawConn(fd) // panic
try c, <strong i="7">@hname</strong> := newRawConn(fd) // invoke named handler
try c, <strong i="8">@_</strong>     := newRawConn(fd) // ignore, or invoke "ignored" handler if defined

Вам по-прежнему нужен синтаксис подвыражения (Расс заявил, что это требование), по крайней мере, для действий паники и игнорирования.

Во-первых, я аплодирую @crawshaw за то, что он нашел время, чтобы просмотреть примерно 200 реальных примеров, и уделил время своему вдумчивому описанию выше.

Во-вторых, @jimmyfrasche , относительно вашего ответа здесь о примере http2Framer :

Я спорил с собой, будет ли if try законным или должен быть законным, но я не мог придумать разумного объяснения, почему это не должно быть, и здесь это работает довольно хорошо:

```
func (f *http2Framer) ошибка endWrite() {
...
если попробовать n := fwWrite(f.wbuf); п != len(f.wbuf) {
вернуть io.ErrShortWrite
}
вернуть ноль
}

At least under what I was suggesting above in https://github.com/golang/go/issues/32437#issuecomment-500213884, under that proposal variation I would suggest `if try` is not allowed.

That `http2Framer` example could instead be:

func (f *http2Framer) ошибка endWrite() {
...
попробуйте n := fwWrite(f.wbuf)
если n != len(f.wbuf) {
вернуть io.ErrShortWrite
}
вернуть ноль
}
`` That is one line longer, but hopefully still "light on the page". Personally, I think that (arguably) reads more cleanly, but more importantly it is easier to see the попробуйте`.

@deanveloper написал выше в https://github.com/golang/go/issues/32437#issuecomment -498932961:

Возврат из функции, казалось, был «священным» делом.

Этот конкретный пример http2Framer оказывается не таким коротким, как мог бы быть. Тем не менее, возврат из функции более «священен», если try должен быть первым в строке.

@crowshaw упомянул:

Во-вторых, очень немногие из них, менее 1 из 10, поместили бы try внутрь другого выражения. Типичным случаем являются операторы вида x := try(...) или ^try(...)$.

Может быть, можно лишь частично помочь тем 1 из 10 примеров с более ограниченной формой try , особенно если типичный случай из этих примеров заканчивается тем же количеством строк, даже если try должен быть первым в строке?

@джиммифраше

@crawshaw спасибо за это, было здорово увидеть это в действии. Но увидев его в действии, я более серьезно отнесся к аргументам против встроенной обработки ошибок, которые до сих пор отвергал.

Поскольку это было так близко к интересному предложению @thepudds сделать try оператором, я переписал все примеры, используя этот синтаксис, и нашел его намного яснее, чем выражение- try или статус-кво, не требуя слишком много дополнительных строк:

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        try lessOrEqual := le(arg1, arg2)
        return !lessOrEqual, nil
}

Ваш первый пример хорошо иллюстрирует, почему я предпочитаю выражение try . В вашей версии я должен поместить результат вызова le в переменную, но эта переменная не имеет семантического значения, которое термин le еще не подразумевает. Поэтому я не могу дать ему имя, которое не было бы либо бессмысленным (например, x ), либо избыточным (например, lessOrEqual ). С выражением- try промежуточная переменная не нужна, так что эта проблема даже не возникает.

Я предпочел бы не тратить умственные усилия на придумывание названий для вещей, которые лучше оставить анонимными.

Я рад поддержать несколько последних сообщений, в которых try (ключевое слово) было перемещено в начало строки. Он действительно должен иметь то же визуальное пространство, что и return .

Re: Предложение @jimmyfrasche разрешить try в составных операторах if — это именно то, чего, я думаю, многие здесь пытаются избежать по нескольким причинам:

• он объединяет два очень разных механизма потока управления в одну строку
• выражение try на самом деле вычисляется первым и может привести к возврату функции, но оно появляется после if
• они возвращаются с совершенно разными ошибками, одну из которых мы на самом деле не видим в коде, а другую видим
• это делает менее очевидным, что try фактически не обрабатывается, потому что блок очень похож на блок обработчика (хотя он обрабатывает совершенно другую проблему)

Можно подойти к этой ситуации с несколько иной точки зрения, предпочитая подталкивать людей к обработке try s. Как насчет того, чтобы позволить синтаксису try / else содержать последующие условные операторы (что является общим шаблоном для многих функций ввода-вывода, которые возвращают как err , так и n , любой из которых может указывать на проблему):

func (f *http2Framer) endWrite() error {
        // ...
        try n := f.w.Write(f.wbuf) else err {
                return errors.Wrap(err, "error writing:")
        } else if n != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

В случае, если вы не обрабатываете ошибку, возвращаемую .Write , у вас все равно будет четкая аннотация о том, что .Write может привести к ошибке (как указано @thepudds):

func (f *http2Framer) endWrite() error {
        // ...
        try n := f.w.Write(f.wbuf)
        if n != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

Я второй ответ @daved . На мой взгляд, каждый пример, который выделил @crawshaw , стал менее ясным и более подверженным ошибкам в результате try .

Я рад поддержать несколько последних сообщений, в которых try (ключевое слово) было перемещено в начало строки. Он действительно должен иметь то же визуальное пространство, что и return .

Учитывая два варианта для этой точки и предполагая, что был выбран один из них, что создало своего рода прецедент для будущих потенциальных функций:

А.)

try f := os.Open(filepath) else err {
    return errors.Wrap(err, "can't open")
}

Б.)

f := try os.Open(filepath) else err {
    return errors.Wrap(err, "can't open")
}

Какой из двух обеспечивает большую гибкость для будущего использования новых ключевых слов? _(Я не знаю ответа на этот вопрос, так как не освоил тёмное искусство написания компиляторов.)_ Будет ли один подход более ограничивающим, чем другой?

@davecheney @daved @crowshaw
Я склонен согласиться с Дэйвами в этом вопросе: в примерах @crawshaw есть много операторов try , встроенных глубоко в строки, в которых происходит много других вещей. Действительно трудно определить точки выхода. Кроме того, скобки try в некоторых примерах сильно загромождают.

Очень полезно видеть кучу преобразованного кода stdlib, поэтому я взял те же примеры, но переписал их в соответствии с альтернативным предложением, которое является более строгим:

• try в качестве ключевого слова
• только один try в строке
• try должен стоять в начале строки

Надеюсь, это поможет нам сравнить. Лично я считаю, что эти примеры выглядят намного более краткими, чем их оригиналы, но не затеняют поток управления. try остается очень заметным везде, где он используется.

текст/шаблон

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        lessOrEqual, err := le(arg1, arg2)
        if err != nil {
                return false, err
        }
        return !lessOrEqual, nil
}

становится:

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        try lessOrEqual := le(arg1, arg2)
        return !lessOrEqual, nil
}

текст/шаблон

func index(item reflect.Value, indices ...reflect.Value) (reflect.Value, error) {
...
        switch v.Kind() {
        case reflect.Map:
                index, err := prepareArg(index, v.Type().Key())
                if err != nil {
                        return reflect.Value{}, err
                }
                if x := v.MapIndex(index); x.IsValid() {
                        v = x
                } else {
                        v = reflect.Zero(v.Type().Elem())
                }
        ...
        }
}

становится

func index(item reflect.Value, indices ...reflect.Value) (reflect.Value, error) {
        ...
        switch v.Kind() {
        case reflect.Map:
                try index := prepareArg(index, v.Type().Key())
                if x := v.MapIndex(index); x.IsValid() {
                        v = x
                } else {
                        v = reflect.Zero(v.Type().Elem())
                }
        ...
        }
}

регулярное выражение/синтаксис:

regexp/syntax/parse.go

func Parse(s string, flags Flags) (*Regexp, error) {
        ...
        if c, t, err = nextRune(t); err != nil {
                return nil, err
        }
        p.literal(c)
        ...
}

становится

func Parse(s string, flags Flags) (*Regexp, error) {
        ...
        try c, t = nextRune(t)
        p.literal(c)
        ...
}

сеть/http

сеть/http/request.go:readRequest

        mimeHeader, err := tp.ReadMIMEHeader()
        if err != nil {
                return nil, err
        }
        req.Header = Header(mimeHeader)

становится:

        try mimeHeader := tp.ReadMIMEHeader()
        req.Header = Header(mimeHeader)

база данных/sql

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                connector, err := driverCtx.OpenConnector(dataSourceName)
                if err != nil {
                        return nil, err
                }
                return OpenDB(connector), nil
        }

становится

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                try connector := driverCtx.OpenConnector(dataSourceName)
                return OpenDB(connector), nil
        }

база данных/sql

        si, err := ctxDriverPrepare(ctx, dc.ci, query)
        if err != nil {
                return nil, err
        }
        ds := &driverStmt{Locker: dc, si: si}

становится

        try si := ctxDriverPrepare(ctx, dc.ci, query)
        ds := &driverStmt{Locker: dc, si: si}

сеть/http

        if http2isconnectioncloserequest(req) && dialonmiss {
                // it gets its own connection.
                http2tracegetconn(req, addr)
                const singleuse = true
                cc, err := p.t.dialclientconn(addr, singleuse)
                if err != nil {
                        return nil, err
                }
                return cc, nil
        }

становится

        if http2isconnectioncloserequest(req) && dialonmiss {
                // it gets its own connection.
                http2tracegetconn(req, addr)
                const singleuse = true
                try cc := p.t.dialclientconn(addr, singleuse)
                return cc, nil
        }

сеть/http
Это на самом деле не экономит нам ни одной строки, но я нахожу его намного понятнее, потому что if err == nil — относительно необычная конструкция.

func (f *http2Framer) endWrite() error {
        ...
        n, err := f.w.Write(f.wbuf)
        if err == nil && n != len(f.wbuf) {
                err = io.ErrShortWrite
        }
        return err
}

становится

func (f *http2Framer) endWrite() error {
        ...
        try n := f.w.Write(f.wbuf)
        if n != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

сеть/http

        if f, err := fr.ReadFrame(); err != nil {
                return nil, err
        } else {
                hc = f.(*http2ContinuationFrame) // guaranteed by checkFrameOrder
        }

становится

        try f := fr.ReadFrame()
        hc = f.(*http2ContinuationFrame) // guaranteed by checkFrameOrder
}

сеть:

        if ctrlFn != nil {
                c, err := newRawConn(fd)
                if err != nil {
                        return err
                }
                if err := ctrlFn(fd.ctrlNetwork(), laddr.String(), c); err != nil {
                        return err
                }
        }

становится

        if ctrlFn != nil {
                try c := newRawConn(fd)
                try ctrlFn(fd.ctrlNetwork(), laddr.String(), c)
        }

@james-lawrence В ответ на https://github.com/golang/go/issues/32437#issuecomment -500116099 : я не припомню, чтобы такие идеи, как необязательный , err , серьезно рассматривались, нет. Лично я думаю, что это плохая идея, потому что это означает, что если функция изменится, чтобы добавить завершающий параметр error , существующий код продолжит компилироваться, но будет действовать совсем по-другому.

Использование defer для обработки ошибок имеет большой смысл, но это приводит к необходимости называть ошибку и создавать новый тип шаблона if err != nil .

Внешние обработчики должны сделать это:

func handler(err *error) {
  if *err != nil {
    *err = handle(*err)
  }
} 

который используется как

defer handler(&err)

Внешние обработчики должны быть написаны только один раз, но должны быть две версии многих функций обработки ошибок: одна предназначена для отсрочки, а другая — для обычного использования.

Внутренние обработчики должны сделать это:

defer func() {
  if err != nil {
    err = handle(err)
  }
}()

В обоих случаях ошибка внешней функции должна быть названа, чтобы к ней можно было получить доступ.

Как я упоминал ранее в ветке, это можно абстрагировать в одну функцию:

func catch(err *error, handle func(error) error) {
  if *err != nil && handle != nil {
    *err = handle(*err)
  }
}

Это противоречит озабоченности @griesemer по поводу неоднозначности функций обработчика nil и имеет свои собственные шаблоны defer и func(err error) error , в дополнение к необходимости называть err во внешней функции.

Если try заканчивается как ключевое слово, то может иметь смысл использовать ключевое слово catch , которое также будет описано ниже.

Синтаксически это будет очень похоже на handle :

catch err {
  return handleThe(err)
}

Семантически это было бы сахаром для кода внутреннего обработчика выше:

defer func() {
  if err != nil {
    err = handleThe(err)
  }
}()

Поскольку это несколько волшебно, он может перехватить ошибку внешней функции, даже если она не была названа. ( err после catch больше похоже на имя параметра для блока catch ).

catch будет иметь то же ограничение, что и try , что он должен быть в функции, которая имеет окончательный возврат ошибки, поскольку они оба являются сахаром, который зависит от этого.

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

Сложная обработка ошибок может потребовать не использовать catch так же, как может потребовать не использовать try .

Поскольку они оба являются сахаром, нет необходимости использовать catch с try . Обработчики catch запускаются всякий раз, когда функция возвращает ошибку, отличную от nil , что позволяет, например, быстро записывать в журнал:

catch err {
  log.Print(err)
  return err
}

или просто обернуть все возвращенные ошибки:

catch err {
  return fmt.Errorf("foo: %w", err)
}

@ianlancetaylor

_" Я думаю, что это плохая идея, потому что это означает, что если функция изменится, чтобы добавить завершающий параметр error , существующий код продолжит компилироваться, но будет действовать совсем по-другому."_

Вероятно, это правильный способ взглянуть на это, если вы можете контролировать как восходящий, так и нисходящий код, так что, если вам нужно изменить сигнатуру функции, чтобы также вернуть ошибку, вы можете это сделать.

Но я бы попросил вас подумать, что происходит, когда кто-то не контролирует ни вышестоящую, ни нижестоящую часть своих пакетов? А также рассмотреть варианты использования, в которых могут быть добавлены ошибки, и что произойдет, если ошибки необходимо добавить, но вы не можете заставить изменить нижестоящий код?

Можете ли вы привести пример, когда кто-то меняет подпись, чтобы добавить возвращаемое значение? Для меня они обычно попадали в категорию _ «Я не понимал, что может произойти ошибка» _ или _ «Я чувствую себя ленивым и не хочу прикладывать усилия, потому что ошибка, вероятно, не произойдет». _

В обоих этих случаях я мог бы добавить возврат ошибки, потому что становится очевидным, что ошибку необходимо обработать. В таком случае, если я не могу изменить подпись, потому что не хочу нарушать совместимость для других разработчиков, использующих мои пакеты, что делать? Я предполагаю, что в подавляющем большинстве случаев ошибка будет возникать и что код, вызывающий func, который не возвращает ошибку, будет действовать совсем по-другому, _все равно._

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

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

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

Например, рассмотрите возможность добавления обработчика ошибок пакета, который необходимо установить, прежде чем можно будет игнорировать ошибки?

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

Мы, суслики, привыкли возвращать ошибку, а не генерировать исключение, поэтому у меня возникает вопрос: «Почему бы нам не возвращать ошибки из каждой функции?» Мы не всегда делаем это, потому что написание кода без обработки ошибок удобнее, чем кодировать с ним. Поэтому мы опускаем обработку ошибок, когда думаем, что можем обойтись без нее. Но часто мы ошибаемся.

Так что на самом деле, если бы можно было понять, как сделать код элегантным и читабельным, я бы сказал, что возвращаемые значения и ошибки действительно должны обрабатываться отдельно, и что _каждая_ функция должна иметь возможность возвращать ошибки независимо от ее прошлых сигнатур функций. И заставить существующий код изящно обрабатывать код, который теперь генерирует ошибки, было бы стоящим усилием.

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

Ключевое слово try , безусловно, улучшает читаемость (по сравнению с вызовом функции) и кажется менее сложным. @brynbellomy @crawshaw спасибо, что нашли время написать примеры.

Я полагаю, моя общая мысль такова, что try делает слишком много. Он решает: вызвать функцию, назначить переменные, проверить ошибку и вернуть ошибку, если она существует. Я предлагаю вместо этого сократить объем и решить только для условного возврата: «возврат, если последний аргумент не равен нулю».

Возможно, это не новая идея... Но просмотрев предложения в вики с отзывами об ошибках , я ее не нашел (не значит, что ее там нет)

Мини-предложение по условному возврату

отрывок:

err, thing := newThing(name)
refuse nil, err

Я также добавил его в вики в разделе «альтернативные идеи».

Ничего не делать также кажется очень разумным вариантом.

@alexhornbake , который наводит меня на несколько иную идею, которая была бы более полезной.

assert(nil, err)
assert(len(a), len(b))
assert(true, condition)
assert(expected, given)

таким образом, это будет применяться не только к проверке ошибок, но и ко многим типам логических ошибок.

Данное значение будет завернуто в ошибку и возвращено.

@alexhornbake

Точно так же, как try на самом деле не пытается, refuse на самом деле не «отказывается». Общее намерение здесь заключалось в том, что мы устанавливаем «защитное реле» ( relay — короткое, точное и аллитеративное слово к return ), которое «срабатывает», когда одно из подключенных значений соответствует условию. (т.е. ненулевая ошибка). Это своего рода автоматический выключатель, и я считаю, что он может повысить ценность, если его дизайн будет ограничен неинтересными случаями, чтобы просто уменьшить некоторые из самых низко висящих шаблонов. Все, что хоть немного сложно, должно основываться на простом коде Go.

Я также благодарю Краншоу за его работу по просмотру стандартной библиотеки, но я пришел к совершенно другому выводу... Я думаю, что почти все эти фрагменты кода труднее читать и они более склонны к неправильному пониманию.

        req.Header = Header(try(tp.ReadMIMEHeader())

Я очень часто упускаю из виду, что это может привести к ошибке. Быстрое чтение дает мне «хорошо, установите заголовок в заголовок ReadMimeHeader вещи».

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                return OpenDB(try(driverCtx.OpenConnector(dataSourceName))), nil
        }

На этот раз мои глаза просто пересекаются, пытаясь разобрать эту строку OpenDB. Там так много плотности ... Это показывает основную проблему, которая есть у всех вызовов вложенных функций, в том, что вы должны читать изнутри, и вы должны анализировать это в своей голове, чтобы выяснить, где находится самая внутренняя часть .

Также обратите внимание, что это может вернуться из двух разных мест в одной и той же строке... вы будете отлаживать, и он скажет, что из этой строки была возвращена ошибка, и первое, что все собираются сделать, это попытаться выясните, почему OpenDB дает сбой с этой странной ошибкой, когда на самом деле происходит сбой OpenConnector (или наоборот).

        ds := &driverStmt{
                Locker: dc,
                si: try(ctxDriverPrepare(ctx, dc.ci, query)),
        }   

Это место, где код может дать сбой там, где раньше это было невозможно. Без try построение литералов структуры не может завершиться ошибкой . Мои глаза будут скользить по нему, как "хорошо, создание driverStmt... идем дальше...", и это будет так легко пропустить, что на самом деле это может привести к ошибке вашей функции. Единственный способ, который был бы возможен раньше, это если бы ctxDriverPrepare запаниковал... и мы все знаем, что это случай, когда 1.) в принципе никогда не должно произойти и 2.) если это произойдет, это означает, что что-то совершенно неправильно.

Попробовав ключевое слово и оператор, я исправляю многие свои проблемы с ним. Я знаю, что это не имеет обратной совместимости, но я не думаю, что использование худшей версии является решением проблемы обратной совместимости.

@daved Я не уверен, что следую. Вам не нравится название или идея?

В любом случае, я разместил это здесь в качестве альтернативы ... Если есть законный интерес, я могу открыть новую тему для обсуждения, не хочу загрязнять эту ветку (может быть, слишком поздно?) Большой палец вверх / вниз по оригинальной идее даст нам смысл... Конечно открыты для альтернативных имен. Важной частью является «условный возврат без попытки обработки присваивания».

Хотя мне нравится предложение catch от @jimmyfrasche , я хотел бы предложить альтернативу:
go handler fmt.HandleErrorf("copy %s %s", src, dst)
будет эквивалентно:
go defer func(){ if(err != nil){ fmt.HandleErrorf(&err,"copy %s %s", src, dst) } }()
где err — последнее именованное возвращаемое значение с ошибкой типа. Однако обработчики также могут использоваться, когда возвращаемые значения не названы. Допускается и более общий случай:
go handler func(err *error){ *err = fmt.Errorf("foo: %w", *err) }() `
Основная проблема, с которой я столкнулся при использовании именованных возвращаемых значений (которую catch не решает), заключается в том, что ошибка избыточна. При откладывании вызова обработчика, такого как fmt.HandleErrorf , нет разумного первого аргумента, кроме указателя на возвращаемое значение ошибки, зачем давать пользователю возможность совершить ошибку?

По сравнению с catch основное отличие состоит в том, что handler немного упрощает вызов предопределенных обработчиков за счет более подробного определения их на месте. Я не уверен, что это идеально, но я думаю, что это больше соответствует первоначальному предложению.

@yiius catch , как я определил, не требует имени err в функции, содержащей catch .

В catch err { err — это имя ошибки в блоке catch . Это похоже на имя параметра функции.

При этом нет необходимости в чем-то вроде fmt.HandleErrorf , потому что вы можете просто использовать обычный fmt.Errorf :

func f() error {
  catch err {
    return fmt.Errorf("foo: %w", err)
  }
  return errors.New("bar")
}

который возвращает ошибку, которая печатается как foo: bar .

Мне не нравится такой подход, потому что:

• Вызов функции try() прерывает выполнение кода в родительской функции.
• нет ключевого слова return , но код действительно возвращается.

Предлагается множество способов создания обработчиков, но я думаю, что они часто упускают два ключевых требования:

1. Он должен значительно отличаться и лучше, чем if x, err := thingie(); err != nil { handle(err) } . Я думаю, что предложения вроде try x := thingie else err { handle(err) } не соответствуют этой планке. Почему бы просто не сказать if ?

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

Помните об этих пожеланиях, когда мы обсуждаем альтернативные механизмы для try /handle.

@carlmjohnson Мне нравится идея @jimmyfrasche catch относительно вашего пункта 2 - это просто синтаксический сахар для defer , который экономит 2 строки и позволяет вам не называть возвращаемое значение ошибки (которое в очередь также потребует от вас назвать все остальные, если вы еще этого не сделали). Это не вызывает проблемы ортогональности с defer , потому что это defer .

повторяя то, что сказал @ubombi :

Вызов функции try() прерывает выполнение кода в родительской функции.; нет ключевого слова return, но код действительно возвращается.

В Ruby procs и lambdas являются примером того, что делает try ... proc — это блок кода, который его оператор return возвращает не из самого блока, а из вызывающего.

Это именно то, что делает try ... это просто предопределенная процедура Ruby.

Я думаю, что если бы мы собирались пойти по этому пути, возможно, мы действительно могли бы позволить пользователю определить свою собственную функцию try , введя proc functions

Я по-прежнему предпочитаю if err != nil , потому что это более читабельно, но я думаю, что try было бы полезнее, если бы пользователь определял свой собственный процесс:

proc try(err *error, msg string) {
  if *err != nil {
    *err = fmt.Errorf("%v: %w", msg, *err)
    return
  }
}

И тогда вы можете назвать это:

func someFunc() (string, error) {
  err := doSomething()
  try(&err, "someFunc failed")
}

Преимущество здесь в том, что вы можете определить обработку ошибок в своих собственных терминах. И вы также можете сделать proc открытым, закрытым или внутренним.

Это также лучше, чем предложение handle {} в исходном предложении Go2, потому что вы можете определить его только один раз для всей кодовой базы, а не для каждой функции.

Одним из соображений удобочитаемости является то, что func() и proc() могут вызываться по-разному, например, func() и proc!() , чтобы программист знал, что вызов proc может фактически вернуться из вызывающая функция.

@marwan-at-work, разве try(err, "someFunc failed") не должно быть try(&err, "someFunc failed") в вашем примере?

@dpinela спасибо за исправление, обновил код :)

Обычная практика, которую мы здесь пытаемся переопределить, - это то, что стандартная раскрутка стека во многих языках предлагает в виде исключения (поэтому было выбрано слово «попытаться»...).
Но если бы мы могли разрешить только функцию (...try() или другую), которая перескакивала бы на два уровня назад в трассировке, тогда

try := handler(err error) {     //which corelates with - try := func(err error) 
   if err !=nil{
       //do what ever you want to do when there's an error... log/print etc
       return2   //2 levels
   }
} 

а потом такой код
f := try(os.Open(имя файла))
может делать именно так, как советует предложение, но как функция (или фактически «функция обработчика») разработчик будет иметь гораздо больший контроль над тем, что делает функция, как она форматирует ошибку в разных случаях, используйте аналогичный обработчик повсюду код для обработки (допустим) os.Open вместо того, чтобы каждый раз писать fmt.Errorf("ошибка открытия файла %s....").
Это также приведет к обработке ошибок, как если бы «попытка» не была определена - это ошибка времени компиляции.

@guybrand Такой двухуровневый возврат return2 (или «нелокальный возврат», как общая концепция называется в Smalltalk) был бы хорошим универсальным механизмом (также предложенным @mikeschinkel в #32473) . Но похоже, что try по-прежнему нужен в вашем предложении, поэтому я не вижу причин для return2 — try может просто сделать return . Было бы интереснее, если бы можно было написать try локально, но это невозможно для произвольных подписей.

@griesemer

_"поэтому я не вижу причин для return2 - try может просто сделать return ."_

Одна из причин — как я указал в #32473 _(спасибо за ссылку)_ — состоит в том, чтобы разрешить несколько уровней break и continue в дополнение к return .

Еще раз спасибо всем за все новые комментарии; это значительные затраты времени, чтобы не отставать от обсуждения и писать подробные отзывы. И даже лучше, несмотря на порой страстные споры, до сих пор это была довольно цивилизованная тема. Спасибо!

Вот еще одно краткое изложение, на этот раз немного более сжатое; приношу свои извинения тем, кого я не упомянул, забыл или исказил. На данный момент я думаю, что появляются некоторые более крупные темы:

1) В общем, использование встроенной функции try считается плохим выбором: учитывая, что это влияет на поток управления, оно должно быть _по крайней мере_ ключевым словом ( @carloslenz "предпочитает делать это оператором без скобка"); try как выражение кажется не очень хорошей идеей, это вредит читабельности ( @ChrisHines , @jimmyfrasche), они "возвращаются без return ". @brynbellomy провел фактический анализ try , используемых в качестве идентификаторов; кажется, что их очень мало в процентном отношении, поэтому можно было бы пойти по маршруту ключевого слова, не затрагивая слишком много кода.

2) @crawshaw потратил некоторое время на анализ пары сотен вариантов использования из библиотеки std и пришел к выводу, что try в предложенном виде почти всегда улучшает читабельность. @jimmyfrasche пришел к противоположному выводу.

3) Еще одна тема заключается в том, что использование defer для оформления ошибок не является идеальным. @josharian указывает, что defer всегда запускаются при возврате функции, но если они здесь для оформления ошибки, мы заботимся об их теле только в случае ошибки, что может быть источником путаницы.

4) Многие написали предложения по улучшению предложения. @zeebo , @patrick-nyt поддерживают форматирование gofmt простых операторов if в одну строку (и довольны статус-кво). @jargv предположил, что try() (без аргументов) может возвращать указатель на текущую «ожидающую» ошибку, что устранит необходимость называть результат ошибки только для того, чтобы иметь доступ к нему в defer ; @masterada предложил вместо этого использовать errorfunc() . @velovix возродил идею try с двумя аргументами, где второй аргумент был бы обработчиком ошибок.

@klaidliadon , @networkimprov выступают за специальные «операторы присваивания», такие как f, # := os.Open() вместо try . @networkimprov подал более подробное альтернативное предложение по изучению таких подходов (см. проблему № 32500). @mikeschinkel также подал альтернативное предложение, предлагая ввести две новые языковые функции общего назначения, которые также можно было бы использовать для обработки ошибок, а не для конкретных ошибок try (см. проблему № 32473). @josharian возродил возможность, которую мы обсуждали на GopherCon в прошлом году, когда try не возвращается при ошибке, а вместо этого переходит (с goto ) к метке с именем error (альтернативно , try может принимать имя целевой метки).

5) По поводу ключевого слова try появилось два направления мыслей. @brynbellomy предложил версию, в которой можно указать обработчик:

a, b := try f()
a, b := try f() else err { /* handle error */ }

@thepudds идет еще дальше и предлагает try в начале строки, давая try ту же видимость, что и return :

try a, b := f()

Оба они могут работать с defer .

@griesemer

Спасибо за ссылку на @mikeschinkel #32473, у нее много общего.

касательно

Но, похоже, в вашем предложении все еще нужна попытка
Хотя мое предложение может быть реализовано с "любым" обработчиком, а не с зарезервированным "встроенным/ключевым словом/выражением", я не думаю, что "try()" - плохая идея (и поэтому не проголосовал за нее), я пытаюсь «расширить его» - чтобы показать больше преимуществ, как многие ожидали, «после выхода go 2.0»

Я думаю, что это также может быть источником «смешанных флюидов», о которых вы сообщили в своем последнем резюме — это не «try () не улучшает обработку ошибок» — конечно, это так, это «ожидание, пока Go 3.0 решит какую-то другую серьезную ошибку». справляться с болями" люди, указанные выше, выглядят слишком долго :)

Я провожу опрос о «болезнях обработки ошибок» (и озвучиваю, что некоторые из них просто «я не использую передовые методы», тогда как некоторые я даже не представлял себе, что люди (в основном из других языков) захотят сделать - от круто к ВТФ).

Надеюсь, скоро смогу поделиться интересными результатами.

наконец-Спасибо за потрясающую работу и терпение!

Глядя просто на длину текущего предлагаемого синтаксиса по сравнению с тем, что доступно сейчас, случай, когда ошибку нужно просто вернуть, не обрабатывая ее или не декорируя, - это тот случай, когда достигается наибольшее удобство. Пример с моим любимым синтаксисом:

try a, b := f() else err { return fmt.Errorf("Decorated: %s", err); }
if a,b, err :=f;  err != nil { return fmt.Errorf("Decorated: %s", err); }
try a, b := f()
if a,b, err :=f;  err != nil { return err; }

Итак, в отличие от того, что я думал раньше, может быть, достаточно просто изменить go fmt, по крайней мере, для случая оформленной/обработанной ошибки. В то время как для случая ошибки, что-то вроде try все еще может быть желательным в качестве синтаксического сахара для этого очень распространенного случая использования.

Что касается try else , я думаю, что условные функции ошибок, такие как fmt.HandleErrorf (редактировать: я предполагаю, что он возвращает ноль, когда ввод равен нулю) в начальном комментарии работают нормально, поэтому добавление else не нужно.

a, b, err := doSomething()
try fmt.HandleErrorf(&err, "Decorated "...)

Как и многие другие здесь, я предпочитаю, чтобы try было оператором, а не выражением, главным образом потому, что выражение, изменяющее поток управления, совершенно чуждо Go. Также, поскольку это не выражение, оно должно быть в начале строки.

Я также согласен с @daved в том, что имя не подходит. В конце концов, здесь мы пытаемся добиться защищенного присваивания, так почему бы не использовать guard , как в Swift, и сделать предложение else необязательным? Что-то типа

GuardStmt = "guard" ( Assignment | ShortVarDecl | Expression ) [  "else" Identifier Block ] .

где Identifier — это имя переменной ошибки, привязанное к следующему Block . Без предложения else просто вернитесь из текущей функции (и используйте обработчик отсрочки для оформления ошибок, если это необходимо).

Сначала мне не нравилось предложение else , потому что это просто синтаксический сахар вокруг обычного присваивания, за которым следует if err != nil , но после просмотра некоторых примеров это просто имеет смысл: использование guard делает намерение более ясным.

РЕДАКТИРОВАТЬ: некоторые предлагали использовать такие вещи, как catch , чтобы как-то указать разные обработчики ошибок. Я нахожу else одинаково жизнеспособным с точки зрения семантики, и это уже есть в языке.

Хотя мне нравится оператор try-else, как насчет такого синтаксиса?

a, b, (err) := func() else { return err }

Выражение try - else является тернарным оператором.

a, b := try f() else err { ... }
fmt.Println(try g() else err { ... })`

Оператор try - else является оператором if .

try a, b := f() else err { ... }
// (modulo scope of err) same as
a, b, err := f()
if err != nil { ... }

Встроенная try с дополнительным обработчиком может быть достигнута либо с помощью вспомогательной функции (ниже), либо без использования try (не показано, мы все знаем, как это выглядит).

a, b := try(f(), decorate)
// same as
a, b := try(g())
// where g is
func g() (whatever, error) {
  x, err := f()
  if err != nil {
    try(decorate(err))
  }
  return x, nil
}

Все три сокращены по шаблону и помогают ограничить объем ошибок.

Это дает наибольшую экономию для встроенной try , но имеет проблемы, упомянутые в документации по дизайну.

Для оператора try - else это дает преимущество по сравнению с использованием if вместо try . Но преимущество настолько незначительно, что мне трудно представить, что оно себя оправдывает, хотя мне оно нравится.

Все три предполагают, что обычно требуется специальная обработка ошибок для отдельных ошибок.

Обработка всех ошибок одинаково может быть выполнена в defer . Если одна и та же обработка ошибок выполняется в каждом блоке else , это немного повторяется:

func printSum(a, b string) error {
  try x := strconv.Atoi(a) else err {
    return fmt.Errorf("printSum: %w", err)
  }
  try y := strconv.Atoi(b) else err {
    return fmt.Errorf("printSum: %w", err)
  }
  fmt.Println("result:", x + y)
  return nil
}

Я, конечно, знаю, что бывают случаи, когда определенная ошибка требует специальной обработки. Это те случаи, которые врезались в мою память. Но если это происходит только, скажем, в 1 из 100 раз, не лучше ли было бы сохранить простоту try и просто не использовать try в таких ситуациях? С другой стороны, если это больше похоже на 1 из 10 случаев, добавление else /handler кажется более разумным.

Было бы интересно увидеть фактическое распределение того, как часто try без обработчика else /handler против try с else /обработчиком было бы полезно, хотя собрать данные непросто.

Я хочу расширить недавний комментарий @jimmyfrasche .

Цель этого предложения состоит в том, чтобы уменьшить шаблон

    a, b, err := f()
    if err != nil {
        return nil, err
    }

Этот код легко читается. Расширение языка имеет смысл только в том случае, если мы сможем добиться значительного сокращения шаблонного кода. Когда я вижу что-то вроде

    try a, b := f() else err { return nil, err }

Я не могу не чувствовать, что мы не так уж много экономим. Мы экономим три строки, и это хорошо, но, по моим подсчетам, мы сокращаем с 56 до 46 символов. Это немного. Сравнить с

    a, b := try(f())

который сокращает с 56 до 18 символов, что является гораздо более значительным сокращением. И хотя оператор try делает потенциальное изменение потока управления более ясным, в целом я не нахожу его более читабельным. Хотя с положительной стороны оператор try упрощает аннотирование ошибки.

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

Как и другие, я хотел бы поблагодарить @crawshaw за примеры.

Читая эти примеры, я призываю людей попытаться принять образ мышления, при котором вы не беспокоитесь о потоке управления из-за функции try . Я полагаю, возможно, ошибочно, что этот поток контроля быстро станет второй натурой людей, которые знают язык. Я считаю, что в обычном случае люди просто перестанут беспокоиться о том, что происходит в случае ошибки. Попробуйте прочитать эти примеры, просматривая try точно так же, как вы уже просматриваете if err != nil { return err } .

После прочтения всего здесь и после дальнейших размышлений я не уверен, что вижу try даже как утверждение, что-то, что стоит добавить.

1. обоснование этого, по-видимому, заключается в уменьшении кода шаблона обработки ошибок. ИМХО, это «расхламляет» код, но на самом деле не устраняет сложность; это просто скрывает это. Это не кажется достаточно сильной причиной. "идти" синтаксис прекрасно зафиксировал запуск параллельного потока. Я не чувствую здесь такого рода "ага!". Это кажется неправильным. Соотношение затрат и выгод недостаточно велико.

2. его название не отражает его функции. В своей простейшей форме она делает следующее: "если функция возвращает ошибку, возвращайтесь из вызывающей программы с ошибкой", но это слишком долго :-) По крайней мере, нужно другое имя.

3. с неявным возвратом при ошибке try кажется, что Go неохотно поддерживает обработку исключений. То есть, если A вызывает be в попытке защиты, а B вызывает C в попытке защиты, а C вызывает D в попытке защиты, если D возвращает ошибку, в результате вы вызвали нелокальный переход. Это кажется слишком «волшебным».

4. и все же я верю, что возможен лучший путь. Если вы выберете «Попробовать сейчас», эта опция будет отключена.

@ianlancetaylor
Если я правильно понимаю предложение «попробовать еще», кажется, что блок else является необязательным и зарезервирован для обработки, предоставляемой пользователем. В вашем примере try a, b := f() else err { return nil, err } предложение else на самом деле избыточно, и все выражение можно записать просто как try a, b := f()

Я согласен с @ianlancetaylor ,
Удобочитаемость и шаблонность — две основные проблемы и, возможно, движущая сила
обработка ошибок go 2.0 (хотя я могу добавить некоторые другие важные проблемы)

Также, что текущий

a, b, err := f()
if err != nil {
    return nil, err
}

Легко читается.
И так как я верю

if a, b, err := f(); err != nil {
    return nil, err
}

Почти так же удобочитаем, но имеет свои "проблемы", возможно,

ifErr a, b, err := f() {
    return nil, err
}

Это было бы только ; err != nil часть и не создаст область, или

по аналогии

попробовать a, b, ошибиться := f() {
вернуть ноль, ошибиться
}

Сохраняет две дополнительные строки, но по-прежнему читаем.

Вт, 11 июня 2019, 20:19 Дмитрий Матреничев, уведомления@github.com
написал:

@ianlancetaylor https://github.com/ianlancetaylor
Если я правильно понимаю предложение "попробовать еще", кажется, что еще блок
является необязательным и зарезервирован для обработки пользователем. В вашем примере
try a, b := f() else err { return nil, err } на самом деле предложение else
избыточно, и все выражение можно записать просто как try a, b :=
е()

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/golang/go/issues/32437?email_source=notifications&email_token=ABNEY4XPURMASWKZKOBPBVDPZ7NALA5CNFSM4HTGCZ72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXN3VDA#issuecomment3 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/ABNEY4SAFK4M5NLABF3NZO3PZ7NALANCNFSM4HTGCZ7Q
.

@ianlancetaylor

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

Согласен, и, учитывая, что else будет всего лишь синтаксическим сахаром (со странным синтаксисом!), который, скорее всего, будет использоваться очень редко, меня это не волнует. Я бы все же предпочел, чтобы try было выражением.

@ianlancetaylor Вторя @DmitriyMV , блок else будет необязательным. Позвольте мне привести пример, который иллюстрирует и то, и другое (и не кажется слишком далеким от истины с точки зрения относительной доли обработанных и необработанных блоков try в реальном коде):

func createMergeCommit(r *repo.Repo, index *git.Index, remote *git.Remote, remoteBranch *git.Branch) error {
    headRef, err := r.Head()
    if err != nil {
        return err
    }

    parentObjOne, err := headRef.Peel(git.ObjectCommit)
    if err != nil {
        return err
    }

    parentObjTwo, err := remoteBranch.Reference.Peel(git.ObjectCommit)
    if err != nil {
        return err
    }

    parentCommitOne, err := parentObjOne.AsCommit()
    if err != nil {
        return err
    }

    parentCommitTwo, err := parentObjTwo.AsCommit()
    if err != nil {
        return err
    }

    treeOid, err := index.WriteTree()
    if err != nil {
        return err
    }

    tree, err := r.LookupTree(treeOid)
    if err != nil {
        return err
    }

    remoteBranchName, err := remoteBranch.Name()
    if err != nil {
        return err
    }

    userName, userEmail, err := r.UserIdentityFromConfig()
    if err != nil {
        userName = ""
        userEmail = ""
    }

    var (
        now       = time.Now()
        author    = &git.Signature{Name: userName, Email: userEmail, When: now}
        committer = &git.Signature{Name: userName, Email: userEmail, When: now}
        message   = fmt.Sprintf(`Merge branch '%v' of %v`, remoteBranchName, remote.Url())
        parents   = []*git.Commit{
            parentCommitOne,
            parentCommitTwo,
        }
    )

    _, err = r.CreateCommit(headRef.Name(), author, committer, message, tree, parents...)
    if err != nil {
        return err
    }
    return nil
}

func createMergeCommit(r *repo.Repo, index *git.Index, remote *git.Remote, remoteBranch *git.Branch) error {
    try headRef := r.Head()
    try parentObjOne := headRef.Peel(git.ObjectCommit)
    try parentObjTwo := remoteBranch.Reference.Peel(git.ObjectCommit)
    try parentCommitOne := parentObjOne.AsCommit()
    try parentCommitTwo := parentObjTwo.AsCommit()
    try treeOid := index.WriteTree()
    try tree := r.LookupTree(treeOid)
    try remoteBranchName := remoteBranch.Name()
    try userName, userEmail := r.UserIdentityFromConfig() else err {
        userName = ""
        userEmail = ""
    }

    var (
        now       = time.Now()
        author    = &git.Signature{Name: userName, Email: userEmail, When: now}
        committer = &git.Signature{Name: userName, Email: userEmail, When: now}
        message   = fmt.Sprintf(`Merge branch '%v' of %v`, remoteBranchName, remote.Url())
        parents   = []*git.Commit{
            parentCommitOne,
            parentCommitTwo,
        }
    )

    try r.CreateCommit(headRef.Name(), author, committer, message, tree, parents...)
    return nil
}

Хотя шаблон try / else не сохраняет много символов по сравнению с составным if , он делает:

• унифицировать синтаксис обработки ошибок с необработанным try
• с первого взгляда понятно, что условный блок обрабатывает состояние ошибки
• дайте нам шанс уменьшить странность области видимости, от которой страдают составные if s

Тем не менее, необработанные try , вероятно, будут наиболее распространенными.

@ianlancetaylor

Попробуйте прочитать эти примеры, пока смотрите на try, точно так же, как вы уже смотрите на if err != nil { return err }.

Я не думаю, что это возможно/равноценно. Не заметить, что попытка существует в переполненной строке, или что она точно обертывает, или что в одной строке есть несколько экземпляров... Это не то же самое, что легко/быстро отметить точку возврата и не беспокоиться о ее специфике.

@ianlancetaylor

Когда я вижу знак «Стоп», я больше узнаю его по форме и цвету, чем по написанному на нем слову и размышляю о его более глубоком значении.

Мои глаза могут затуманиться на if err != nil { return err } , но в то же время это все равно зафиксируется — четко и мгновенно.

Что мне нравится в варианте try -statement, так это то, что он уменьшает шаблон, но таким образом, что его легко замаскировать, но трудно не заметить.

Это может означать дополнительную строку здесь или там, но это все равно меньше строк, чем статус-кво.

@brynbellomy

1. Как вы предлагаете обрабатывать функции, которые возвращают несколько значений, например:
   func createMergeCommit(r *repo.Repo, index *git.Index, remote *git.Remote, remoteBranch *git.Branch) (хэш, ошибка) {
2. Как бы вы отследили правильную строку, которая вернула ошибку
3. отбрасывая проблему области действия (которая может быть решена другими способами), я не уверен

func createMergeCommit(r *repo.Repo, index *git.Index, remote *git.Remote, remoteBranch *git.Branch) error {

    if headRef, err := r.Head(); err != nil {
        return err
    } else if parentObjOne, err := headRef.Peel(git.ObjectCommit); err != nil {
        return err
    } else parentObjTwo, err := remoteBranch.Reference.Peel(git.ObjectCommit); err != nil {
        return err
    } ...

не так сильно отличается читабельностью (или fmt.Errorf("ошибка при получении заголовка: %s", err.Error() ) позволяет вам легко изменять и предоставлять дополнительные данные.

Что еще ворчит, так это

1. необходимость перепроверки; ошибка != ноль
2. возвращая ошибку как есть, если мы не хотим предоставлять дополнительную информацию, что в некоторых случаях не является хорошей практикой, потому что вы зависите от вызываемой вами функции, чтобы отразить «хорошую» ошибку, которая будет намекать на «что пошло не так». ", в случаях функций file.Open , close , Remove , Db и т. д. многие вызовы функций могут возвращать одну и ту же ошибку (мы можем спорить, означает ли это, что разработчик, написавший ошибку, хорошо поработал или нет... но это СЛУЧАЕТСЯ) - и тогда - у вас есть ошибка, вероятно, зарегистрируйте ее из функции, которая вызвала
   « createMergeCommit », но не могу отследить его до точной строки, в которой он произошел.

Извините, если кто-то уже опубликовал что-то подобное (есть много хороших идей: P). Как насчет этого альтернативного синтаксиса:

fail := func(err error) error {
  log.Print("unexpected error", err)
  return err
}

a, b, err := f1()          // normal
c, d := f2() -> throw      // calls throw(err)
e, f := f3() -> panic      // calls panic(err)
g, h := f4() -> t.Error    // calls t.Error(err)
i, j := f5() -> fail       // calls fail(err)

то есть у вас есть -> handler справа от вызова функции, которая вызывается, если возвращенная ошибка != nil. Обработчик — это любая функция, которая принимает ошибку как единственный аргумент и необязательно возвращает ошибку (например, func(error) или func(error) error ). Если обработчик возвращает нулевую ошибку, функция продолжается, в противном случае возвращается ошибка.

поэтому a := b() -> handler эквивалентно:

a, err := b()
if err != nil {
  if herr := handler(err); herr != nil {
    return herr
  }
}

Теперь в качестве ярлыка вы можете поддерживать встроенную функцию try (или ключевое слово, или оператор ?= , или что-то еще), что является сокращением от a := b() -> throw , поэтому вы можете написать что-то вроде:

func() error {
  a, b := try(f1())
  c, d := try(f2())
  e, f := try(f3())
  ...
  return nil
}() -> panic // or throw/fail/whatever

Лично я считаю, что оператор ?= легче читать, чем ключевое/встроенное слово try:

func() error {
  a, b ?= f1()
  c, d ?= f2()
  e, f ?= f3()
  ...
  return nil
}() -> panic

примечание : здесь я использую throw в качестве заполнителя для встроенной функции, которая возвращает ошибку вызывающей стороне.

Я пока не комментировал предложения по обработке ошибок, потому что в целом поддерживаю их, и мне нравится, как они продвигаются. И функция try, определенная в предложении, и оператор try, предложенный @thepudds , кажутся разумными дополнениями к языку. Я уверен, что все, что придумает команда Go, будет хорошим.

Я хочу поднять то, что я считаю незначительной проблемой, связанной с определением попытки в предложении и с тем, как это может повлиять на будущие расширения.

Try определяется как функция, принимающая переменное количество аргументов.

func try(t1 T1, t2 T2, … tn Tn, te error) (T1, T2, … Tn)

Передача результата вызова функции в try , как в try(f()) , работает неявно из-за того, как в Go работает несколько возвращаемых значений.

Судя по моему прочтению предложения, следующие фрагменты действительны и семантически эквивалентны.

a, b = try(f())
//
u, v, err := f()
a, b = try(u, v, err)

Предложение также повышает возможность расширения try дополнительными аргументами.

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

Предположим, мы хотим добавить аргумент обработчика. Он может идти либо в начале, либо в конце списка аргументов.

var h handler
a, b = try(h, f())
// or
a, b = try(f(), h)

Размещение его в начале не работает, потому что (учитывая приведенную выше семантику) try не сможет отличить явный аргумент обработчика от функции, возвращающей обработчик.

func f() (handler, error) { ... }
func g() (error) { ... }
try(f())
try(h, g())

Размещение его в конце, вероятно, сработает, но тогда попытка будет уникальной в языке, поскольку это единственная функция с параметром varargs в начале списка аргументов.

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

@волшебный

Наличие обработчика, возможно, мощно:
Я тебя уже объявил ч,

ты сможешь

var h handler
a, b, h = f()

или

a, b, h.err = f()

если это похоже на функцию:

h:= handler(err error){
 log(...)
 return ....
} 

Потом было предложение

a, b, h(err) = f()

Все могут вызывать обработчик
И вы также можете «выбрать» обработчик, который возвращает или только фиксирует ошибку (conitnue/break/return), как некоторые предлагали.

Таким образом, проблема вараргов исчезла.

Одна альтернатива предложению else @brynbellomy:

a, b := try f() else err { /* handle error */ }

может быть поддержка функции украшения сразу после else:

decorate := func(err error) error { return fmt.Errorf("foo failed: %v", err) }

try a, b := f() else decorate
try c, d := g() else decorate

И, возможно, также некоторые служебные функции что-то вроде:

decorate := fmt.DecorateErrorf("foo failed")

Функция оформления может иметь сигнатуру func(error) error и вызываться функцией try при наличии ошибки непосредственно перед возвратом функции try из связанной пробуемой функции.

По духу это будет похоже на одну из более ранних «итераций дизайна» из документа с предложением:

f := try(os.Open(filename), handler)              // handler will be called in error case

Если кому-то нужно что-то более сложное или блок операторов, он может вместо этого использовать if (так же, как и сегодня).

Тем не менее, есть что-то приятное в визуальном выравнивании try , показанном в примере @brynbellomy в https://github.com/golang/go/issues/32437#issuecomment -500949780.

Все это может по-прежнему работать с defer , если этот подход будет выбран для униформного оформления ошибок (или даже теоретически может быть альтернативная форма регистрации функции оформления, но это отдельный вопрос).

В любом случае, я не уверен, что здесь лучше, но хотел сделать еще один вариант явным.

Вот пример @brynbellomy , переписанный с помощью функции try , с использованием блока var , чтобы сохранить хорошее выравнивание, указанное @thepudds в https://github.com/golang/go/issues .

package main

import (
    "fmt"
    "time"
)

func createMergeCommit(r *repo.Repo, index *git.Index, remote *git.Remote, remoteBranch *git.Branch) error {
    var (
        headRef          = try(r.Head())
        parentObjOne     = try(headRef.Peel(git.ObjectCommit))
        parentObjTwo     = try(remoteBranch.Reference.Peel(git.ObjectCommit))
        parentCommitOne  = try(parentObjOne.AsCommit())
        parentCommitTwo  = try(parentObjTwo.AsCommit())
        treeOid          = try(index.WriteTree())
        tree             = try(r.LookupTree(treeOid))
        remoteBranchName = try(remoteBranch.Name())
    )

    userName, userEmail, err := r.UserIdentityFromConfig()
    if err != nil {
        userName = ""
        userEmail = ""
    }

    var (
        now       = time.Now()
        author    = &git.Signature{Name: userName, Email: userEmail, When: now}
        committer = &git.Signature{Name: userName, Email: userEmail, When: now}
        message   = fmt.Sprintf(`Merge branch '%v' of %v`, remoteBranchName, remote.Url())
        parents   = []*git.Commit{
            parentCommitOne,
            parentCommitTwo,
        }
    )

    _, err = r.CreateCommit(headRef.Name(), author, committer, message, tree, parents...)
    return err
}

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

Однако это поднимает вопрос о том, как try работает в блоке var . Я предполагаю, что каждая строка var считается отдельным оператором, а не целым блоком, являющимся одним оператором, насколько порядок того, что присваивается, когда.

Было бы хорошо, если бы предложение «попробовать» явно указывало на последствия для таких инструментов, как cmd/cover, которые аппроксимируют статистику покрытия тестами, используя наивный подсчет операторов. Я беспокоюсь, что невидимый поток контроля ошибок может привести к занижению счета.

@пуддс

попробуйте a, b := f() иначе украсьте

Возможно, это слишком глубокий ожог клеток моего мозга, но это слишком сильно бьет по мне.

try a, b := f() ;catch(decorate)

и скользкий путь к

a, b := f()
catch(decorate)

Я думаю, вы можете видеть, к чему это ведет, и для меня сравнение

    try headRef := r.Head()
    try parentObjOne := headRef.Peel(git.ObjectCommit)
    try parentObjTwo := remoteBranch.Reference.Peel(git.ObjectCommit)
    try parentCommitOne := parentObjOne.AsCommit()
    try parentCommitTwo := parentObjTwo.AsCommit()
    try treeOid := index.WriteTree()
    try tree := r.LookupTree(treeOid)
    try remoteBranchName := remoteBranch.Name()

с участием

    try ( 
    headRef := r.Head()
    parentObjOne := headRef.Peel(git.ObjectCommit)
    parentObjTwo := remoteBranch.Reference.Peel(git.ObjectCommit)
    parentCommitOne := parentObjOne.AsCommit()
    parentCommitTwo := parentObjTwo.AsCommit()
    treeOid := index.WriteTree()
    tree := r.LookupTree(treeOid)
    remoteBranchName := remoteBranch.Name()
    )

(или даже подвох в конце)
Второй более читабелен, но подчеркивает тот факт, что функции ниже возвращают 2 vars, и мы волшебным образом отбрасываем одну, собирая ее в "magic return err" .

    try(err) ( 
    headRef := r.Head()
    parentObjOne := headRef.Peel(git.ObjectCommit)
    parentObjTwo := remoteBranch.Reference.Peel(git.ObjectCommit)
    parentCommitOne := parentObjOne.AsCommit()
    parentCommitTwo := parentObjTwo.AsCommit()
    treeOid := index.WriteTree()
    tree := r.LookupTree(treeOid)
    remoteBranchName := remoteBranch.Name()
    ); err!=nil {
      //handle the err
    }

по крайней мере, явно задает возвращаемую переменную и позволяет мне обрабатывать ее внутри функции, когда захочу.

Просто добавляю конкретный комментарий, поскольку я не видел, чтобы кто-то еще явно упоминал об этом, в частности, об изменении gofmt для поддержки следующего однострочного форматирования или любого другого варианта:

if f() { return nil, err }

Пожалуйста, нет. Если нам нужна одна строка if , сделайте одну строку if , например:

if f() then return nil, err

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

Я хотел бы подчеркнуть пару вещей, которые, возможно, были забыты в пылу дискуссии:

1) Весь смысл этого предложения состоит в том, чтобы сделать обычную обработку ошибок отодвинутой на второй план — обработка ошибок не должна доминировать в коде. Но все же должно быть явным. Любое из альтернативных предложений, которые делают обработку ошибок еще более выпирающей, упускает суть. Как уже сказал @ianlancetaylor , если эти альтернативные предложения не уменьшат значительно количество шаблонов, мы можем просто остаться с операторами if . (И запрос на сокращение шаблонного кода исходит от вас, сообщества Go.)

2) Одна из претензий к текущему предложению — необходимость назвать результат ошибки, чтобы получить к нему доступ. Любое альтернативное предложение будет иметь ту же проблему, если альтернатива не вводит дополнительный синтаксис, т. е. больше шаблонов (таких как ... else err { ... } и т.п.) для явного наименования этой переменной. Но что интересно: если мы не заботимся об оформлении ошибки и не называем результирующие параметры, но по-прежнему требуем явного return , потому что есть своего рода явный обработчик, этот оператор return должен будет перечислить все (обычно нулевые) значения результата, поскольку в этом случае не допускается голый возврат. Особенно, если функция возвращает много ошибок без оформления ошибки, эти явные возвраты ( return nil, err и т. д.) добавляются к шаблону. Текущее предложение и любая альтернатива, не требующая явного указания return , отменяет это. С другой стороны, если кто-то действительно хочет приукрасить ошибку, текущее предложение _требует_ того, чтобы имя результата ошибки (а вместе с ним и все остальные результаты) получило доступ к значению ошибки. У этого есть приятный побочный эффект, заключающийся в том, что в явном обработчике можно использовать голый возврат и не нужно повторять все остальные значения результата. (Я знаю, что есть некоторые сильные чувства по поводу голых возвратов, но реальность такова, что, когда все, о чем мы заботимся, - это результат ошибки, это настоящая неприятность, чтобы перечислить все остальные (обычно нулевые) значения результата - это ничего не добавляет к понимание кода). Другими словами, необходимость называть результат ошибки так, чтобы его можно было декорировать, позволяет еще больше сократить шаблон.

@magical Спасибо, что указали на это . Я заметил то же самое вскоре после публикации предложения (но не поднял его, чтобы не вызывать путаницы). Вы правы, что try не может быть расширен. К счастью, исправить это достаточно просто. (Как оказалось, в наших более ранних внутренних предложениях не было этой проблемы — она появилась, когда я переписал нашу окончательную версию для публикации и попытался упростить try , чтобы более точно соответствовать существующим правилам передачи параметров. - но, как оказалось, ущербно и в основном бесполезно - благо можно написать try(a, b, c, handle) .)

Более ранняя версия try определяла его примерно следующим образом: try(expr, handler) принимает одно (или, возможно, два) выражения в качестве аргументов, где первое выражение может быть многозначным (может случиться, только если выражение вызов функции). Последнее значение этого (возможно, многозначного) выражения должно иметь тип error , и это значение проверяется на нулевое значение. (и т.д. - остальное вы можете себе представить).

В любом случае, дело в том, что try синтаксически принимает только одно или, возможно, два выражения. (Но немного сложнее описать семантику try .) Следствием будет такой код, как:

a, b := try(u, v, err)

больше бы не разрешили. Но нет особых причин для того, чтобы заставить это работать: в большинстве случаев (если только a и b не являются именованными результатами) этот код — если он по какой-то причине важен — может быть легко переписан в

a, b := u, v  // we don't care if the assignment happens in case of an error
try(err)

(или используйте оператор if по мере необходимости). Но опять же, это кажется неважным.

этот оператор возврата должен будет перечислить все (обычно нулевые) результирующие значения, поскольку в этом случае голый возврат не разрешен.

Голый возврат не разрешен, но попробовать можно. Одна вещь, которая мне нравится в try (либо как функция, либо как оператор), заключается в том, что мне больше не нужно думать, как установить безошибочные значения при возврате ошибки, я просто буду использовать try.

@griesemer Спасибо за объяснение. Вот к такому выводу я тоже пришел.

Краткий комментарий к try как к утверждению: как я думаю, можно увидеть в примере в https://github.com/golang/go/issues/32437#issuecomment -501035322, try хоронит лед. Код становится серией операторов try , что скрывает то, что на самом деле делает код.

Существующий код может повторно использовать вновь объявленную переменную ошибки после блока if err != nil . Скрытие переменной нарушит это, и добавление именованной возвращаемой переменной в сигнатуру функции не всегда исправит это.

Может быть, лучше оставить объявление/назначение ошибок как есть и найти однострочный код обработки ошибок stmt.

err := f() // followed by one of

on err, return err            // any type can be tested for non-zero
on err, return fmt.Errorf(...)
on err, fmt.Println(err)      // doesn't stop the function
on err, hname err             // handler invocation without parens
on err, ignore err            // optional ignore handler logs error if defined

if err, return err            // alternatively, use if

handle hname(err error, clr caller) { // type caller has results of runtime.Caller()
   if err == io.Bad { return err }
   fmt.Println(clr.name, err)
}

Подвыражение try может вызвать панику, что означает, что ошибки никогда не ожидается. Вариант этого может игнорировать любую ошибку.

f(try g()) // panic on error
f(try_ g()) // ignore any error

Весь смысл этого предложения состоит в том, чтобы отодвинуть обычную обработку ошибок на задний план — обработка ошибок не должна доминировать в коде. Но все же должно быть явным.

Мне нравится идея комментариев, в которых try как утверждение. Это явно, все еще легко замазать (поскольку он имеет фиксированную длину), но не настолько легко замазать (поскольку он всегда в одном и том же месте), чтобы их можно было спрятать в переполненной строке. Его также можно комбинировать с defer fmt.HandleErrorf(...) , как отмечалось ранее, однако у него есть ловушка злоупотребления именованными параметрами для переноса ошибок (что все еще кажется мне умным хаком. умные хаки - это плохо).

Одна из причин, по которой мне не нравилось выражение try , заключается в том, что его либо слишком легко замазать, либо недостаточно просто замазать. Возьмите следующие два примера:

Попробуйте как выражение

// Too hidden, it's in a crowded function with many symbols that complicate the function.

f, err := os.OpenFile(try(FileName()), os.O_APPEND|os.O_WRONLY, 0600)

// Not easy enough, the word "try" already increases horizontal complexity, and it
// being an expression only encourages more horizontal complexity.
// If this code weren't collapsed to multiple lines, it would be extremely
// hard to read and unclear as to what's executing when.

fullContents := try(io.CopyN(
    os.Stdout,
    try(net.Dial("tcp", "localhost:"+try(buf.ReadString("\n"))),
    try(strconv.Atoi(try(buf.ReadString("\n")))),
))

Попробуйте как заявление

// easy to see while still not being too verbose

try name := FileName()
os.OpenFile(name, os.O_APPEND|os.O_WRONLY, 0600)

// does not allow for clever one-liners, code remains much more readable.
// also, the code reads in sequence from top-to-bottom.

try port := r.ReadString("\n")
try lengthStr := r.ReadString("\n")
try length := strconv.Atoi(lengthStr)

try con := net.Dial("tcp", "localhost:"+port)
try io.CopyN(os.Stdout, con, length)

Выводы

Этот код определенно придуман, я признаю. Но я имею в виду, что, как правило, try как выражение плохо работает в:

1. Середина переполненных выражений, которые не нуждаются в большой проверке ошибок
2. Относительно простые многострочные операторы, требующие большого количества проверок ошибок.

Однако я согласен с @ianlancetaylor в том, что начало каждой строки с try , похоже, мешает важной части каждого оператора (определяемой переменной или выполняемой функции). Однако я думаю, что из-за того, что он находится в том же месте и имеет фиксированную ширину, его гораздо легче скрыть, но при этом заметить. Однако глаза у всех разные.

Я также думаю, что поощрение умных однострочников в коде — это вообще плохая идея. Я удивлен, что смог создать такой мощный однострочник, как в моем первом примере, это фрагмент, который заслуживает своей собственной функции, потому что он так много делает, но он умещается в одну строку, если бы я не свернул его. на несколько для удобочитаемости. Все в одной строке:

fullContents := try(io.CopyN(os.Stdout, try(net.Dial("tcp", "localhost:"+try(r.ReadString("\n"))), try(strconv.Atoi(try(r.ReadString("\n"))))))

Он считывает порт из *bufio.Reader , запускает TCP-соединение и копирует количество байтов, указанное тем же *bufio.Reader , в stdout . Все с обработкой ошибок. Я не думаю, что для языка с такими строгими соглашениями о кодировании это вообще должно быть разрешено. Я думаю, что gofmt может помочь с этим.

Я не думаю, что для языка с такими строгими соглашениями о кодировании это вообще должно быть разрешено.

На Go можно написать отвратительный код. Можно даже страшно отформатировать; есть только сильные нормы и инструменты против этого. В Go даже есть goto .

Во время проверки кода я иногда прошу людей разбить сложные выражения на несколько операторов с полезными промежуточными именами. Я бы сделал что-то подобное для глубоко вложенных try s по той же причине.

Все это говорит о том, что давайте не будем слишком сильно пытаться объявить плохой код вне закона ценой искажения языка. У нас есть другие механизмы для поддержания чистоты кода, которые лучше подходят для чего-то, что принципиально предполагает человеческое суждение в каждом конкретном случае.

На Go можно написать отвратительный код. Можно даже страшно отформатировать; есть только сильные нормы и инструменты против этого. Go даже имеет goto.

Во время проверки кода я иногда прошу людей разбить сложные выражения на несколько операторов с полезными промежуточными именами. По той же причине я бы сделал что-то подобное для глубоко вложенных попыток.

Все это говорит о том, что давайте не будем слишком сильно пытаться объявить плохой код вне закона ценой искажения языка. У нас есть другие механизмы для поддержания чистоты кода, которые лучше подходят для чего-то, что принципиально предполагает человеческое суждение в каждом конкретном случае.