나는 이것이 가장 일반적인 문제를 단순한 디자인으로 해결하는 최선의 방법이라는 데 동의합니다.

나는 자전거를 타고 싶지 않지만(이 대화를 연기해도 무방합니다), 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, "x") 또는 (7, "x")? 나는 후자를 가정할 것이다.

내부 도우미 함수와 같이 장식이나 처리가 없는 경우 오류 반환 이름을 지정해야 합니까? 나는 그렇지 않다고 가정한다.

귀하의 예는 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 는 미래의 어떤 지점에서 함수가 반환되기 직전에 오류 값을 _eventually_ 설정하는 것처럼 보였습니다. 아마도 나중 줄에 있을 것입니다. 올바른 해석은 try로 인해 현재 함수가 반환될 수 있다는 것입니다. 이는 현재 언어에 대한 놀라운 동작이므로 더 명확한 텍스트가 환영받을 것입니다.

나는 이것이 단지 설탕이라고 생각하고 소수의 보컬 반대자가 if err != nil ... 를 반복적으로 입력하는 것에 대해 golang을 조롱했고 누군가는 그것을 진지하게 받아들였습니다. 나는 그것이 문제라고 생각하지 않는다. 유일하게 누락된 것은 다음 두 가지 내장 기능입니다.

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

왜 누군가가 이와 같은 기능을 작성하는지 확실하지 않지만 예상되는 출력은 무엇입니까?

try(foobar())

foobar 가 (error, error) $를 반환한 경우

제어 흐름에 대한 이전 우려를 철회하고 더 이상 ? 사용을 제안하지 않습니다. 갑작스러운 답변에 대해 사과드립니다(전체 제안이 제공된 _이후_ 문제가 제출되었다면 이런 일이 발생하지 않았을 것이라는 점을 지적하고 싶습니다).

나는 단순한 오류 처리의 필요성에 동의하지 않지만 그것이 지는 싸움이라고 확신합니다. 제안서에 명시된 try 는 가장 나쁜 방법인 것 같습니다.

@webermaster 마지막 error 결과만 제안 문서에 설명된 대로 try 에 전달된 표현식에 대해 특별합니다.

@dominikh 와 마찬가지로 나도 단순화된 오류 처리의 필요성에 동의하지 않습니다.

수직적 복잡성을 수평적 복잡성으로 옮기는 것은 거의 좋은 생각이 아닙니다.

그러나 오류 처리 제안을 단순화하는 것 사이에서 절대적 으로 선택해야 한다면 이것이 내가 선호하는 제안이 될 것입니다.

이러한 변환이 다음 없이 쉽게 수행될 수 있는 오류 반환 함수의 일부 하위 집합에서 try 를 사용하도록 Go 코드를 변환하는 도구와 함께(일부 승인 단계에서) 도움이 될 수 있습니다. 의미 변경. 세 가지 이점이 있습니다.

• 이 제안을 평가할 때 사람들은 코드베이스에서 try 가 어떻게 사용될 수 있는지 빠르게 이해할 수 있습니다.
• try 가 Go의 미래 버전에 포함된다면 사람들은 코드를 변경하여 이를 사용하기를 원할 것입니다. 쉬운 사례를 자동화하는 도구가 있으면 많은 도움이 될 것입니다.
• try 를 사용하도록 대규모 코드베이스를 빠르게 변환하는 방법을 사용하면 대규모 구현의 효과를 쉽게 조사할 수 있습니다. (정확성, 성능, 코드 크기 등) 하지만 구현은 이를 무시해도 될 정도로 간단할 수 있습니다.

try(foo()) 실제로 호출 함수를 빠져나가는 것은 결과에 따라 함수 흐름이 변경될 수 있다는 시각적 신호를 우리에게서 빼앗아간다고 생각한다는 것을 표현하고 싶습니다.

충분히 익숙해지면 try 로 작업할 수 있다고 생각하지만 코드 리뷰에서 암시적 흐름을 효율적으로 인식하려면 try 를 강조 표시하기 위해 추가 IDE 지원(또는 이와 유사한 것)이 필요하다고 생각합니다. /디버깅 세션

내가 가장 걱정하는 것은 defer 문이 만족하도록 명명된 반환 값을 가질 필요가 있다는 것입니다.

커뮤니티에서 불평하는 전반적인 오류 처리 문제는 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. 과거에 했던 것처럼 값을 할당하되 if err != nil 상용구가 있는 도우미 wrapf 함수를 사용하십시오.

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
}

작동해야 합니다. 하지만 nil 오류가 발생하더라도 wrapf를 호출합니다.
이것은 또한 (계속) 작동하며 IMO가 훨씬 명확합니다.

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

아무도 try 를 사용하게 만들지 않을 것입니다.

왜 누군가가 이와 같은 기능을 작성하는지 확실하지 않지만 예상되는 출력은 무엇입니까?

try(foobar())

foobar 가 (error, error) $를 반환한 경우

함수에서 둘 이상의 오류를 반환하는 이유는 무엇입니까? 함수에서 둘 이상의 오류를 반환하는 경우 함수는 처음에 각각 하나의 오류만 반환하는 두 개의 개별 오류로 분할되어야 합니다.

예를 들어 자세히 설명해 주시겠습니까?

@cespare : 누군가 try 를 사용하도록 try 에 적합한 기존 코드를 다시 작성하는 go fix 를 작성하는 것이 가능해야 합니다. 기존 코드가 어떻게 단순화될 수 있는지 감을 잡는 것이 유용할 수 있습니다. try 는 기본적으로 동일한 출력 코드를 생성하는 더 짧은 소스 코드로 공통 패턴을 대체하는 단순한 구문 설탕이기 때문에 코드 크기나 성능에 큰 변화가 없을 것으로 예상합니다. 또한 try 를 사용하는 코드는 적어도 try 가 도입된 버전인 Go 버전을 사용해야 합니다.

@lesrrat : try 가 제어 흐름을 변경할 수 있다는 것을 배워야 한다는 데 동의했습니다. 우리는 IDE가 그것을 충분히 쉽게 강조할 수 있다고 생각합니다.

@Goodwine : @randall77 이 이미 지적했듯이 첫 번째 제안은 작동하지 않습니다. 우리가 생각한 한 가지 옵션(문서에서는 논의되지 않음)은 error 결과를 나타내는 미리 선언된 변수를 가질 가능성입니다(처음에 존재하는 경우). 그러면 defer 에서 사용할 수 있도록 결과 이름을 지정할 필요가 없습니다. 그러나 그것은 훨씬 더 마술적일 것입니다. 정당화되지 않는 것 같습니다. 반환 결과의 이름을 지정하는 문제는 본질적으로 외관상 문제이며 가장 중요한 부분은 go doc 및 친구들이 제공하는 자동 생성 API입니다. 이러한 도구에서 이 문제를 쉽게 해결할 수 있습니다(이 주제에 대한 자세한 디자인 문서의 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

5년 전 Go에서 AST 전처리기로 try()를 구현하고 실제 프로젝트에서 사용했는데 꽤 좋았습니다. https://github.com/lunixbochs/og

다음은 오류 검사가 많은 기능에서 사용하는 몇 가지 예입니다. https://github.com/lunixbochs/poxd/blob/master/tls.go#L13

나는 이것에 들어간 노력에 감사드립니다. 지금까지 본 솔루션 중 가장 과감한 솔루션이라고 생각합니다. 하지만 디버깅할 때 많은 작업을 도입한다고 생각합니다. 디버깅할 때마다 시도를 풀고 if 블록을 추가하고 완료되면 다시 래핑하는 것은 지루합니다. 또한 고려해야 할 마법의 오류 변수에 대해 약간의 오싹함이 있습니다. 나는 명시적인 오류 검사로 인해 귀찮게 한 적이 없으므로 아마도 내가 물어볼 잘못된 사람일 것입니다. 항상 "디버그할 준비가 되었다"는 느낌을 받았습니다.

@griesemer
오류 래핑을 처리하기 위해 제안한 defer 사용에 대한 내 문제는 내가 보여준 스니펫(아래에서 반복됨)의 동작이 매우 일반적인 AFAICT가 아니며 매우 드물기 때문에 사람들이 이것이 작동한다고 생각하는 것을 작성하는 것을 상상할 수 있다는 것입니다. 그렇지 않을 때.

예를 들어 .. 초보자는 이것을 알지 못합니다. 이 때문에 버그가 있으면 "물론 이름이 지정된 반환이 필요합니다."라고 표시되지 않고 작동해야 하지만 작동하지 않기 때문에 스트레스를 받을 것입니다.

var err error
defer fmt.HandleErrorf(err);

try 는 이미 너무 마술적이므로 끝까지 가서 암시적 오류 값을 추가할 수도 있습니다. 바둑의 모든 뉘앙스를 아는 사람이 아니라 초보자를 생각하십시오. 충분히 명확하지 않으면 올바른 해결책이 아니라고 생각합니다.

또는... 이와 같이 defer를 사용하는 것을 제안하지 말고 더 안전하지만 여전히 읽을 수 있는 다른 방법을 시도하십시오.

@deanveloper 이 제안(그리고 동일한 것을 시도하는 모든 제안)이 소스 코드에서 명시적으로 보이는 return 문을 제거한다는 것은 사실입니다. 이것이 결국 제안의 요점입니다. 그렇지 않아? if 문과 returns 의 상용구를 제거하려면 모두 동일합니다. return try 를 사용하지 마십시오.

우리는 return 문(및 panic )을 즉시 인식하는 데 익숙합니다. Go(및 기타 많은 언어)에서 이러한 종류의 제어 흐름이 표현되는 방식이기 때문입니다. 우리가 $# return 8$#$ 에서 하는 것처럼 일부가 익숙해지면 try 도 제어 흐름을 변경하는 것으로 인식하게 될 것입니다. 좋은 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 이 링크를 주셔서 감사합니다. 나는 그것을 모르고 있었다.

@굿와인포인트 득템 . 더 직접적인 오류 처리 지원을 제공하지 않는 이유는 디자인 문서에서 자세히 설명합니다. (작년 Gophercon에서 디자인 초안이 발표된 이후) 1년 정도 동안 명시적 오류 처리에 대한 만족스러운 솔루션이 나오지 않은 것도 사실입니다. 이것이 이 제안이 의도적으로 이것을 생략하는 이유입니다(대신 defer 사용을 제안함). 이 제안은 여전히 ​​그 점에서 향후 개선을 위한 문을 열어 둡니다.

제안서는 테스트 및 벤치마크가 오류를 반환할 수 있도록 패키지 테스트를 변경하는 것을 언급합니다. "적당한 라이브러리 변경"은 아니지만 func main() error 도 허용하는 것을 고려할 수 있습니다. 작은 스크립트를 훨씬 더 멋지게 작성할 수 있습니다. 의미론은 다음과 같습니다.

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

마지막으로 한 가지 비판. 실제로 제안 자체에 대한 비판이 아니라 "흐름을 제어하는 ​​기능" 반론에 대한 일반적인 응답에 대한 비판입니다.

"기능이 흐름을 제어하는 ​​것이 마음에 들지 않습니다"에 대한 응답은 " panic 도 프로그램의 흐름을 제어합니다!"입니다. 그러나 try 에 적용되지 않는 panic 이 작업을 수행하는 것이 더 괜찮은 몇 가지 이유가 있습니다.

1. panic 는 직관적이고 스택을 계속 풀기 때문에 초보자 프로그래머에게 친숙합니다. panic 가 무엇을 하는지 이해하기 위해 어떻게 작동하는지 찾아볼 필요조차 없습니다. 초보자 프로그래머는 recover 에 대해 걱정할 필요조차 없습니다. 왜냐하면 초보자는 일반적으로 패닉 복구 메커니즘을 구축하지 않기 때문입니다. 특히 처음부터 패닉을 피하는 것보다 거의 항상 유리하지 않기 때문입니다.

2. panic 는 보기 쉬운 이름입니다. 그것은 걱정거리를 가져오고, 그럴 필요가 있습니다. 코드베이스에서 panic 를 본 사람은 사소한 것이라도 패닉을 _피하는_ 방법을 즉시 생각해야 합니다.

3. 마지막 포인트를 피기백하면 panic 는 호출에 중첩될 수 없으므로 보기가 훨씬 쉽습니다.

프로그램의 흐름을 제어하는 ​​패닉은 매우 찾기 쉽고 그것이 하는 일에 대해 직관적이기 때문에 괜찮습니다.

try 함수는 이러한 점 중 어느 것도 충족하지 않습니다.

1. 문서를 찾아보지 않고는 try 가 무엇을 하는지 추측할 수 없습니다. 많은 언어에서 키워드를 다양한 방식으로 사용하므로 Go에서 이 키워드가 의미하는 바를 이해하기 어렵습니다.

2. try 는 특히 함수일 때 눈에 띄지 않습니다. _특히_ 구문 강조 표시가 이를 함수로 강조할 때. _ESPECIALLY_ 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 에 대한 귀하의 특정 제안은 내가 올바르게 이해하는 경우 API와 같은 fmt.Errorf ( 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 및 다른 사람들과 공유합니다. 우리가 그것을 사용하지 않기로 선택할 수 있는 것은 사실이지만 제3자 종속성의 스타일은 우리가 통제할 수 없습니다.
덜 반복적인 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())
오류 != nil {
반환 ..., 오류
}
이렇게 생긴 코드가 엄청나게 많습니다. 그리고 이와 같이 보이는 모든 코드에 더 많은 오류 처리가 필요한 것은 아닙니다. defer가 옳지 않은 경우에도 여전히 if 문을 사용할 수 있습니다.

예, 하지만 좋지 않아야 합니다. 관용적 코드는 항상 오류를 래핑/장식합니까? 이것이 우리가 stdlib에 컨텍스트/랩 오류를 추가하기 위해 세련된 오류 처리 메커니즘을 도입하는 이유라고 생각합니다. 내가 보기에 이 제안은 가장 기본적인 사용 사례만을 고려하는 것 같습니다.

게다가, 이 제안은 지연 호출과 함께 명명된 매개변수를 사용하여 _단일 장소_에서 가능한 여러 오류 반환 사이트를 래핑/장식하는 경우에만 해결합니다.

그러나 단일 함수의 다른 오류에 다른 컨텍스트를 추가해야 하는 경우에는 아무 것도 하지 않습니다. 예를 들어, DB 오류를 장식하여 오류가 발생한 위치에 대한 자세한 정보를 얻는 것이 매우 중요합니다(스택 추적이 없다고 가정)

이것은 내가 가지고 있는 실제 코드의 예입니다.

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처럼 보이는 후속 nil 테스트 없이 할당 구문을 원합니다. 확인/처리에 대한 13개의 개별 응답 이 이를 제안했습니다. 여기에서 _반복 테마_를 참조하세요.
   https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback#recurring -themes

   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 보다 훨씬 더 자주 수행합니다.

   • log.Fatal()
   • 발생하지 말아야 할 오류에 대한 패닉()
   • 메시지를 기록하고 다시 시도

@gopherbot 은 Go2, LanguageChange 추가

? 만 사용하여 rust 처럼 결과를 언래핑하는 것은 어떻습니까?

try() 호출에 대해 회의적인 이유는 두 가지 암시적 바인딩 때문일 수 있습니다. 반환 값 오류에 대한 바인딩과 try()에 대한 인수를 볼 수 없습니다. try()에 대해 반환 값에 오류가 있는 인수 함수와 함께 try()를 사용해야 한다는 규칙을 만들 수 있습니다. 그러나 반환 값에 대한 바인딩은 그렇지 않습니다. 따라서 사용자가 이 코드가 무엇을 하는지 이해하려면 더 많은 표현이 필요하다고 생각합니다.

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

• doSomething의 반환 값에 %error 가 없으면 try()를 사용할 수 없습니다.
• foo()가 반환 값의 마지막에 오류가 없으면 try()를 사용할 수 없습니다.

기존 구문에 새로운 요구 사항/기능을 추가하는 것은 어렵습니다.

솔직히 말해서 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
})  

문서에 나와 있는 것처럼 이는 몇 가지 질문을 제기하지만 이러한 오류 처리기 기능이나 클로저를 선택적으로 지정할 수 있는 가능성을 유지했다면 이 제안이 훨씬 더 바람직하고 유용할 것이라고 생각합니다.

두 번째로, 내장 함수가 반환되도록 할 수 있다는 점은 신경쓰지 않지만, 약간의 바이크세팅을 위해 'try'라는 이름이 반환을 유발할 수 있다고 제안하기에는 너무 짧습니다. 따라서 attempt 와 같이 더 긴 이름이 더 나은 것 같습니다.

편집: 셋째, 이상적으로는 go 언어가 먼저 제네릭을 가져와야 합니다. 여기서 중요한 사용 사례는 이 try 함수를 제네릭으로 구현하는 기능이 될 것이며, 따라서 bikeshedding이 끝날 수 있고 모든 사람이 자신이 선호하는 오류 처리를 얻을 수 있습니다.

Hacker 뉴스에는 몇 가지 요점이 있습니다. 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 를 사용하는 대신) 우리는 이 디자인의 이전 버전에서 질문에 대한 합리적인 답변을 찾을 수 있습니다. 예를 들어 기능 보강이 nil이면 아무 것도 하지 않고 원래 오류를 반환합니다.

try 가 기존의 오류 처리를 대체하고 결과적으로 오류 경로에 주석을 추가하는 것이 더 어려워질까 걱정됩니다.

메시지를 기록하고 원격 측정 카운터를 업데이트하여 오류를 처리하는 코드는 try 모든 것을 기대하는 린터와 개발자 모두에게 결함이 있거나 부적절한 것으로 간주됩니다.

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

Go는 도구(fmt, lint 등)에 의해 시행되는 일반적인 관용구를 가진 극도로 사회적인 언어입니다. 이 아이디어의 사회적 파급 효과를 염두에 두십시오. 모든 곳에서 사용하려는 경향이 있을 것입니다.

@politician , 죄송합니다. 하지만 찾고 계신 단어는 _social_이 아니라 _opinionated_입니다. Go는 독창적인 프로그래밍 언어입니다. 나머지는 대부분 당신이 무엇을 얻고 있는지에 동의합니다.

@beoran Godep과 같은 커뮤니티 도구와 다양한 린터는 바둑이 독단적이면서 사교적이라는 것을 보여주며, 언어를 사용하는 많은 드라마는 이러한 조합에서 비롯됩니다. 바라건대, 우리 둘 다 try 가 다음 드라마가 되어서는 안 된다는 데 동의할 수 있기를 바랍니다.

@politician 명확히 해 주셔서 감사합니다. 그렇게 이해하지 못했습니다. 나는 우리가 드라마를 피하려고 노력해야 한다는 데 동의할 수 있습니다.

나는 그것에 대해 혼란스러워한다.

블로그에서: Errors are values ​​, 내 관점에서 이것은 무시되지 않는 가치를 갖도록 설계되었습니다.

그리고 저는 Rop Pike가 "값은 프로그래밍될 수 있고 오류는 값이므로 오류도 프로그래밍될 수 있습니다"라고 말한 것을 믿습니다.

우리는 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()) 이러한 오류를 처리하는 방법에 대한 관리 가능한 구문을 갖는 좋은 방법이 될 수 있습니까? 적어도 r.Close() 및 w.Close() 의 오류를 무시하지 않도록 제안에서 CopyFile() 예제를 조정하는 것이 좋습니다.

@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 의 이름 지정입니다. 다른 언어와의 함축된 의미가 다른 언어에서 올 때 그 목적이 무엇인지에 대한 개발자의 인식을 왜곡할 수 있다고 생각합니다. 자바는 여기에 찾아옵니다.

저에게는 pass 라는 내장 기능을 선호합니다. 나는 이것이 무슨 일이 일어나고 있는지 더 잘 표현한다고 생각합니다. 결국 오류를 처리하는 것이 아니라 호출자가 처리하도록 다시 전달하는 것입니다. try 는 오류가 처리되었다는 인상을 줍니다.

그것은 주로 해결하려는 문제("일반적으로 오류 처리와 관련된 상용구문")가 단순히 나에게 문제가 되지 않기 때문입니다. 모든 오류 검사가 단순히 if err != nil { return err } 이면 이에 대한 구문 설탕을 추가하는 데 약간의 가치가 있음을 알 수 있습니다(Go는 성향에 따라 상대적으로 설탕이 없는 언어임).

사실, nil이 아닌 오류가 발생했을 때 내가 하고 싶은 일은 상황마다 상당히 다릅니다. 아마도 t.Fatal(err) 하고 싶습니다. 아마도 장식 메시지 return fmt.Sprintf("oh no: %v", err) 를 추가하고 싶습니다. 아마도 오류를 기록하고 계속할 것입니다. SafeWriter 개체에 오류 플래그를 설정하고 계속 진행하면서 일부 작업 시퀀스가 ​​끝날 때 플래그를 확인합니다. 다른 조치를 취해야 할 수도 있습니다. 이들 중 어느 것도 try 로 자동화할 수 없습니다. 따라서 try 에 대한 인수가 모든 if err != nil 블록을 제거한다는 것이라면 해당 인수는 유효하지 않습니다.

그 중 _일부_가 제거됩니까? 확신하는. 그것이 나에게 매력적인 제안입니까? 음. 나는 정말로 걱정하지 않는다. 나에게 if err != nil 는 중괄호 또는 defer 와 같이 Go의 일부일 뿐입니다. Go를 처음 사용하는 사람들에게는 이것이 장황하고 반복적으로 보일 수 있다는 것을 이해하지만, Go를 처음 사용하는 사람들은 여러 가지 이유로 언어를 극적으로 변경하기에 가장 적합하지 않습니다.

Go에 대한 중요한 변경에 대한 기준은 전통적으로 제안된 변경이 (A) 중요하고, (B) 많은 사람들에게 영향을 미치고, (C) 제안에 의해 잘 해결된 문제를 해결해야 한다는 것이었습니다. 저는 이 세 가지 기준 중 어느 것에도 확신이 없습니다. 나는 Go의 오류 처리가 있는 그대로 매우 만족합니다.

@peterbourgon 및 @deanveloper 를 에코하기 위해 Go에서 내가 가장 좋아하는 것 중 하나는 코드 흐름이 명확하고 panic()이 Python에서와 같은 방식으로 표준 흐름 제어 메커니즘으로 취급 되지 않는다는 것입니다.

패닉에 대한 논쟁과 관련하여, panic()은 가치가 없기 때문에 거의 항상 한 줄에 단독으로 나타납니다. fmt.Println(panic("oops")) 할 수 없습니다. 이것은 가시성을 엄청나게 증가시키고 사람들이 만드는 것보다 try() 와 비교할 수 없게 만듭니다.

함수에 대한 또 다른 흐름 제어 구조가 있다면, 나는 그것이 줄의 맨 왼쪽 항목이 되도록 보장된 명령문을 _far_ 선호할 것입니다.

제안서의 예 중 하나는 다음과 같은 문제를 해결합니다.

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

제어 흐름은 실제로 덜 명확해지고 매우 모호해집니다.

이것은 또한 모든 오류가 명시적으로 처리되어야 한다는 Rob Pike의 초기 의도에 위배됩니다.

이에 대한 반응은 "사용하지 마세요"일 수 있지만 문제는 -- 다른 라이브러리에서 사용할 것이고 디버깅하고 읽고 사용하는 것이 더 문제가 된다는 것입니다. 이것은 우리 회사가 go 2를 채택하지 않도록 동기를 부여하고 try 를 사용하지 않는 라이브러리만 사용하기 시작합니다. 나 혼자가 아니라면 python 2/3 분할로 이어질 수 있습니다.

또한 try 의 이름은 결국 catch 가 구문에 표시되고 Java로 돌아갈 것임을 자동으로 암시합니다.

이 모든 것 때문에 저는 이 제안에 _강력하게_ 반대합니다.

try 이름이 마음에 들지 않습니다. 이것은 실패 위험이 높은 일을 하려는 _시도_를 의미합니다(저는 영어가 모국어가 아니기 때문에 try 에 대한 문화적 편견이 있을 수 있습니다). (오류 처리의 장황함을 줄이려는 동기) 낙관적입니다. 또한 이 제안에서 try 는 실제로 오류를 조기에 반환하는 _캐치_합니다. @HiImJC의 pass 제안이 마음에 듭니다.

이름 외에도 return 와 같은 문이 이제 표현식 중간에 숨겨져 있는 것이 어색합니다. 이것은 Go 흐름 스타일을 깨뜨립니다. 코드 리뷰를 더 어렵게 만들 것입니다.

일반적으로, 나는 이 제안이 더 짧은 코드를 위한 무기를 갖고 있고 오류를 래핑하는 노력을 할 이유가 훨씬 적은 게으른 프로그래머에게만 도움이 될 것이라고 생각합니다. 또한 리뷰를 어렵게 만들기 때문에(표현 중간에 반환), 이 제안은 바둑의 "대규모 프로그래밍" 목표에 어긋난다고 생각합니다.

Go에 대해 내가 언어를 설명할 때 일반적으로 말하는 가장 좋아하는 것 중 하나는 대부분의 경우 작업을 수행하는 방법이 하나뿐이라는 것입니다. 이 제안은 동일한 작업을 수행하는 여러 가지 방법을 제공함으로써 그 원칙에 약간 어긋납니다. 나는 개인적으로 이것이 필요하지 않으며 언어의 단순성과 가독성을 추가하기보다는 제거할 것이라고 생각합니다.

나는 이 제안이 전반적으로 마음에 든다. defer 와의 상호 작용은 추가 컨텍스트를 추가하면서 오류를 반환하는 인체 공학적 방법을 제공하기에 충분해 보입니다. @josharian 이 래핑된 오류 메시지에 원래 오류를 포함하는 방법에 대해 지적한 걸림돌을 해결하는 것이 좋지만.

누락된 것은 테이블에 있는 오류 검사 제안과 상호 작용하는 인체 공학적 방법입니다. API는 반환하는 오류 유형에 대해 매우 신중해야 하며 기본값은 아마도 "반환된 오류는 어떤 식으로든 검사할 수 없음"이어야 한다고 생각합니다. 그러면 함수 서명("상황 A에서 종류 X의 오류 및 상황 B에서 종류 Y의 오류를 보고합니다")에 의해 문서화된 것처럼 정확한 방식으로 오류를 검사할 수 있는 상태로 쉽게 이동해야 합니다.

불행히도 현재로서는 이 제안이 가장 인체공학적인 옵션을 (나에게) 가장 바람직하지 않은 것으로 만듭니다. 맹목적으로 임의의 오류 종류를 통과합니다. 반환하는 오류의 종류와 API 사용자가 오류를 소비하는 방법에 대해 생각하지 않도록 권장하기 때문에 이것이 바람직하지 않다고 생각합니다. 이 제안의 추가된 편리함은 확실히 좋지만, 인식된 편리함이 사용자가 제공하는(또는 누출) 오류 정보에 대해 신중하게 생각하는 인식된 가치보다 더 크기 때문에 나쁜 행동을 조장할까봐 두렵습니다.

반창고는 try 에 의해 반환된 오류가 "래핑할 수 없는" 오류로 변환되는 경우입니다. 불행히도 이것은 defer 가 오류 자체를 검사할 수 없도록 하기 때문에 꽤 심각한 단점도 있습니다. 또한 try 가 실제로 바람직한 종류의 오류를 반환하는 사용을 방지합니다(즉, try 가 부주의하지 않고 신중하게 사용되는 사용 사례).

또 다른 해결책은 해당 사이트에서 반환될 수 있는 오류 종류를 정의/허용 목록에 추가하기 위해 try 에 대한 선택적 두 번째 인수를 갖는 (폐기된) 아이디어의 용도를 변경하는 것입니다. 값( io.EOF 등) 또는 유형( *os.PathError , *exec.ExitError )으로 "오류 종류"를 정의하는 두 가지 다른 방법이 있기 때문에 이것은 약간 번거롭습니다. 값을 함수에 대한 인수로 지정하는 것은 쉽지만 유형을 지정하는 것은 더 어렵습니다. 그것을 처리하는 방법을 모르지만 아이디어를 던지고 있습니다.

@josharian 이 지적한 문제는 err 평가를 지연함으로써 피할 수 있습니다.

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는 분명히 유지되는 오류 참조에도 의존하지만 블록 범위 vars로 오류 참조를 섀도잉하는 데 문제가 발생하는 것을 보았습니다. 따라서 이동 중에 오류를 처리하는 표준 방법으로 간주될 만큼 충분히 어리석은 것은 아닙니다.

이 경우 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를 제어 흐름을 변경하는 것으로 인식하게 될 것입니다. 좋은 IDE 지원이 이것에도 도움이 될 것이라고 믿어 의심치 않습니다.

상당히 무리수라고 생각합니다. gofmt's 코드에서 반환값은 항상 /^\t*return / 와 일치합니다. 도움 없이는 눈으로 식별할 수 있는 매우 사소한 패턴입니다. 반면에 try 는 코드의 어느 곳에서나 발생할 수 있으며 함수 호출에서 임의로 깊숙이 중첩됩니다. 교육을 아무리 많이 해도 도구 지원 없이 기능의 모든 제어 흐름을 즉시 발견할 수는 없습니다.

또한 "좋은 IDE 지원"에 의존하는 기능은 좋은 IDE 지원이 없는 모든 환경에서 불리합니다. 코드 검토 도구가 즉시 떠오릅니다. Gerrit가 모든 시도를 강조 표시할까요? 여러 가지 이유로 IDE 또는 멋진 코드 강조 표시를 사용하지 않기로 선택한 사람들은 어떻습니까? acme가 try 강조 표시하기 시작합니까?

언어 기능은 편집기 지원에 의존하지 않고 그 자체로 이해하기 쉬워야 합니다.

@kungfusheep 나는 그 기사를 좋아한다. defer만으로 래핑을 처리하면 try 없이 이미 가독성이 상당히 향상됩니다.

나는 Go의 오류가 실제로 문제라고 느끼지 않는 캠프에 있습니다. 그럼에도 불구하고 if err != nil { return err } 는 일부 기능에서 상당히 버벅거릴 수 있습니다. 나는 거의 모든 명령문 후에 오류 검사가 필요한 함수를 작성했으며 랩 및 반환 이외의 특별한 처리가 필요하지 않은 함수를 작성했습니다. 때로는 상황을 더 좋게 만드는 영리한 Buffer 구조체가 없을 때가 있습니다. 때때로 이것은 다른 중요한 단계일 뿐이며 문제가 발생하면 단순히 단락시켜야 합니다.

try 가 확실히 이전 버전과 완벽하게 호환되는 동안 해당 코드를 훨씬 더 읽기 쉽게 만들 수 있지만 try 가 중요한 필수 기능이 아니므로 사람들이 너무 두려워하는 경우 없는 것이 최선일 수도 있습니다.

의미론은 아주 명확합니다. try 를 볼 때마다 행복한 경로를 따르거나 반환됩니다. 정말 이보다 더 간단할 수 없습니다.

이것은 특수 케이스 매크로처럼 보입니다.

@dominikh try 는 항상 /try\(/ 와 일치하므로 귀하의 요점이 실제로 무엇인지 모르겠습니다. 검색 가능하고 내가 들어본 모든 편집기에는 검색 기능이 있습니다.

@qrpnxz 내 생각에 그가 말하려는 요점은 프로그래밍 방식으로 검색할 수 없다는 것이 아니라 눈으로 검색하기가 더 어렵다는 것입니다. 정규 표현식은 /^\t* 에 중점을 둔 유추일 뿐이며, 이는 모든 반환값이 줄의 시작 부분에 있음을 의미합니다(선행 공백 무시).

좀 더 생각해보면 몇 가지 일반적인 도우미 기능이 있어야 합니다. 아마도 "지연"이라는 패키지에 있어야 합니다.

check 에 대한 제안을 형식으로 지정하여 반환 이름을 지정하지 않도록 하려면 다음과 같이 nil을 확인하는 함수를 사용하면 됩니다.

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는 대신 지연된 패키지에 넣을 수 있고 내 errors.Defer 도우미 함수 는 deferred.Exec 로 호출될 수 있으며 오류가 nil이 아닌 경우에만 실행되는 프로시저에 대한 조건부 실행이 있을 수 있습니다.

합치면 다음과 같이 된다.

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를 완전히 소유하지 않는 이유는 무엇입니까? 예를 들어 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 키를 누르면 전체 오류 처리 명령문으로 확장됩니다...따라서 작성하는 것이 지루하지 않고 나중에 읽는 것이 더 좋습니다. .

@josharian

"적당한 라이브러리 변경"은 아니지만 func main() 오류도 허용하는 것을 고려할 수 있습니다.

문제는 모든 플랫폼이 그 의미에 대한 명확한 의미를 갖고 있지 않다는 것입니다. 재작성은 전체 운영 체제에서 실행되는 "기존" Go 프로그램에서 잘 작동하지만 마이크로컨트롤러 펌웨어 또는 WebAssembly만 작성하자마자 os.Exit(1) 가 무엇을 의미하는지 명확하지 않습니다. 현재 os.Exit 는 라이브러리 호출이므로 Go 구현은 그것을 제공하지 않는 것만으로도 무료입니다. main 의 모양은 언어 문제입니다.

제안에 대한 질문 중 "아니오"로 가장 잘 대답할 수 있는 질문: try 는 가변 인수와 어떻게 상호 작용합니까? 마지막 인수에 가변성이 없는 가변성(ish) 함수의 첫 번째 경우입니다. 이것이 허용됩니까?

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 코드를 더 좋게 만들지 않습니다. 읽기가 쉽지 않을 것입니다. 더 견고하게 만들지 않습니다.

전에도 말했지만 이 제안이 그것을 예시합니다. Go에 대한 불만의 90%는 "나는 if 문이나 루프를 작성하고 싶지 않습니다" 인 것 같습니다. 이것은 매우 간단한 if 문을 제거하지만 인지 부하를 추가하고 함수의 종료점을 놓치기 쉽습니다.

나는 이것을 메인에서 사용할 수 없으며 새로운 사용자나 가르칠 때 혼란스러울 수 있다는 점을 지적하고 싶습니다. 분명히 이것은 오류를 반환하지 않는 모든 함수에 적용되지만 많은 예제에서 나타나기 때문에 main은 특별하다고 생각합니다.

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

main에서 try 공황 상태로 만드는 것도 허용되는지 확신할 수 없습니다.

또한 불행히도 테스트 ( 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 } 를 대체하는 것 외에는 아무 것도 하지 않는 일종의 마법 같은 새 키워드를 제공하는 것은 위험한 길인 것 같습니다.
이제 모든 코드는 시도 호출로 래핑됩니다. 다음과 같은 패키지 내 오류만 처리하는 코드의 경우 다소 괜찮습니다(가독성은 떨어짐).

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

그러나 나는 주어진 예제가 정말 끔찍하고 기본적으로 호출자가 예외 처리와 마찬가지로 스택에 정말 깊은 오류를 이해하려고 시도하게 만든다고 주장합니다.
물론 여기에서 올바른 일을 하는 것은 모두 개발자의 몫이지만, "나중에 수정할 것"이라는 오류에 대해 개발자가 신경 쓰지 않아도 되는 좋은 방법을 제공합니다. ).

나는 우리가 *"어떻게 하면 반복을 줄일 수 있는가"와 "(적절한) 오류 처리를 더 간단하게 만들고 개발자를 더 생산적으로 만들 수 있는 방법"에 대해 더 많은 관점에서 문제를 보았으면 합니다.
이것이 프로덕션 코드 실행에 어떤 영향을 미칠지 생각해야 합니다.

*참고: 이것은 실제로 반복을 줄이는 것이 아니라 반복되는 내용을 변경하는 것뿐입니다. 모든 것이 try() 안에 있기 때문에 코드 가독성이 떨어집니다.

마지막 요점: 처음에는 제안을 읽는 것이 좋아 보이지만 모든 문제(적어도 나열된 항목)에 빠지기 시작하고 "그래, 이건 너무해"와 같습니다.

나는 이것의 많은 부분이 주관적이라는 것을 알고 있지만 그것은 내가 관심을 갖는 것입니다. 이러한 의미는 매우 중요합니다.
내가 보고 싶은 것은 POC/데모 수준 코드에 대해서도 "올바른" 오류를 수행할 수 있도록 프로덕션 수준 코드 작성 및 유지 관리를 더 간단하게 만드는 방법입니다.

오류 컨텍스트가 반복되는 테마인 것 같아서...

가설: 대부분의 Go 함수는 $ (T1, T2, T3, error) $가 아닌 (T, error) 를 반환합니다.

try 를 try(T1, T2, T3, error) (T1, T2, T3) 로 정의하는 대신 다음과 같이 정의하면 어떻게 될까요?
try(func (args) (T1, T2, T3, error))(T1, T2, T3) ? (이것은 근사치입니다)

즉, try 호출의 구문 구조는 항상 여러 값을 반환하는 표현식인 첫 번째 인수이며 마지막 인수는 오류입니다.

그런 다음 make 와 마찬가지로 두 번째 인수가 try 컨텍스트(예: 고정 문자열, %v , 오류 인수를 취하고 다른 오류를 반환하는 함수 등)

이것은 여전히 (T, error) 케이스에 대한 연결을 허용하지만 일반적으로 IMO가 필요하지 않은 다중 반품을 더 이상 연결할 수 없습니다.

@cpuguy83 제안서를 읽으면 오류를 래핑하는 것을 방해하는 것이 없음을 알 수 있습니다. 실제로 try 를 사용하면서 여러 가지 방법이 있습니다. 많은 사람들이 어떤 이유로 그렇게 생각하는 것 같습니다.

if err != nil { return err } 는 프로토타이핑할 때 더 짜증나는 점을 제외하고는 try 와 "나중에 수정할 것"과 동일합니다.

한 쌍의 괄호 안에 있는 것이 상용구의 4줄마다 있는 함수 단계보다 가독성이 떨어지는지 모르겠습니다.

당신이 주제이기 때문에 당신을 괴롭히는 이러한 특정 "문제" 중 일부를 지적해 주시면 좋을 것입니다.

가독성이 문제인 것 같지만 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() vs foo2() 에서 반환될 수 있는 오류에 대해 다른 오류 처리를 원하면 어떻게 합니까?

@MrTravisB

foo() 대 foo2()에서 반환될 수 있는 오류에 대해 다른 오류 처리를 원하면 어떻게 합니까?

그런 다음 다른 것을 사용합니다. 그것이 @boomlinde 가 말한 요점입니다.

개인적으로 이 사용 사례를 자주 볼 수는 없지만 많은 사람들이 보고 있으며 try 를 추가해도 실제로 영향을 받지 않습니다. 실제로 사용 사례가 드물수록 try 가 추가되는 영향이 적습니다.

@qrpnxz

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

(예, ReadFile 가 있으며 이 특정 예가 요점이 아니라 데이터를 어딘가에 복사하는 가장 좋은 방법이 아니라는 것을 이해합니다)

try의 인라인을 구문 분석해야 하므로 읽는 데 더 많은 노력이 필요합니다. 응용 프로그램 논리는 다른 호출로 래핑됩니다.
나는 또한 여기서 defer 오류 처리기가 새 메시지로 오류를 래핑하는 것을 제외하고는 좋지 않을 것이라고 주장합니다... 이것은 훌륭하지만 오류를 쉽게 처리하는 것보다 오류를 처리하는 것이 더 중요합니다. 무슨 일이 있었는지 읽는 인간.

Rust에서 적어도 연산자는 실제 논리를 파헤치는 데 추가 부담을 주지 않는 접미사( ? 가 호출 끝에 추가됨)입니다.

표현식 기반 흐름 제어

panic 는 또 다른 흐름 제어 기능일 수 있지만 값을 반환하지 않아 효과적으로 명령문을 만듭니다. 이것을 try 와 비교하십시오. 이는 표현식이며 어디에서나 발생할 수 있습니다.

recover 에는 값이 있고 흐름 제어에 영향을 미치지만 defer 문에서 발생해야 합니다. 이러한 defer 는 일반적으로 함수 리터럴이고 recover 는 한 번만 호출되므로 recover 도 효과적으로 명령문으로 발생합니다. 다시, 이것을 어디에서나 발생할 수 있는 try 와 비교하십시오.

나는 그 점들이 try 가 우리가 이전에 지적한 바와 같이 이전에 없었던 방식으로 제어 흐름을 따르는 것을 상당히 어렵게 만든다는 것을 의미한다고 생각합니다. 지적했다.

또 다른 제안

다음과 같은 명령문을 허용합니다.

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

블록에 return 명령문이 포함되어 있고 해당 명령문이 개행 문자를 포함하지 않는 경우 gofmt 에 의해 한 행에 형식이 지정됩니다. 예를 들어:

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

이론적 해석

• 언어 변경이 필요하지 않습니다.
• 서식 규칙은 간단하고 명확합니다.
• gofmt 는 개행이 이미 존재하는 경우(구조체 리터럴과 같이) 유지하는 위치에서 선택하도록 규칙을 설계할 수 있습니다. 옵트인을 통해 작성자는 일부 오류 처리를 강조할 수도 있습니다.
• 선택하지 않은 경우 gofmt 를 호출하여 코드를 새 스타일로 자동 이식할 수 있습니다.
• return 구문에만 해당하므로 불필요하게 골프 코드에 남용되지 않습니다.
• 일부 오류가 발생할 수 있는 이유와 오류가 반환되는 이유를 설명하는 주석과 잘 상호 작용합니다. 많은 중첩 try 표현식을 사용하면 이를 제대로 처리하지 못합니다.
• 오류 처리의 수직 공간을 66% 줄입니다.
• 식 기반 제어 흐름 없음
• 코드는 작성된 것보다 훨씬 더 자주 읽히므로 독자에게 최적화되어야 합니다. 적은 공간을 차지하는 반복적인 코드는 독자에게 도움이 됩니다. try 는 작성자에게 더 많이 기울입니다.
• 사람들은 이미 여러 줄에 try 을 제안했습니다. 예를 들어 이 주석 또는 다음과 같은 스타일을 소개하는 이 주석

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

• "try on its own line" 스타일은 반환되는 err 값에 대한 모호성을 제거합니다. 따라서 이 형식이 일반적으로 사용되지 않을까 생각합니다. 반환 값이 무엇인지 명시한다는 점을 제외하고 블록이 거의 동일한 경우 한 줄로 허용
• 명명된 반환 또는 불명확한 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 를 통해 스캔할 수 있습니다. try 가 더 쉽습니다. 왜냐하면 내가 볼 때 즉시 행동을 알기 때문입니다. err != nil을 반환합니다. 지점이 있다면 그 지점이 무엇을 하는지 봐야 합니다. 무엇이든 할 수 있습니다.

나는 또한 여기서 오류 처리기를 새 메시지로 오류를 래핑하는 것을 제외하고는 좋지 않을 것이라고 주장합니다.

연기할 때 할 수 있는 다른 일이 있을 거라고 확신하지만, 어쨌든 try 는 간단한 일반적인 경우를 위한 것입니다. 더 많은 작업을 수행하고 싶을 때마다 항상 좋은 ol' Go 오류 처리가 있습니다. 그것은 사라지지 않을 것입니다.

@zeebo 네, 저는 그것에 빠져있습니다.
@kungfusheep 의 기사는 그런 한 줄 오류 검사를 사용했고 나는 그것을 시도하기 위해 종료했습니다. 그런 다음 저장하자마자 gofmt에서 슬펐던 세 줄로 확장했습니다. stdlib의 많은 기능이 이와 같이 한 줄에 정의되어 있으므로 gofmt가 이를 확장할 것이라는 사실에 놀랐습니다.

@qrpnxz

나는 많은 go 코드를 읽는다. 이 언어의 가장 좋은 점 중 하나는 특정 스타일을 따르는 대부분의 코드에서 쉽게 얻을 수 있다는 것입니다(gofmt에 감사드립니다).
try(f()) 로 래핑된 많은 코드를 읽고 싶지 않습니다 .
이것은 코드 스타일/실습에 차이가 있거나 "오, 여기에 try() 를 사용했어야 했습니다"와 같은 린터가 있음을 의미합니다. 이 제안에 대해).

객관적 으로 if err != nil { return err } 보다는 낫지 않고, 타이핑이 덜할 뿐입니다.

마지막 한가지:

당신이 제안을 읽으면 당신을 방해하는 것이 아무것도 없다는 것을 알게 될 것입니다.

그런 말은 삼가해 주십시오. 물론 제안서를 읽었습니다. 어젯밤에 그것을 읽고 오늘 아침에 그것에 대해 생각한 후 댓글을 달았고 내가 의도한 것의 세부 사항을 설명하지 않았습니다.
이것은 매우 적대적인 음색입니다.

@cpuguy83
내 나쁜 CPU 녀석. 그런 뜻이 아니었어요.

그리고 try 를 사용하는 코드가 그렇지 않은 코드와 상당히 다르게 보일 것이라는 점을 지적해야 할 것 같습니다. 따라서 이것이 해당 코드를 구문 분석하는 경험에 영향을 미칠 것이라고 상상할 수 있지만, 이 경우 더 나쁘다는 것을 의미합니다. 하지만 제가 개인적으로 좋아하는 것처럼 당신도 개인적으로 좋아하지 않는다는 것을 이해합니다. Go의 많은 것들이 그런 식입니다. 린터가 당신에게 무엇을 하라고 말하는지는 완전히 다른 문제라고 생각합니다.

물론 객관적으로 더 나은 것은 아닙니다. 나는 그것이 나에게 더 읽기 쉽다고 표현하고 있었다 . 나는 그것을 조심스럽게 말했다.

다시 한 번 말씀드리지만 죄송합니다. 비록 이것이 논쟁이지만 당신을 적대시할 의도는 없었습니다.

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

아무도 시도를 사용하지 않을 것입니다.

뻔뻔함을 무시하고, 디자인 비판을 무시하는 꽤 손에 땀을 쥐게 하는 방법이라고 생각합니다.

물론, 나는 그것을 사용할 필요가 없습니다. 하지만 나와 함께 코드를 작성하는 사람은 누구나 그것을 사용할 수 있고 나에게 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 에 대한 귀하의 의견과 관련하여 여기에 초기 평가 오류가 있다고 생각하지 않습니다.

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

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())

^^ 이마저도 끔찍합니다. 첫 번째 줄은 머리 속에서 paren 매칭을 하면서 앞뒤로 점프해야 합니다. 실제로는 아주 간단한 두 번째 줄도... 읽기가 정말 어렵습니다.
중첩된 함수는 읽기 어렵습니다.

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

^^ 이것은 훨씬 더 쉽고 더 나은 IMO입니다. 매우 간단하고 명확합니다. 예, 훨씬 더 많은 코드 라인이 있습니다. 저는 상관하지 않습니다. 그것은 매우 분명합니다.

@bcmills @josharian 아 물론 감사합니다. 그래서 그것은 있어야합니다

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

그렇게 좋지 않습니다. 아마도 fmt.HandleErrorf 는 암시적으로 오류 값을 마지막 인수로 전달해야 합니다.

이 문제는 많은 댓글을 매우 빠르게 받았고 그 중 상당수는 이미 작성된 댓글을 반복하는 것 같습니다. 물론 댓글은 자유롭게 말씀드리지만, 이미 지적한 부분을 다시 언급하고 싶으시다면 요점을 반복하는 것보다 GitHub의 이모티콘을 사용하여 다시 말씀해 주시기 바랍니다. 감사 해요.

@ianlancetaylor fmt.HandleErrorf 가 형식 후 첫 번째 인수로 err을 보내면 구현이 더 좋아지고 사용자는 항상 %[1]v 로 참조할 수 있습니다.

@natefinch 전적으로 동의합니다.

러스트 스타일 접근 방식이 더 맛있을지 궁금합니다.
생각만 하는 제안은 아니니 참고하세요...

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

결국 나는 이것이 더 좋다고 생각하지만 ( ! 또는 다른 것을 사용할 수도 있습니다...), 여전히 오류 처리 문제를 잘 해결하지 못합니다.

물론 Rust에도 try() 가 있습니다. 하지만... 다른 Rust 스타일입니다.

if err != nil { return err } 보다 _객관적으로_ 좋지 않습니다. 다만 입력하는 것이 적습니다.

둘 사이에는 한 가지 객관적인 차이가 있습니다. try(Foo()) 는 표현식입니다. 어떤 사람들에게는 그 차이가 단점입니다( try(strconv.Atoi(x))+try(strconv.Atoi(y)) 비판). 다른 사람들에게는 그 차이가 거의 같은 이유로 장점입니다. 여전히 객관적으로 더 좋거나 나쁘진 않습니다. 그러나 나는 그 차이가 양탄자 아래에서 휩쓸려야 하고 그것이 "그저 타이핑을 덜 한다"고 주장하는 것이 제안을 정당화하지 않는다고 생각합니다.

이것이 내가 이 구문을 좋아하는 가장 큰 이유 중 하나입니다. 모든 중간 결과의 이름을 지정할 필요 없이 더 큰 표현식의 일부로 오류 반환 함수를 사용할 수 있습니다. 어떤 상황에서는 이름을 짓는 것이 쉽지만 어떤 상황에서는 특별히 의미가 있거나 중복되지 않는 이름을 지정하지 않습니다. 이 경우에는 이름을 아예 지정하지 않는 것이 좋습니다.

@MrTravisB

정확히 내 요점. 이 제안은 오류 처리의 더 큰 문제를 해결하기 위한 도구를 제공하기보다 단일 사용 사례를 해결하려고 합니다. 나는 당신이 지적한 것이 정확히 무엇인지 근본적인 질문이라고 생각합니다.

내가 구체적으로 말한 것이 정확히 당신의 요점입니까? 오히려 우리가 동의한다고 생각한다면 내 말을 근본적으로 잘못 이해하신 것 같습니다.

제 생각과 경험에 따르면 이 사용 사례는 소수에 불과하며 속기 구문을 보증하지 않습니다.

Go 소스에는 오류에 컨텍스트를 추가할 방법이 없더라도 기본적으로 try 로 처리할 수 있는 수천 가지 경우가 있습니다. 경미한 경우에도 여전히 일반적인 불만 사항입니다.

또한 defer를 사용하여 오류를 처리하는 접근 방식은 가능한 모든 오류를 동일하게 처리하기를 원한다고 가정한다는 점에서 문제가 있습니다. defer 문은 취소할 수 없습니다.

유사하게, 산술을 처리하기 위해 +를 사용하는 접근 방식은 뺄셈을 원하지 않는다고 가정하므로 원하지 않는 경우 하지 않습니다. 흥미로운 질문은 블록 전체의 오류 컨텍스트가 최소한 공통 패턴을 나타내는지 여부입니다.

foo() 대 foo2()에서 반환될 수 있는 오류에 대해 다른 오류 처리를 원하면 어떻게 합니까?

다시 말하지만 try 를 사용하지 않습니다. 그러면 try 에서 아무 것도 얻지 못하지만 잃을 것도 없습니다.

@cpuguy83

러스트 스타일 접근 방식이 더 맛있을지 궁금합니다.

제안은 이에 대한 주장을 제시합니다.

이 시점에서 try{}catch{} 가 더 읽기 쉽다고 생각합니다.upside_down_face:

1. defer 코너 케이스를 돌기 위해 명명된 가져오기를 사용하는 것은 godoc과 같은 것들에 끔찍할 뿐만 아니라 가장 중요한 것은 매우 오류가 발생하기 쉽습니다. 나는 문제를 해결하기 위해 다른 func() 로 모든 것을 포장할 수 있다는 점에 신경 쓰지 않습니다. 그것은 내가 명심해야 할 더 많은 것들입니다. 제 생각에는 그것이 "나쁜 습관"을 조장한다고 생각합니다.

2. 아무도 시도를 사용하지 않을 것입니다.

   그렇다고 해서 그것이 좋은 솔루션이라는 의미는 아닙니다. 현재 아이디어에 디자인에 결함이 있다는 점을 지적하고 있으며 오류가 발생하기 쉬운 방식으로 해결되기를 요청합니다.

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 는 오류를 받아 덮어쓴 오류를 반환하는 함수를 수신한 다음 후속 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 가 마음에 들지 않으면 사용할 필요가 없습니다.

이제... 마지막 문장을 의미하지는 않지만 토론에 도움이 되지 않는 것처럼 느껴집니다. 매우 공격적인 IMO입니다.
그래도 우리가 이 길을 간다면 try{}catch(error err){} 를 가질 수 있다고 생각합니다 :stuck_out_tongue:

#27519 - #id/catch 오류 모델도 참조하십시오.

아무도 시도를 사용하지 않을 것입니다.

뻔뻔함을 무시하고, 디자인 비판을 무시하는 꽤 손에 땀을 쥐게 하는 방법이라고 생각합니다.

죄송합니다. glib는 제 의도가 아니었습니다.

내가 말하려는 것은 try 이 100% 솔루션이 될 수 없다는 것입니다. try 에서 잘 처리되지 않는 다양한 오류 처리 패러다임이 있습니다. 예를 들어 호출 사이트 종속 컨텍스트를 오류에 추가해야 하는 경우입니다. 더 복잡한 경우를 처리하기 위해 언제든지 if err != nil { 를 사용할 수 있습니다.

try 가 X의 다양한 인스턴스에 대해 X를 처리할 수 없다는 것은 확실히 유효한 주장입니다. 그러나 종종 경우 X를 처리하는 것은 메커니즘을 더 복잡하게 만드는 것을 의미합니다. 여기에는 한 손으로 X를 처리하지만 다른 모든 것에 대한 메커니즘을 복잡하게 만드는 절충점이 있습니다. 우리가 하는 일은 X가 얼마나 흔한지, 그리고 X를 다루기 위해 얼마나 많은 복잡성이 필요한지에 달려 있습니다.

그래서 "아무도 당신을 시도하게 만들지 않을 것입니다"라는 말은 문제의 예가 90%가 아니라 10%에 있다고 생각한다는 의미입니다. 그 주장은 확실히 논쟁의 여지가 있으며 나는 반론을 듣게 되어 기쁩니다. 그러나 결국 우리는 어딘가에 선을 긋고 "예, try 는 그 경우를 처리하지 않을 것입니다. 당신은 구식 오류 처리를 사용해야 할 것입니다. 죄송합니다."라고 말해야 할 것입니다.

문제는 "시도가 오류 처리의 이 특정한 경우를 처리할 수 없습니다"가 아니라 "시도에서 오류를 래핑하지 않도록 권장합니다"입니다. check-handle 아이디어로 인해 return 문을 작성해야 했기 때문에 오류 래핑을 작성하는 것은 매우 간단했습니다.

이 제안에 따라 defer 와 함께 명명된 반환을 사용해야 합니다. 이는 직관적이지 않고 매우 해키해 보입니다.

check-handle 아이디어로 인해 return 문을 작성해야 했기 때문에 오류 래핑을 작성하는 것은 매우 간단했습니다.

그것은 사실이 아닙니다. 디자인 초안에서 오류를 반환하는 모든 함수에는 오류를 반환하는 기본 처리기 가 있습니다.

@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 를 사용하기 때문에 nil이 아닌 오류가 반환될 때마다 handle func를 호출할 수 있으므로 try 없이도 유용합니다.

defer handler(wrapErrWithPackageName)

맨 위에 fmt.Errorf("mypkg: %w", err) 모든 것.

그것은 당신에게 오래된 check / handle 제안을 많이 제공하지만 대부분의 경우 명시적으로 err 의 이름을 지정할 필요성을 없애면서 자연스럽게(그리고 명시적으로) defer와 함께 작동합니다. try 와 같이 프론트 엔드에서 완전히 구현할 수 있는 비교적 간단한 매크로입니다.

그것은 사실이 아닙니다. 디자인 초안에서 오류를 반환하는 모든 함수에는 오류를 반환하는 기본 처리기가 있습니다.

내 나쁜, 당신이 맞습니다.

문제의 예는 90%가 아니라 10%에 있다고 생각합니다. 그 주장은 확실히 논쟁의 여지가 있으며 나는 반론을 듣게 되어 기쁩니다. 그러나 결국 우리는 어딘가에 선을 긋고 "예, 시도는 그 경우를 처리하지 않을 것입니다. 당신은 구식 오류 처리를 사용해야 할 것입니다. 죄송합니다."라고 말해야 할 것입니다.

동의합니다. 제 생각에는 이 선은 래핑이 아니라 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 또는 오류를 캡처하는 방법을 알고 있는 일반 처리기(이 경우 2개의 문자열 매개변수 사용)에 인라인될 수 있습니다. 따라서 많은 함수에서 동일한 반복 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가 not 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
}

등.

다시 목표를 넘어서

• 상용구 제거 - 완료
• 최소한의 언어 변경 - 완료
• "가장 일반적인 시나리오" 다루기 - 제안된 IMO 이상
• 언어에 약간의 복잡성 추가 - 손
  플러스 - 보다 쉬운 코드 마이그레이션

x, err := strconv.Atoi(a)

에게

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

그리고 실제로 - 더 나은 가독성(IMO, 다시)

@guybrand 당신은 (내가 좋아하는) 이 되풀이되는 주제에 대한 최신 지지자입니다.

https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback#recurring -themes 참조

@guybrand 완전히 다른 제안처럼 보입니다. @griesemer 의 제안에 대해 논의하는 데 집중할 수 있도록 자체 문제로 제출해야 한다고 생각합니다.

@natefinch 동의합니다. 나는 이것이 읽기를 최적화하는 대신 Go를 쓰는 동안 경험을 향상시키는 데 더 적합하다고 생각합니다. IDE 매크로나 스니펫이 이것이 언어의 기능이 되지 않고 문제를 해결할 수 있는지 궁금합니다.

@굿와인

유용한 컨텍스트로 오류를 래핑하는 것이 좋습니다. try() 컨텍스트를 추가하지 않기 때문에 나쁜 습관으로 간주됩니다. 즉, try() 는 아무도 사용하고 싶어하지 않는 기능이며 거의 사용되지 않아 존재하지 않았을 수도 있는 기능이 됩니다.

제안서에서 언급한 바와 같이(예시로 표시됨) try 는 기본적으로 컨텍스트를 추가하는 것을 방지하지 않습니다. 나는 그것이 제안된 방식, 오류에 컨텍스트를 추가하는 것이 완전히 직교한다고 말하고 싶습니다. 이것은 제안의 FAQ에서 구체적으로 다룹니다.

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에서 피하려고 하는 것을 우려합니다. 또한 try 를 강조하기 위한 IDE 지원은 충분하지 않을 수 있습니다(@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 이 한 줄(@zeebo)의 오류를 검사하는 if 문을 형식화하도록 허용하여 기존 코드를 더 간결하게 만들 수 있습니다.

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) 오류 테스팅( try ) 관점이 아닌 오류 처리( handle ) 관점에서 문제를 살펴보는 것을 고려했습니다. 특히, 우리는 간단히 오류 처리기의 개념을 도입하는 것만 고려했습니다(작년 Gophercon에서 발표된 원래 디자인 초안과 유사). 마지막 값이 error 유형인 다중 값 할당에서 핸들러가 선언된 경우에만 해당 값을 할당에서 생략할 수 있다고 생각했습니다. 컴파일러는 그것이 nil이 아닌지 암시적으로 확인하고 만약 그렇다면 핸들러로 분기합니다. 그러면 명시적 오류 처리가 완전히 사라지고 모든 사람이 대신 처리기를 작성하도록 권장합니다. 이것은 완전히 암시적이기 때문에 극단적인 접근 방식처럼 보였습니다. 검사가 발생한다는 사실은 보이지 않을 것이기 때문입니다.

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는 단일 함수의 모든 오류가 정확히 한 방향으로 래핑되어야 하는 경우에만 상용구를 줄이는 데 도움이 되며, 함수가 다르게 래핑해야 할 수 있는 5개의 오류를 처리하는 경우에는 도움이 되지 않습니다. 야생에서 그러한 경우가 얼마나 흔한지(대부분의 프로젝트에서 꽤 일반적임) 확실하지 않지만 try() 가 다른 오류를 래핑하는 것이 합리적일 때에도 사람들이 함수당 공통 래퍼를 사용하도록 권장할 수 있다고 우려합니다. 다르게.

작은 샘플 세트의 데이터로 뒷받침되는 간단한 설명:

우리는 일반적으로 Go의 오류 처리와 관련된 상용구 if 문을 제거하도록 특별히 설계된 try라는 새로운 내장 함수를 제안합니다.

이것이 이 제안으로 해결되는 핵심 문제인 경우 이 "보일러 플레이트"는 총 ~60k SLOC에 달하는 수십 개의 공개 오픈 소스 프로젝트에서 내 코드의 ~1.4%만 차지하는 것으로 나타났습니다.

다른 사람이 비슷한 통계를 가지고 있는지 궁금하십니까?

Go 자체와 같은 훨씬 더 큰 코드베이스에서 총 ~160만 SLOC는 if err != nil 와 같은 행이 있는 코드베이스의 약 ~0.5%에 해당합니다.

이것이 Go 2로 해결해야 할 가장 영향력 있는 문제입니까?

시간을 내어 모든 사람의 아이디어를 살펴보고 명시적으로 생각을 제공한 @griesemer 에게 대단히 감사합니다. 그 과정에서 커뮤니티의 목소리가 들린다는 인식에 정말 도움이 된다고 생각합니다.

1. @pierrec 는 gofmt가 try 표현식을 적절하게 형식화하여 더 잘 보이도록 할 수 있다고 제안했습니다.
   또는 gofmt에서 한 줄(@zeebo)의 오류를 검사하는 if 문을 형식화하도록 허용하여 기존 코드를 더 간결하게 만들 수 있습니다.

1. gofmt 를 사용하여 $ try 표현식의 형식을 지정하여 추가로 눈에 띄도록 하는 것은 확실히 옵션입니다. 그러나 표현식에 사용될 때 try 의 일부 이점이 사라집니다.

이것들은 try 형식을 지정하기 위해 gofmt 을 요구하는 것에 대한 귀중한 생각이지만 if gofmt 에 대해 특별히 생각이 있는 경우 관심이 있습니다. 오류는 한 줄입니다. 제안은 try 형식으로 일괄 처리되었지만 완전히 직교하는 것이라고 생각합니다. 감사 해요.

@griesemer 모든 의견을 검토하고 피드백의 전부는 아닐지라도 가장 많이 답변해 주신 놀라운 작업에 감사드립니다 🎉

귀하의 피드백에서 해결되지 않은 한 가지는 Go 구문을 업데이트하는 대신 오류 처리 경험을 개선하기 위해 Go 언어의 도구/검토 부분을 사용하는 아이디어였습니다.

예를 들어, 새로운 LSP( gopls )가 출시되면서 함수의 서명을 분석하고 개발자를 위한 오류 처리 상용구를 처리하고 적절한 래핑 및 검사도 수행하기에 완벽한 장소인 것 같습니다.

@griesemer 나는 이것이 잘 생각되지 않았다고 확신하지만, https://www.reddit.com/r/golang/comments/bwvyhe 에서 내가 편안할 수 있는 것에 더 가깝게 귀하의 제안을 수정하려고 했습니다.

@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 도구가 당신을 위해 무엇을 제안하는지 잘 모르겠습니다. 어떻게 든 오류 처리를 숨길 것을 제안합니까?

@dpinela

@guybrand 완전히 다른 제안처럼 보입니다. @griesemer 의 제안에 대해 논의하는 데 집중할 수 있도록 자체 문제로 제출해야 한다고 생각합니다.

IMO 내 제안은 구문 만 다릅니다. 의미:

• 목표는 내용과 우선 순위가 비슷합니다.
• 자체 라인 내에서 각 오류를 캡처하고 그에 따라 (nil이 아닌 경우) 핸들러 함수를 통과하는 동안 함수를 종료하는 아이디어는 유사합니다(의사 asm - "jnz" 및 "호출").
• 이것은 심지어 함수 본문의 줄 수(지연 없음)와 흐름이 정확히 유사하게 보일 것임을 의미합니다(따라서 AST도 아마 동일하게 나타날 것입니다).

그래서 주된 차이점은 우리가 항상 마지막 var to jnz 호출을 분석하거나 그렇게 하기 위해 실제 반환 값을 사용하는 try(func())로 원래 함수 호출을 래핑하는지 여부입니다.

나는 그것이 다르게 보이지만 실제로는 개념적으로 매우 유사하다는 것을 알고 있습니다.
반면에 - 일반적인 시도 .... 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) }

첫 번째 줄과 마지막 줄이 가장 명확해 보입니다. 특히 try를 있는 그대로 인식하는 데 사용되면 더욱 그렇습니다. 마지막 줄에서 오류는 명시적으로 검사되지만 (일반적으로) 주요 작업이 아니기 때문에 백그라운드에서 좀 더 많이 발생합니다.

마지막 줄에는 비용의 일부가 숨겨져 있습니다. 커뮤니티에서 권장하는 모범 사례라고 목소리로 말한 오류에 주석을 달고 싶다면 함수 서명을 변경하여 인수의 이름을 지정하고 단일 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-at-work

마지막 댓글에서 언급했듯이:

이 제안의 이유는 오류 처리(특히 관련 상용구 코드)가 Go 커뮤니티에서 (제네릭 부족과 함께) Go에서 중요한 문제로 언급되었기 때문입니다.

따라서 문제의 핵심은 프로그래머가 결국 많은 상용구 코드를 작성하게 된다는 것입니다. 따라서 문제는 읽기가 아니라 쓰기에 관한 것입니다.

나는 그것이 실제로 반대라고 생각합니다. 현재 오류 처리 상용구의 가장 큰 성가심은 입력해야 하는 것이 아니라 화면 전체에 수직으로 함수의 행복한 경로를 분산시켜 이해하기 어렵게 만드는 방법입니다. 곁눈질. 그 효과는 일반적으로 두 작업 사이에 상용구 블록이 있는 I/O가 많은 코드에서 특히 두드러집니다. CopyFile 의 단순한 버전조차도 실제로 5단계(오픈 소스, 닫기 소스 연기, 대상 열기, 소스 복사 -> 대상, 대상 닫기)만 수행하더라도 20줄 정도 걸립니다.

현재 구문의 또 다른 문제는 앞에서 언급한 것처럼 각각 오류를 반환할 수 있는 일련의 작업이 있는 경우 현재 구문이 모든 중간 결과에 이름을 지정해야 한다는 것입니다. 익명으로 남겨주세요. 이런 일이 발생하면 정보가 많지 않더라도 해당 이름을 구문 분석하는 데 두뇌 주기를 사용해야 하기 때문에 가독성도 떨어집니다.

나는 별도의 줄에 try 를 좋아합니다.
그리고 handler func를 독립적으로 지정할 수 있기를 바랍니다.

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 결과 변수에 직접 액세스할 수 있습니다. 다시 쓰기는 다음과 같이 보일 수 있습니다.

[편집됨] 추신: 더 나은 대답은 다음과 같습니다. try 는 알몸 반환이 아닙니다(다시 작성하는 것처럼 보이지만). 결국 try nil 가 아닌 경우 반환되는 오류를 포함하는(또는 포함하는) 인수를 명시적으로 제공합니다. 네이키드 리턴에 대한 섀도우 오류는 소스의 오류입니다(소스의 기본 번역이 아닙니다. 컴파일러에는 오류가 필요하지 않습니다.

가장 중요한 함수의 최종 반환 유형이 오류 유형이 아닌 경우 당황할 수 있습니까?

빌트인을 더 다재다능하게 만들 것입니다(예: #32219에서 내 관심사를 만족시킴)

@pjebs 이것은 고려되어 결정되었습니다. 세부 설계 문서(이 주제에 대한 귀하의 문제를 명시적으로 언급함)를 읽으십시오.

나는 또한 try()가 return 문으로 작동하더라도 표현식으로 취급된다는 점을 지적하고 싶습니다. 예, 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는 오류가 발생하면 패닉 상태가 됩니다. (제쳐두고, 그 속성 때문에 내장은 그 제안에서 try보다는 must라고 불렸습니다.) try(또는 must)가 컨텍스트에 민감한 방식으로 행동하는 것은 자연스럽고 매우 유용해 보였습니다. 많은 사용자 정의 필수 도우미 함수는 현재 패키지 수준 변수 초기화 표현식에서 사용됩니다. 또한 테스트 패키지를 통해 단위 테스트에서 시도를 사용할 수 있는 가능성이 열립니다.

그러나 try의 컨텍스트 감도는 어려운 것으로 간주되었습니다. 예를 들어 오류 결과가 서명에서 추가되거나 제거되면 try 호출을 포함하는 함수의 동작이 조용히(패닉 상태에서 패닉 상태가 아닌 상태로 또는 그 반대로) 변경될 수 있습니다. 이것은 너무 위험한 재산처럼 보였습니다. 명백한 해결책은 try의 기능을 must와 try라는 두 개의 개별 기능으로 나누는 것이었습니다(문제 #31442에서 제안한 것과 매우 유사). 그러나 더 나은 오류 처리 지원에 대한 즉각적인 요구에 직접 연결된 시도와 함께 두 개의 새로운 내장 함수가 필요했을 것입니다.

@pjebs 그것이 _정확히_ 우리가 이전 제안에서 고려한 것입니다(자세한 문서, 디자인 반복 섹션, 4번째 단락 참조):

또한 오류 결과가 있는 함수 내부에서만이 아니라 try를 유용하게 만들려는 시도에서 try의 의미는 컨텍스트에 따라 다릅니다. try가 패키지 수준에서 사용되었거나 오류 결과 없이 함수 내부에서 호출된 경우, try는 오류가 발생하면 패닉 상태가 됩니다. (제쳐두고, 그 속성 때문에 내장은 그 제안에서 시도하기 보다는 must라고 불렸습니다.)

(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-able이 추가됩니다. 이렇게 하면 예외 대신 오류 처리가 기본값이 됩니다. 오류를 변경하지 않고 전달하려는 경우 핸들러에 nil 값을 제공하기만 하면 try 가 원래 제안에서와 같이 동작하지만 nil 인수는 오류가 처리되지 않습니다. 코드 검토 중에 잡기가 더 쉬울 것입니다.

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

핸들러가 제공되었지만 nil이면 어떻게 됩니까? 패닉을 시도하거나 부재 오류 처리기로 처리해야 합니까?

위에서 언급했듯이 try 은 원래 제안에 따라 작동합니다. 부재 오류 핸들러 같은 것은 없고 오직 하나뿐입니다.

핸들러가 nil이 아닌 오류로 호출된 다음 nil 결과를 반환하면 어떻게 될까요? 이것은 오류가 "취소됨"을 의미합니까? 아니면 둘러싸는 함수가 nil 오류와 함께 반환되어야 합니까?

나는 둘러싸는 함수가 nil 오류와 함께 반환될 것이라고 믿습니다. try 가 nil이 아닌 오류 값을 받은 후에도 실행을 계속할 수 있다면 잠재적으로 매우 혼란스러울 수 있습니다. 이렇게 하면 일부 상황에서 핸들러가 오류를 "처리"할 수 있습니다. 이 동작은 예를 들어 "가져오기 또는 만들기" 스타일 함수에서 유용할 수 있습니다.

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)
}

또한 선택적 오류 처리기를 허용하면 프로그래머가 적절한 오류 처리를 완전히 무시하게 될지 여부도 분명하지 않았습니다. 또한 모든 곳에서 적절한 오류 처리를 쉽게 수행할 수 있지만 시도를 한 번만 놓치게 됩니다. 기타 등등.

핸들러를 nil-able 필수 인수로 만들면 이러한 두 가지 우려가 모두 완화된다고 생각합니다. 프로그래머는 오류를 처리하지 않을 것이라는 의식적이고 명시적인 결정을 내려야 합니다.

보너스로, 오류 처리기를 요구하는 것도 덜 간단하기 때문에 깊게 중첩된 try 를 권장하지 않는다고 생각합니다. 누군가는 이것을 단점으로 생각할 수도 있지만 나는 이것이 장점이라고 생각합니다.

@velovix 아이디어가 마음에 들지만 오류 처리기가 필요한 이유는 무엇입니까? 기본적으로 nil 가 될 수 없나요? 왜 "시각적 단서"가 필요한가요?

@griesemer @velovix 아이디어가 채택되었지만 builtin 에 err 을 패닉으로 변환하는 사전 정의된 함수가 포함되어 있고 지나치게 중요한 함수에 오류 반환 값이 있어야 한다는 요구 사항을 제거하면 어떻게 될까요?

가장 중요한 함수가 오류를 반환하지 않는 경우 오류 처리기 없이 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
Go의 기존 if 모양과 더 호환됩니다.

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 변형과 다시 유사해집니다.
개인적으로 이 경우 try return if 를 선호합니다. 왜냐하면 이것이 함수의 종료점을 매우 명시적으로 만들기 때문입니다. 예를 들어 디버깅할 때 나는 종종 편집기 내에서 키워드 return 를 강조 표시하여 큰 함수의 모든 종료점을 식별합니다.

불행히도 디버그 로깅을 삽입하는 불편함에도 충분히 도움이 되지 않는 것 같습니다.
return if body 블록도 허용하지 않는 한 다음과 같이
원래의:

        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 팀 내에서의 우리의 경험이었습니다). 예를 들어, 핸들러 인수는 항상 제공되어야 하지만 nil 일 수 있다고 명시하고 있어 오류 처리에 대해 신경 쓰지 않습니다. 이제 함수 값( nil 리터럴이 아님)을 제공하고 해당 함수 값(변수에 저장된)이 nil이면 어떻게 될까요? 명시적 nil 값과 유사하게 처리할 필요가 없습니다. 그러나 다른 사람들은 이것이 코드의 버그라고 주장할 수 있습니다. 또는 nil 값 처리기 인수를 허용할 수 있지만 함수는 어떤 경우에는 일관성 없이 오류를 처리할 수 있고 다른 경우에는 처리하지 않을 수 있으며 처리기가 항상 존재하는 것처럼 보이기 때문에 수행하는 코드에서 반드시 명확하지는 않습니다. . 또 다른 주장은 함수가 오류를 처리한다는 것을 매우 명확하게 하기 때문에 오류 처리기의 최상위 선언을 갖는 것이 더 낫다는 것입니다. 따라서 defer . 아마 더 있을 것입니다.

이 문제에 대해 자세히 알아보는 것이 좋습니다. 오류를 테스트하기 위해 if 문을 사용하는 현재 코딩 스타일은 최대한 명시적입니다. 개별적으로(각각의 경우에 대해) 오류에 추가 정보를 추가하는 것은 매우 쉽습니다. 종종 함수에서 감지된 모든 오류를 균일한 방식으로 처리하는 것이 합리적입니다. 이는 연기로 수행할 수 있습니다. 이것은 이미 가능합니다. 우리는 이미 언어에서 좋은 오류 처리를 위한 모든 도구를 가지고 있다는 사실과 처리기 구성이 지연에 직교하지 않는 문제로 인해 오류를 보강하기 위한 새로운 메커니즘을 그냥 두게 되었습니다.

@griesemer - IIUC, 호출 사이트 종속 오류 컨텍스트의 경우 현재 if 문이 괜찮다고 합니다. 반면에 이 새로운 try 함수는 한 곳에서 여러 오류를 처리하는 것이 유용한 경우에 유용합니다.

단순히 if err != nil { return err} 를 수행하는 것이 어떤 경우에는 괜찮을 수 있지만 일반적으로 반환하기 전에 오류를 장식하는 것이 좋습니다. 그리고 이 제안은 전자를 다루는 것으로 보이며 후자에는 별로 도움이 되지 않습니다. 이는 본질적으로 사람들이 쉬운 반환 패턴을 사용하도록 권장된다는 것을 의미합니다.

@agnivade 맞습니다. 이 제안은 오류 장식에 전혀 도움이 되지 않습니다(그러나 defer 사용을 권장하기 위한 것입니다). 한 가지 이유는 이에 대한 언어 메커니즘이 이미 존재하기 때문입니다. 특히 개별 오류 기준으로 오류 데코레이션이 필요한 즉시 데코레이션 코드에 대한 추가 소스 텍스트 양이 비교하여 if 를 덜 부담스럽게 만듭니다. 장식이 필요하지 않거나 장식이 항상 동일한 경우 상용구가 눈에 보이는 골칫거리가 되어 중요한 코드를 손상시키는 경우입니다.

사람들은 이미 쉬운 반환 패턴을 사용하도록 권장하고 있습니다. try 또는 try , 쓸 것이 적습니다. 생각해 보면 _오류 장식을 장려하는 유일한 방법은 의무화하는 것입니다_. 어떤 언어 지원을 사용할 수 있더라도 오류 장식에는 더 많은 작업이 필요하기 때문입니다.

거래를 부드럽게 하는 한 가지 방법은 try (또는 유사한 단축키 표기법)와 같은 것을 허용하는 것입니다. _if_ 명시적(비어 있을 수 있음) 처리기가 어딘가에 제공됩니다(원래 초안 디자인 에는 이러한 요구 사항).

우리가 지금까지 가고 싶은지 잘 모르겠습니다. 라이브러리의 내부와 같이 완벽하게 훌륭한 많은 코드가 모든 곳에서 오류를 장식할 필요가 없다는 점을 다시 말씀드리겠습니다. 예를 들어 오류가 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 입니다.
물론, 우리는 오류를 반환하는 func가 있는 명백한 코너 케이스가 있습니다. 이 경우 오류 값을 그냥 통과하는 것이 편리할 것이라고 생각합니다.

따라서 기본적으로 catch()를 사용하여 실제로 패닉을 복구하고 오류로 전환할 수 있습니다.
Go는 실제로 예외가 없기 때문에 이것은 나에게 꽤 재미있어 보입니다. 그러나 이 경우 우리는 꽤 깔끔한 try()-catch() 패턴을 가지고 있습니다. 또한 Java( catch(Throwable) in Main + throws LiterallyAnything ). 일반적인 오류처럼 누군가의 패닉을 쉽게 처리할 수 있습니다. 현재 내 현재 프로젝트에서 Go에 약 6백만 개 이상의 LoC가 있으며, 이것이 적어도 저에게는 일을 단순화할 것이라고 생각합니다.

@griesemer 토론을 요약해 주셔서 감사합니다.

나는 거기에 한 가지 요점이 빠졌다는 것을 알아차렸습니다. 어떤 사람들은 우리가 제네릭을 가질 때까지 이 기능을 기다려야 한다고 주장했습니다. 그러면 이 문제를 보다 우아한 방식으로 해결할 수 있기를 바랍니다.

또한 @velovix 의 제안도 마음에 들고 사양에 설명된 대로 몇 가지 질문이 제기된다는 점에 감사하지만 @velovix 가 이미 한 것처럼 합리적인 방식으로 쉽게 답변할 수 있다고 생각합니다.

예를 들어:

• 함수 값(nil 리터럴이 아님)을 제공하고 해당 함수 값(변수에 저장됨)이 nil이면 어떻게 됩니까? => 오류 처리하지 마세요, 마침표. 이는 오류 처리가 컨텍스트에 의존하고 오류 처리가 필요한지 여부에 따라 핸들러 변수가 설정된 경우에 유용합니다. 버그가 아니라 기능입니다. :)

• 또 다른 주장은 함수가 오류를 처리한다는 것을 매우 명확하게 하기 때문에 오류 처리기의 최상위 선언을 갖는 것이 더 낫다는 것입니다. => 따라서 함수의 상단에 있는 에러 핸들러를 명명된 클로저 함수로 정의하고 그것을 사용하면 에러를 처리해야 하는 것도 매우 명확해집니다. 이것은 심각한 문제가 아니라 스타일 요구 사항입니다.

또 어떤 고민이 있었나요? 나는 그들이 합리적인 방식으로 모두 비슷하게 대답할 수 있다고 확신합니다.

마지막으로, 당신이 말했듯이 "거래를 부드럽게 하는 한 가지 방법은 명시적(비어 있을 수 있는) 핸들러가 어딘가에 제공되는 경우에만 try(또는 유사한 단축키 표기법)와 같은 것을 허용하는 것입니다." 우리가 이 제안을 계속 진행하려면 실제로 "여기까지" 받아들여야 하고 "명시적인 것이 암시적인 것보다 낫다"는 적절한 오류 처리를 장려해야 한다고 생각합니다.

@griesemer

이제 함수 값(nil 리터럴이 아님)을 제공하고 해당 함수 값(변수에 저장된)이 nil이면 어떻게 될까요? 명시적 nil 값과 유사하게 처리가 필요하지 않습니다. 그러나 다른 사람들은 이것이 코드의 버그라고 주장할 수 있습니다.

이론적으로 이것은 잠재적인 문제처럼 보이지만 핸들러가 우연히 0이 되는 합리적인 상황을 개념화하는 데 어려움을 겪고 있습니다. 핸들러는 다른 곳에서 정의된 유틸리티 함수나 함수 자체에 정의된 클로저에서 가장 일반적으로 올 것이라고 생각합니다. 이들 중 어느 것도 예기치 않게 0이 될 가능성이 없습니다. 이론적으로 핸들러 함수가 다른 함수에 대한 인수로 전달되는 시나리오가 있을 수 있지만 내 눈에는 다소 무리한 것처럼 보입니다. 내가 모르는 이런 패턴이 있을지도 모르겠다.

또 다른 주장은 함수가 오류를 처리한다는 것을 매우 명확하게 하기 때문에 오류 처리기의 최상위 선언을 갖는 것이 더 낫다는 것입니다. 따라서 defer .

@beoran이 언급했듯이 핸들러를 함수 상단 근처의 클로저로 정의하는 것은 스타일이 매우 유사하게 보일 것이며 개인적으로 사람들이 핸들러를 가장 일반적으로 사용하는 방식일 것으로 예상합니다. 오류를 처리하는 모든 함수가 defer 를 사용한다는 사실에 의해 얻은 명확성에 감사하지만 함수가 함수의 중간에 오류 처리 전략에서 피벗해야 할 때 명확하지 않을 수 있습니다. 그러면 두 개의 defer 가 표시되며 독자는 서로 어떻게 상호 작용할지 추론해야 합니다. 이것은 핸들러 인수가 더 명확하고 인체공학적일 것이라고 생각하는 상황이며 이것이 _상대적으로_ 일반적인 시나리오가 될 것이라고 생각합니다.

대괄호 없이 작동하게 할 수 있습니까?

예를 들면 다음과 같습니다.
a := try func(some)

@Cyberax - 위에서 이미 언급했듯이 게시하기 전에 디자인 문서를 주의 깊게 읽는 것이 매우 중요합니다. 이것은 트래픽이 많은 문제이기 때문에 많은 사람들이 구독했습니다.

문서는 연산자와 함수에 대해 자세히 설명합니다.

8월 버전보다 이게 더 마음에 듭니다.

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에 관해서는 8월 제안에는 이 문제가 없었고 대부분의 반대 제안에도 이 문제가 없었습니다.

특히 tryf 반대 제안(이 스레드에서 독립적으로 두 번 게시됨)이나 try(X, handlefn) 반대 제안(설계 반복의 일부임) 모두 이 문제가 없었습니다.

try 가 관련 컨텍스트로 오류를 꾸미는 것에서 벗어나 하나의 일반적인 기능별 오류 장식으로 사람들을 밀어낼 것이라고 주장하는 것은 어렵다고 생각합니다.

이러한 이유 때문에 이 문제를 해결할 가치가 있다고 생각하며 가능한 솔루션을 제안하고자 합니다.

1. 현재 defer 의 매개변수는 함수 또는 메소드 호출만 가능합니다. defer 가 함수 이름이나 함수 리터럴도 가질 수 있도록 허용합니다. 즉,

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

1. 패닉 또는 지연이 이러한 유형의 지연을 만나면 모든 매개변수에 대해 0 값을 전달하는 함수를 호출합니다.

2. try 에 둘 이상의 매개변수를 허용

3. try 가 새로운 유형의 defer를 만나면 첫 번째 매개변수를 제외한 모든 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"

@zeebo의 https://github.com/golang/go/issues/32437#issuecomment -499309304 코드는 다음과 같이 다시 작성할 수 있습니다.

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)...)
        }
}

fmt -스타일 형식 문자열을 핵심 언어로 가져오지 않고 모든 사람이 많이 찾는 tryf 를 무료로 제공합니다.

defer 는 인수로 함수 표현식을 허용하지 않기 때문에 이 기능은 이전 버전과 호환됩니다. 새로운 키워드를 소개하지 않습니다.
https://github.com/golang/proposal/blob/master/design/32437-try-builtin.md 에 설명된 변경 사항 외에 구현해야 하는 변경 사항은 다음과 같습니다.

1. 새로운 종류의 연기에 대해 파서에게 가르친다
2. 함수 내에서 호출 대신 매개변수로 함수가 있는 모든 지연도 동일한 서명을 갖는지 확인하도록 유형 검사기를 변경합니다.
3. try 에 전달된 매개변수가 defer 에 전달된 함수의 서명과 일치하는지 확인하도록 유형 검사기를 변경합니다.
4. 적절한 deferproc 호출을 생성하도록 백엔드(?)를 변경합니다.
5. try 의 구현을 변경하여 새로운 종류의 지연에 의해 지연된 호출을 만날 때 지연된 호출의 인수로 인수를 복사합니다.

check/handle 드래프트 디자인의 복잡성 이후에 이 훨씬 더 간단하고 실용적인 제안이 실현되는 것을 보고 기분 좋게 놀랐습니다.

분명히 많은 반발이 현재의 장황한 표현에 매우 만족하고 이를 완화하기 위한 제안을 별로 환영하지 않을 것입니다. 나머지 우리들에게 이 제안은 너무 많은 일을 하지 않고 try 인 경우 항상 되돌아갈 수 있는 기존 오류 처리 기술과 잘 일치하는 단순하고 Go-like의 스위트 스폿에 도달한다고 생각합니다.

몇 가지 특정 사항에 대해:

1. 제안에 대해 내가 싫어하는 유일한 점은 defer 가 사용될 때 명명된 오류 반환 매개변수가 필요하다는 것입니다. 나머지 언어가 작동하는 방식. 따라서 제안이 채택되면 이를 수용해야 한다고 생각합니다.

2. try 가 오류 값을 반환하지 않는 함수에 대한 테스트 패키지와 잘 작동하지 않는 것은 유감입니다. 이에 대한 내가 선호하는 솔루션은 nil이 아닌 오류가 발생했을 때 반환되기보다는 항상 패닉 상태가 되는 두 번째 내장 함수(아마도 ptry 또는 must )를 갖는 것입니다. 앞서 언급한 기능( main 포함)과 함께 사용됩니다. 이 아이디어는 제안서의 현재 반복에서 거부되었지만 '밀접한 요청'이라는 인상을 받았으며 따라서 재검토 대상이 될 수 있습니다.

3. 나는 사람들이 go try(f) 또는 defer try(f) 하는 일에 대해 머리를 숙이는 것이 어려울 것이라고 생각하며 따라서 그들을 완전히 금지하는 것이 가장 좋습니다.

4. go fmt 가 if 명령문을 한 줄로 다시 작성하지 않으면 기존 오류 처리 기술이 덜 장황해 보일 것이라고 생각하는 사람들의 의견에 동의합니다. 개인적으로, 나는 이것이 오류 처리와 관련이 있든 없든 _any_ 단일 명령문 if 에 허용된다는 간단한 규칙을 선호합니다. 사실 나는 선언이 허용되는 것과 같은 줄에 본문이 배치되는 단일 줄 함수를 작성할 때 이것이 현재 허용되지 않는 이유를 결코 이해할 수 없었습니다.

장식 오류의 경우

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

이것은 기존 패러다임보다 훨씬 더 장황하고 고통스럽게 느껴지며 검사/핸들만큼 간결하지 않습니다. 래핑되지 않은 try() 변형이 더 간결하지만 사람들이 try와 일반 오류 반환을 혼합하여 사용하게 될 것 같습니다. try와 간단한 오류 반환을 혼합하는 아이디어가 마음에 들지는 모르겠지만 오류를 꾸미는 데 완전히 매료되었습니다(Is/As를 기대합니다). 이것이 구문적으로 깔끔하지만 실제로 사용하고 싶은지 확신이 서지 않는다고 생각하게 만드십시오. check/handle은 내가 더 철저하게 수용할 무언가를 느꼈습니다.

나는 이것의 단순성과 "한 가지만 잘 하라"는 접근 방식을 정말 좋아합니다. 내 GoAWK 인터프리터에서는 매우 도움이 될 것입니다. 저는 약 100개의 if err != nil { return nil } 구조를 가지고 있으며, 이는 상당히 작은 코드베이스에 있습니다.

나는 그것을 키워드가 아닌 내장으로 만드는 것에 대한 제안의 정당성을 읽었고, 그것은 파서를 조정할 필요가 없다는 결론으로 ​​귀결됩니다. 그러나 컴파일러와 도구 작성자에게는 상대적으로 적은 양의 고통이 되지 않습니까? 반면에 추가 괄호와 this-look-like-a-function- but-is-in-in-readability 문제는 모든 Go 코더와 코드의 문제가 될 것입니다. 독자는 견뎌야 한다. 내 의견으로는 (변명? :-) "하지만 panic() 는 흐름을 제어합니다"는 그것을 자르지 않습니다. 왜냐하면 패닉과 회복은 본질적으로 예외적 인 반면 try() 는 정상적인 오류 처리 및 제어 흐름이어야 합니다.

이것이 그대로 들어가더라도 나는 확실히 감사할 것이지만, 내가 가장 선호하는 것은 일반적인 제어 흐름이 명확해지는 것, 즉 키워드를 통해 수행되는 것입니다.

저는 이 제안에 찬성합니다. 이전 제안에 대한 가장 큰 예약을 피합니다: defer 에 대한 handle 의 비직교성.

위에서 강조되지 않은 두 가지 측면을 언급하고 싶습니다.

첫째, 이 제안이 오류에 상황별 오류 텍스트를 추가하는 것을 쉽게 만들지는 않지만 스택 프레임 오류 추적 정보를 오류에 쉽게 추가할 수 있도록 합니다. 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 가 다양한 수의 매개변수를 사용하도록 허용할 수 있습니까?

• 시도(f):
  위와 같이.
  반환 오류 값은 필수입니다(마지막 반환 매개변수로).
  가장 일반적인 사용 모델
• 시도(f, doPanic 부울):
  위와 같지만 doPanic이면 반환하는 대신 패닉(err)합니다.
  이 모드에서는 반환 오류 값이 필요하지 않습니다.
• 시도(f, fn):
  위와 같지만 반환하기 전에 fn(err)을 호출합니다.
  이 모드에서는 반환 오류 값이 필요하지 않습니다.

이런 식으로 명시적이면서 모든 사용 사례를 처리할 수 있는 하나의 내장 기능입니다. 장점:

• 항상 명시적 - 패닉 또는 설정 오류 여부를 유추할 필요가 없습니다.
• 컨텍스트별 핸들러 지원(하지만 핸들러 체인 없음)
• 오류 반환 변수가 없는 사용 사례 지원
• 필수(...) 의미 체계를 지원합니다.

반복적인 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은 다른 반환 값의 0 값입니다.

이 제안은 명명된 반환 값의 필요성을 제거할 수 있으며,
제 생각에는 더 이해하기 쉽고 읽기 쉽습니다.

더 나은 방법은 다음과 같습니다.

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

또는

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

이 마지막 항목은 이전 버전과 호환됩니다(현재 식별자에는 ?가 허용되지 않음).

(이 제안은 https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback#recurring-themes 와 관련이 있습니다. 그러나 반복되는 테마 예제는 떠나지 않고 명시적 핸들이 여전히 논의되는 단계였기 때문에 다르게 보입니다. 연기하는 것입니다.)

이 신중하고 흥미로운 제안을 해주신 go 팀에 감사드립니다.

@rogpeppe comment if try 내가 아닌 스택 프레임을 자동으로 추가하면 컨텍스트를 추가하지 않는 것이 좋습니다.

@aarzilli - 귀하의 제안에 따르면 tryf 에 추가 매개변수를 제공할 때마다 defer 절이 필수입니까?

내가 하면 어떻게 됩니까

try(ioutil.WriteFile(target, buf, 0644), "write file %s", target)

지연 기능을 작성하지 않습니까?

@agnivade

내가 하고(...) defer 함수를 작성하지 않으면 어떻게 됩니까?

유형 검사 오류.

제 생각에는 모든 반환 값을 쓰지 않기 위해 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) 가 되어 훨씬 더 잘 읽힙니다.

그건 제쳐두고, try(err) 쓰는 것이 정말 남용인지 모르겠습니다. 깔끔하게 정의를 벗어났습니다. 그러나 다른 한편으로는 이것이 합법적이라는 의미이기도 합니다.

a, b := try(1, f(), err)

try 에 대한 내 주요 문제는 실제로 한 단계만 올라가는 panic 라는 것입니다. 단, 패닉과 달리 문이 아니라 표현이므로 숨길 수 있습니다. 그것은 어딘가에 진술의 중간에 있습니다. 그것은 거의 공황 상태보다 더 악화 됩니다.

@natefinch 한 단계 올라가서 다른 일을 하는 패닉처럼 개념화하면 꽤 지저분해 보입니다. 그러나 나는 그것을 다르게 개념화한다. Go에서 오류를 반환하는 함수는 결과를 효과적으로 반환합니다., Rust의 용어를 느슨하게 차용합니다. try 는 결과의 압축을 풀고 error != nil 이면 "오류 결과"를 반환하거나 error == nil 이면 결과의 T 부분 압축을 푸는 유틸리티입니다.

물론 Go에는 실제로 결과 개체가 없지만 사실상 동일한 패턴이고 try 는 해당 패턴의 자연스러운 코드화처럼 보입니다. 나는 이 문제에 대한 모든 해결책이 오류 처리의 일부 측면을 성문화해야 하고 try 가 이를 받아들이는 것이 합리적이라고 생각합니다. 나와 다른 사람들은 기존 Go 오류 처리 패턴에 더 잘 맞도록 try 의 기능을 약간 확장할 것을 제안하지만 기본 개념은 동일하게 유지됩니다.

@ugorji 당신이 제안한 try(f, bool) 변종은 #32219의 must 처럼 들립니다.

@ugorji 당신이 제안한 try(f, bool) 변종은 #32219의 must 처럼 들립니다.

예, 그렇습니다. 3가지 경우 모두 단일 내장 함수로 처리할 수 있고 모든 사용 사례를 우아하게 만족시킬 수 있다고 느꼈습니다.

try() 는 이미 마술적이고 오류 반환 값을 알고 있기 때문에 nullary(인수 없음) 형식으로 호출될 때 해당 값에 대한 포인터도 반환하도록 확장될 수 있습니까? 그러면 명명된 반환이 필요하지 않으며 defer 문에서 오류가 발생할 것으로 예상되는 위치를 시각적으로 연관시키는 데 도움이 된다고 생각합니다. 예를 들어:

func foo() error {
  defer fmt.HandleErrorf(try(), "important foo context info")
  try(bar())
  try(baz())
  try(etc())
}

@ugorji
try(f, bool) 에 부울을 지정하면 읽기 어렵고 놓치기 쉽습니다. 나는 당신의 제안을 좋아하지만 패닉의 경우 사용자가 세 번째 글머리 기호(예: try(f(), func(err error) { panic('at the disco'); }) )에서 핸들러 내부에 작성하는 것을 생략할 수 있다고 생각합니다. 이렇게 하면 숨겨진 try(f(), true) 보다 사용자에게 더 명확해집니다.

@ugorji
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에서 nil 테스트를 트리거하는 _assignment syntax_의 또 다른 지지자입니다.

이 개념은 확인/처리 제안에 대한 13개의 개별 응답에 나타납니다.
https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback#recurring -themes

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 -design

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()는 이미 마술적이고 오류 반환 값을 알고 있으므로 nullary(인수 0) 형식으로 호출될 때 해당 값에 대한 포인터도 반환하도록 확장될 수 있습니까? 그러면 명명된 반환이 필요하지 않습니다.

그러나 인수의 수를 기반으로 try 라는 이름을 오버로드하는 대신 $ reterr 같은 또 다른 마법 내장이 있을 수 있다고 생각합니다.

나는 자주 사용되는 패키지에 대해 브리핑을 하며 오류 처리로 "고통을 받는" go 코드를 찾았지만 제안된 try()가 수행할 "마법"이 무엇인지 알아내려 했습니다.
현재, 내가 제안을 잘못 이해하지 않는 한, 그 중 많은 것(예: 기본 오류 처리가 아님)은 많은 것을 얻지 못하거나 "오래된" 오류 처리 스타일을 유지해야 합니다.
net/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 *프로필, *aggTest) 오류 {
// 행에 대한 총 샘플 수가 보존되었는지 확인합니다.
총계 := 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() 를 사용하여 이것이 어떻게 개선되는지 보여줄 수 있습니까?

저는 이 제안에 대부분 찬성합니다.

많은 주석가들과 공유하는 나의 주요 관심사는 명명된 결과 매개변수에 관한 것입니다. 현재 제안은 명명된 결과 매개변수를 훨씬 더 많이 사용하도록 권장하며 이는 실수라고 생각합니다. 나는 이것이 제안서에 명시된 것처럼 단순히 스타일의 문제라고 생각하지 않습니다. 명명된 결과는 많은 경우에 코드를 버그가 발생하기 쉽거나 덜 명확하게 만드는 언어의 미묘한 기능입니다. Go 코드를 읽고 작성한 지 약 8년 후, 저는 두 가지 목적으로만 명명된 결과 매개변수만을 사용합니다.

• 결과 매개변수 문서화
• defer 내에서 결과 값 조작(일반적으로 error )

새로운 방향에서 이 문제를 공격하기 위해 디자인 문서 또는 이 문제 주석 스레드에서 논의된 것과 밀접하게 일치하지 않는다고 생각하는 아이디어가 있습니다. "오류 지연"이라고 합시다.

암시적 오류 매개변수가 있는 함수를 호출하는 데 defer를 사용할 수 있습니다.

따라서 기능이 있는 경우

func f(err error, t1 T1, t2 T2, ..., tn Tn) error

그런 다음 마지막 결과 매개변수가 error 유형인 $#$2 g #$ 함수(즉, try 가 사용되는 모든 함수)에서 $ f 에 대한 호출 다음과 같이 연기될 수 있습니다.

func g() (R0, R0, ..., error) {
    defer f(t0, t1, ..., tn) // err is implicit
}

error-defer의 의미는 다음과 같습니다.

1. f 에 대한 지연된 호출은 f 의 첫 번째 입력 매개변수로 g 의 마지막 결과 매개변수로 호출됩니다.
2. f 는 해당 오류가 nil이 아닌 경우에만 호출됩니다.
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 와 error-defer 사이에는 일정한 대칭이 있습니다.

마지막으로 error-defers는 오류 반환을 조작하기 위해 명명된 결과 매개변수의 사용을 대체하기 때문에 오늘날에도 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)
                }
            }
        }
    }()

    // ...
}

error-defer를 사용하면 다음과 같이 됩니다.

// 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 의 2-argument try 의 기본 동작에 대한 귀하의 제안과 관련하여: 전에 말했듯이 분명히 합리적인 선택이 무엇인지에 대한 귀하의 아이디어는 다른 사람의 악몽입니다.

명시적 오류 처리기가 있는 try 가 현재 최소 try 보다 더 나은 아이디어라는 폭넓은 합의가 이루어지면 이 토론을 계속할 것을 제안합니다. 그 시점에서 그러한 디자인의 좋은 점을 논의하는 것이 합리적입니다.

(그 문제에 관해서는 핸들러가 있는 것을 좋아합니다. 그것은 우리의 초기 제안 중 하나입니다. 그리고 우리가 try 를 그대로 채택하더라도 여전히 핸들러가 있는 try 로 이동할 수 있습니다. -compatible way - 적어도 핸들러가 선택 사항이라면 한 번에 한 단계씩 가자.)

@aarzilli 제안 해 주셔서 감사합니다.

장식 오류가 선택 사항인 한 사람들은 그것을 하지 않는 쪽으로 기울게 될 것입니다(결국 추가 작업입니다). 여기에서 내 의견도 참조하십시오.

그래서, 나는 제안된 try 사람들이 장식 오류를 _discourages_한다고 생각하지 않습니다(위의 이유로 if 를 사용하더라도 이미 낙담하고 있습니다). try 는 _장려하지_ 않습니다.

(이를 장려하는 한 가지 방법은 try 에 묶는 것입니다. 오류를 장식하거나 명시적으로 옵트아웃하는 경우에만 try 를 사용할 수 있습니다.)

그러나 귀하의 제안으로 돌아가서: 귀하가 여기에 훨씬 더 많은 기계를 도입하고 있다고 생각합니다. try 에 대해 더 잘 작동하도록 defer 의 의미를 변경하는 것은 이러한 defer 변경이 보다 일반적인 방식으로 도움이 되지 않는 한 고려하고 싶지 않은 사항입니다. 또한 귀하의 제안은 defer 와 try 를 연결하므로 두 메커니즘 모두 직교성이 떨어집니다. 우리가 피하고 싶은 것.

그러나 더 중요한 것은 모든 사람이 try 를 사용할 수 있도록 defer 을 쓰도록 강요하고 싶지 않다는 것입니다. 하지만 그렇게 하지 않으면 다시 원점으로 돌아갑니다. 사람들은 오류를 꾸미지 않는 쪽으로 기울게 될 것입니다.

(저는 그 문제에 대해 핸들러가 있는 것을 좋아합니다. 그것은 우리의 이전 제안 중 하나입니다. 그리고 우리가 try 그대로를 채택한다면, 우리는 여전히 앞으로 호환 가능한 방식으로 핸들러를 사용하여 try로 이동할 수 있습니다. 적어도 핸들러가 다음과 같을 경우 선택사항입니다. 하지만 한 번에 한 단계씩 이동해 보겠습니다.)

물론, 아마도 다단계 접근 방식이 갈 길일 것입니다. 향후에 선택적 처리기 인수를 추가하면 errcheck 도구와 동일한 정신으로 처리되지 않은 try 작성자에게 경고하는 도구가 생성될 수 있습니다. 그럼에도 불구하고 귀하의 피드백에 감사드립니다!

@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 vs try 주제에 대한 디자인 문서도 읽으십시오. try 는 최대한 단순하게 유지하는 것이 좋습니다. must 는 초기화 표현식의 일반적인 "패턴"이지만 이를 "수정"할 긴급한 필요는 없습니다.

@jargv 제안 해 주셔서 감사합니다. 이것은 흥미로운 아이디어입니다(이 주제에 대한 내 의견도 참조 하십시오 ). 요약:

• try(x) 는 제안된 대로 작동합니다.
• try() 는 오류 결과를 가리키는 *error $를 반환합니다.

이것은 실제로 이름을 지정하지 않고도 결과를 얻는 또 다른 방법이 될 것입니다.

@cespare @jargv 의 제안 은 당신이 제안하는 것보다 훨씬 간단해 보입니다. 결과 오류에 대한 동일한 액세스 문제를 해결합니다. 어떻게 생각해?

https://github.com/golang/go/issues/32437#issuecomment -499320588에 따라:

func doPanic(err 오류) 오류 { 패닉(err) }

나는 이 기능이 꽤 일반적일 것이라고 예상한다. 이것은 "builtin"(또는 errors 과 같은 표준 패키지의 다른 곳)에서 미리 정의될 수 있습니까?

구현하기에 충분히 강력한 제네릭을 기대하지 않는 것은 너무 나쁩니다.
실제로 그렇게 할 수 있기를 바랐을 것입니다.

예, 이 제안은 첫 번째 단계가 될 수 있습니다.
지금의 나 자신.

물론, 이 문제는 세부적인 대안에 너무 많은 초점을 맞춘 것 같습니다.
그러나 많은 참가자들이 완전히 만족하지 않는다는 것을 보여줍니다.
그것. 이 제안에 대한 폭넓은 공감대가 부족한 것 같습니다...

Op vr 7 jun. 2019 01:04 슈리프 피제이 알림 @github.com :

아스퍼 #32437 (댓글)
https://github.com/golang/go/issues/32437#issuecomment-499320588 :

func doPanic(err 오류) 오류 { 패닉(err) }

나는 이 기능이 꽤 일반적일 것이라고 예상한다. 이것은 미리 정의 될 수 있습니까?
"빌트인"에서?

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/golang/go/issues/32437?email_source=notifications&email_token=AAARM6OOOLLYO5ZCE6VVL2TPZGJWRA5CNFSM4HTGCZ72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LDNMVXH
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AAARM6K5AOR2DES4QDTNLSTPZGJWRANCNFSM4HTGCZ7Q
.

@pjebs , 동등한 기능을 수십 번 작성했습니다. 나는 보통 그것을 "orDie" 또는 "check"라고 부릅니다. 너무 간단하여 표준 라이브러리의 일부로 만들 필요가 없습니다. 또한 다른 사람들은 종료 전에 로깅 또는 무엇이든 원할 수 있습니다.

@beoran 아마도 제네릭과 오류 처리 간의 연결을 확장할 수 있습니다. 생각해보면 둘은 다른 것 같아요. 제네릭은 언어의 모든 문제를 해결할 수 있는 캐치 올이 아닙니다. 여러 유형에서 작동할 수 있는 단일 함수를 작성하는 기능입니다.

이 특정 오류 처리 제안은 일부 상황에서 흐름 제어를 변경하는 미리 선언된 함수 try 를 도입하여 상용구를 줄이려고 합니다. 제네릭은 제어 흐름을 변경하지 않습니다. 그래서 관계가 정말 안 보인다.

함수 내에서 오류가 발생하기 쉬운 여러 호출을 처리하면 defer 오류 핸들이 혼란스러울 것이라고 상상했기 때문에 이에 대한 나의 초기 반응은 👎였습니다. 전체 제안서를 읽은 후 상대적으로 낮은 복잡성으로 여전히 달성 할 수 있다는 것을 배웠기 때문에 ❤️ 및 👍에 대한 반응을 뒤집었습니다.

@carlmjohnson 네 간단하지만...

나는 동등한 기능을 수십 번 작성했습니다.

미리 선언된 함수의 장점은 다음과 같습니다.

1. 우리는 그것을 한 줄로 할 수 있습니다
2. 우리가 사용하는 모든 패키지에서 err => 패닉 기능을 다시 선언하거나 공통 위치를 유지할 필요가 없습니다. Go 커뮤니티의 모든 사람에게 공통적이므로 "표준 패키지" 는 _ 공통 위치입니다.

@griesemer 원래 try 제안의 오류 처리기 변형을 사용하면 오류를 반환하기 위한 가장 중요한 함수의 요구 사항이 더 이상 필요하지 않습니다.

내가 처음에 그것에 대해 물었을 때 err => 공황, 나는 그 제안이 그것을 고려했지만 그것이 너무 위험하다고 (합당한 이유로) 고려된다는 지적을 받았습니다. 그러나 가장 중요한 함수가 오류를 반환하지 않는 시나리오에서 오류 처리기 없이 try() 를 사용하면 이를 컴파일 시간 오류로 만들면 제안에서 논의된 문제가 완화됩니다.

@pjebs 오류를 반환하기 위한 가장 중요한 함수의 요구 사항은 원래 디자인에서 필요하지 않은 오류 핸들러가 제공된 _if_입니다. 그러나 이것은 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 의 명백하고 직접적인 특성에 과부하가 걸리는 것을 선호하는 것은 놀라운 일입니다. 내가 defer closeFile(f) 라고 쓰면 무슨 일이 일어나고 왜 그런지 간단하고 분명합니다. 호출될 함수의 끝에서. panic() 및 recover() 에 $ defer #$를 사용하는 것은 덜 명확하지만, 저는 거의 사용하지 않으며 다른 사람의 코드를 읽을 때 거의 보지 않습니다.

오류도 처리하기 위해 defer 를 오버로드하는 스푸는 명확하지 않고 혼란스럽습니다. 왜 키워드 defer 입니까? defer 는 _"나중에 할 수 있음"이 아니라 _"나중에 할 것"_을 의미하지 않습니까?

또한 Go 팀이 defer 성능 에 대해 언급한 우려가 있습니다. 이를 감안할 때 defer 가 _"hot path"_ 코드 흐름에 대해 고려되고 있다는 것은 두 배로 불행한 것 같습니다.

중요한 사용 사례를 확인하는 통계 없음

@prologic 이 언급했듯이 이 try() 제안은 이 사용 사례를 사용할 코드의 많은 부분에 근거한 것입니까, 아니면 Go 오류 처리에 대해 불평하는 사람들을 달래기 위한 시도에 기반한 것입니까?

모든 파일을 철저히 검토하고 메모하지 않고 내 코드 기반에서 통계를 제공하는 방법을 알고 싶습니다. @prologic 이 기뻐하면서도 어떻게 할 수 있었는지 모르겠습니다.

그러나 일화에 따르면 try() 가 내 사용 사례의 5%를 처리하고 1% 미만을 처리할 것이라고 의심하면 놀랄 것입니다. 다른 사람들은 매우 다른 결과를 얻는다는 것을 확실히 알고 있습니까? 표준 라이브러리의 하위 집합을 가져 와서 어떻게 적용할지 확인하려고 했습니까?

이것이 야생의 많은 코드에 적합하다는 알려진 통계가 없기 때문에 모든 사람이 새로운 개념을 배워야 하는 언어에 대한 이 복잡하고 새로운 변경이 실제로 매력적인 수의 사용 사례를 해결해야 합니까?

개발자가 오류를 쉽게 무시할 수 있도록 합니다.

이것은 다른 사람들의 의견을 완전히 반복한 것이지만 기본적으로 try() 를 제공하는 것은 다음을 단순히 idomatic 코드로 수용하는 것과 여러 면에서 유사하며 이것은 어떤 코드에도 절대 들어가지 않는 코드입니다. -개발자 배송 존중:

f, _ := os.Open(filename)

나는 내 자신의 코드를 더 잘 할 수 있다는 것을 알고 있지만, 우리 중 많은 사람들이 엄청나게 유용한 패키지를 게시하는 다른 Go 개발자들에게 의존하고 있다는 것도 압니다. 그러나 _"Other People's Code(tm)"_ 오류 처리의 모범 사례는 종종 무시됩니다.

정말 진지하게, 개발자가 오류를 더 쉽게 무시하고 GitHub를 견고하지 않은 패키지로 더럽힐 수 있도록 하고 싶습니까?

(대부분) 이미 userland에서 try() 를 구현할 수 있습니다.

내가 제안을 오해하지 않는 한 - 아마도 그럴 것입니다 - 여기에 try() 가 userland 에서 구현된 Go Playground 가 있습니다 . 비록 하나의 반환 값과 예상 유형 대신 인터페이스를 반환하지만:

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는 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 를 호출합니까? 역순으로 또는 일반 순서로?

아니면 클로저와 오류가 반환된 func 모두에서 반환됩니까? _(여기에서 그것을 의미하는 단어를 읽지 않았다면 결코 고려하지 않았을 것입니다.)_

제안서와 지금까지의 모든 의견을 읽은 후에도 솔직히 위의 질문에 대한 답변을 모르겠습니다. 이것이 우리가 _"Captain Obvious"_를 옹호하는 언어에 추가하고 싶은 기능입니까?

통제력 부족

defer 를 사용하면 개발자가 _(가장 최근에?)_ defer 로 분기하는 것만으로도 개발자가 제어할 수 있는 것으로 보입니다. 그러나 사소한 func 이외의 방법에 대한 제 경험에 따르면 일반적으로 그보다 더 복잡합니다.

종종 func 내에서 또는 package 내에서 오류 처리 측면을 공유하는 것이 도움이 되지만 하나 이상의 다른 패키지에서 더 구체적인 처리를 공유하는 것이 도움이 된다는 것을 알게 되었습니다.

예를 들어, 다른 func 내에서 error() func 호출 5개를 호출할 수 있습니다. A() , B() , C() , D() 및 E() 레이블을 지정하겠습니다. 자체 오류 처리를 사용하려면 C() , 오류 처리를 공유하려면 A() , B() , D() , E() 가 필요할 수 있습니다. 및 B() 및 E() 를 사용하여 특정 처리를 수행합니다.

그러나 나는 이 제안으로 그렇게 할 수 있다고 믿지 않습니다. 적어도 쉽지는 않습니다.

그러나 아이러니하게도 Go에는 작은 사용 사례 집합으로 제한될 필요가 없는 높은 수준의 유연성을 허용하는 언어 기능이 이미 있습니다. func 및 폐쇄. 제 수사학적 질문은 다음과 같습니다.

_ "왜 우리는 이러한 사용 사례를 다루기 위해 기존 언어에 약간의 개선 사항을 추가할 수 없고 새로운 내장 기능을 추가하거나 혼란스러운 의미 체계를 받아들일 필요가 없습니까?" _

내가 이 제안을 연구하는 동안 생각한 대안으로 제안을 제출할 계획이기 때문에 수사학적 질문입니다.

그러나 나는 여담입니다. 그것은 나중에 올 것이며 이 의견은 현재 제안을 재고해야 하는 이유에 대한 것입니다.

break 에 대한 명시적 지원 부족

이것은 대부분의 사람들이 오류 처리를 위해 조기 반환을 사용하기 때문에 왼쪽 필드에서 나오는 것처럼 느껴질 수 있지만 $# 이전에 함수의 대부분 또는 전체를 래핑하는 오류 처리를 위해 break 를 사용하는 것이 더 낫다는 것을 알았습니다 return .

나는 잠시 동안 이 접근 방식을 사용해 왔으며 리팩토링을 완화하는 것만으로도 초기 return 보다 선호되지만 단일 종료 지점 및 함수의 섹션을 조기에 종료할 수 있는 기능을 포함하여 몇 가지 다른 이점이 있지만 여전히 정리를 실행할 수 있음 _(아마도 내가 defer 를 거의 사용하지 않는 이유일 것입니다. 프로그램 흐름 측면에서 추론하기가 더 어렵습니다.)_

조기 반환 대신 break 를 사용하려면 for range "1" {...} 루프를 사용하여 _(실제로는 상수만 포함하는 only 라는 패키지를 생성합니다. Once #$6$#$ 값으로 "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 를 가정하고 오류 처리를 위해 break 를 사용하는 것을 무시하는 오류 처리를 구현해야 한다는 것입니다.

내 의견 err == nil 에 문제가 있습니다.

더 나아가 Go의 관용적 오류 처리에 대해 느꼈던 우려를 제기하고 싶습니다. 저는 오류가 발생할 때 오류를 처리하는 것과 예외 처리를 사용하는 것에 대한 Go의 철학을 크게 신봉하지만 오류가 없음을 나타내기 위해 nil 를 사용하는 것이 문제가 된다고 생각합니다. 루틴 — API 응답에 사용 — 오류가 있을 때만 nil이 아닌 값을 반환하는 것은 아닙니다 .

그래서 Go 2의 경우 Go가 status 의 새로운 내장 유형과 세 개의 내장 함수 iserror() , iswarning() , issuccess() 를 추가하는 것을 고려하고 싶습니다. status 는 error 를 구현할 수 있습니다. — 많은 역호환성을 허용하고 issuccess() 에 전달된 nil 값은 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 팀의 주요 응답 중 하나는 _"다시 말하지만, 이 제안은 모든 오류 처리 상황을 해결하려는 시도는 아닙니다."입니다.
그리고 그것은 아마도 거버넌스 관점에서 가장 골치 아픈 문제일 것입니다.

모든 사람이 새로운 개념을 배워야 하는 이 복잡하고 복잡한 언어 변경이 정말 많은 사용 사례를 해결합니까?

그리고 핵심 팀의 동일한 정당 구성원이 커뮤니티의 수많은 기능 요청을 거부한 것이 아닙니까? 다음은 약 2년 전에 제출된 기능 요청에 대한 전형적인 응답에서 Go 팀 구성원이 한 의견에서 직접 인용한 것입니다. 사람들이 아니라 언어에 대해):_

_"새로운 언어 기능에는 강력한 사용 사례가 필요합니다. 모든 언어 기능이 유용하거나 아무도 제안하지 않습니다. 문제는 언어를 복잡하게 만들고 모든 사람이 새로운 개념을 배우도록 요구하는 것을 정당화할 만큼 유용합니까? 설득력 있는 사용은 무엇입니까? 예를 들어, 사람들은 이것을 어떻게 사용할까요? 예를 들어, 사람들은 ... 그리고 그렇다면 어떻게 하시겠습니까? 이 제안은 ... 이상의 기능을 합니까?"_
— Go 핵심 팀원

솔직히 그 반응을 보았을 때 나는 두 가지 감정 중 하나를 느꼈습니다.

1. 내가 동의하는 기능이라면 분개하거나
2. 내가 동의하지 않는 기능이라면 의기양양합니다.

그러나 두 경우 모두 내 감정은 관련이 없습니다. 나는 바둑이 우리 중 많은 사람들이 개발하기로 선택한 언어의 일부가 언어의 순수성을 질투하게 보호하기 때문이라는 것을 이해하고 동의합니다.

그리고 이것이 바로 이 제안이 저를 힘들게 하는 이유입니다. Go 핵심 팀은 이 제안을 Go 커뮤니티에서 절대 용납할 수 없는 난해한 기능을 독단적으로 원하는 사람과 같은 수준으로 이 제안을 파고 있는 것처럼 보이기 때문입니다.

_(그리고 나는 팀이 메신저를 쏘지 않고 바둑이 계속해서 최고가 되기를 바라는 누군가의 건설적인 비판으로 받아들이기를 진심으로 바랍니다. 핵심 팀.)_

설득력 있는 실제 사용 사례 집합을 요구하는 것이 모든 커뮤니티 생성 기능 제안에 대한 기준이라면 _ 모든 _ 기능 제안에 대해서도 동일한 기준이 되어야 하지 않을까요?

try() 중첩

이것 역시 몇몇에 의해 다루어졌지만, 나는 try() 와 삼항 연산자에 대한 계속되는 요청을 비교하고 싶습니다. 약 18개월 전 다른 바둑 팀원의 말 인용:

_""대규모 프로그래밍"(오랜 기간에 걸쳐 대규모 팀이 있는 대규모 코드 기반)인 경우 코드는 작성된 것보다 훨씬 더 자주 읽히므로 쓰기 가능성이 아닌 가독성을 위해 최적화합니다."_

삼항 연산자를 추가하지 않는 _primary_ 언급된 이유 중 하나는 중첩될 때 읽기 어렵거나 잘못 읽기 쉽다는 것입니다. 그러나 try(try(try(to()).parse().this)).easily()) 와 같은 중첩된 try() 문의 경우에도 마찬가지입니다.

삼항 연산자 에 반대하는 또 다른 이유는 중첩된 표현식이 복잡성을 추가할 수 있다는 주장이 있는 _"표현식"_이라는 것입니다. 그러나 try() 도 중첩 가능한 표현식을 생성하지 않습니까?

이제 여기 누군가가 _"내 생각에 [중첩된 try() s]와 같은 예는 비현실적이라고 생각합니다."_ 그 진술은 이의를 제기하지 않았습니다.

그러나 사람들이 개발자가 try() 를 중첩하지 않을 것이라는 가정을 받아들인다면 사람들이 _"깊게 중첩된 삼항 연산자는 비현실적이라고 생각합니다."_라고 말할 때 삼항 연산자에 대해 동일한 존중이 주어지지 않는 이유는 무엇입니까?

이 점에 대한 결론은 삼항 연산자 에 대한 주장이 실제로 유효하다면 이 try() 제안에 대한 유효한 주장으로도 간주되어야 한다고 생각합니다.

요약하자면

이 글을 쓰는 시점에서 58% 반대 투표는 42% 찬성 투표입니다. 나는 이것만으로도 이 문제에 대해 다시 논의해야 할 시점이라는 제안이 충분히 분열적임을 나타내기에 충분해야 한다고 생각합니다.

fwiw

추신: 좀 더 농담으로 표현하자면 Yoda의 지혜를 의역해야 한다고 생각합니다.

_" try() 이(가) 없습니다. do() 있습니다."_

@ianlancetaylor

@beoran 아마도 제네릭과 오류 처리 간의 연결을 확장할 수 있습니다.

@beoran 에 대해 말하는 것이 아니라 몇 분 전 제 의견에서 제네릭 _(가변 반환 매개변수 포함)_이 있다면 우리 고유의 try() 를 빌드할 수 있음을 알 수 있습니다.

그러나 — 그리고 저는 제네릭에 대해 위에서 말한 것을 더 쉽게 볼 수 있도록 여기에서 반복할 것입니다.

_" 제네릭의 유스 케이스는 Java 등의 혼란스러운 의미 체계와 제네릭 구문 샐러드를 추가하기보다는 제네릭의 유스 케이스를 해결하기 위해 내장을 추가하여 축소되어야 한다고 생각합니다.)"_

@ianlancetaylor

귀하의 질문에 대한 답변을 공식화하려고 할 때 Go에서 try 기능을 있는 그대로 구현하려고 시도했으며 기쁘게도 실제로 이미 매우 유사한 것을 에뮬레이트하는 것이 가능합니다.

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. 반환된 emtpy 인터페이스 결과를 assert를 입력해야 합니다.

충분히 강력한 제네릭은 문제 2와 3을 해결할 수 있으며 super() 를 추가하여 해결할 수 있는 1개만 남깁니다. 이 두 가지 기능을 사용하면 다음과 같은 결과를 얻을 수 있습니다.

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 호출 사이에서 일부 오류를 처리할 수도 있습니다.

요약:
a) go 및 defer $에 대해 $ try 를 허용하지 않는 문제는 구문 덕분에 사라집니다.
b) 여러 기능의 오류 처리를 제외할 수 있습니다.
c) 그것의 마법 같은 성질은 함수 호출보다 특별한 구문으로 더 잘 표현됩니다.

try가 컨텍스트라면 우리는 특별히 피하려고 하는 try/catch 블록을 만든 것입니다.

캐치가 없습니다. 현재 제안서가 있을 때와 똑같은 코드가 생성됩니다.
x = try(foo(...)) y = try(bar(...))
이것은 의미가 아닌 다른 구문입니다.
````

아직 몇 가지 단점이 있기는 하지만 하지 말았어야 하는 몇 가지 가정을 했던 것 같습니다.

foo 또는 bar가 오류를 반환하지 않으면 try 컨텍스트에도 배치될 수 있습니까? 그렇지 않다면 오류 기능과 오류가 아닌 기능 사이를 전환하는 것이 다소 추한 것처럼 보입니다. 가능하다면 이전 언어의 try 블록 문제로 되돌아갑니다.

두 번째는 일반적으로 keyword ( ... ) 구문에서 각 줄에 키워드 접두사를 붙인다는 의미입니다. 따라서 import, var, const 등의 경우: 각 행은 키워드로 시작합니다. 그 규칙에 대한 예외를 만드는 것은 좋은 결정처럼 보이지 않습니다

함수를 사용하는 대신 특수 식별자를 사용하는 것이 더 관용적입니까?

값을 무시하는 빈 식별자 _ 가 이미 있습니다.
우리는 # 와 같은 것을 가질 수 있습니다. 이것은 error 유형의 마지막 반환 값이 있는 함수에서만 사용할 수 있습니다.

func foo() (error) {
    f, # := os.Open()
    defer f.Close()
    _, # = f.WriteString("foo")
    return nil
}

# 에 오류가 할당되면 함수는 수신된 오류와 함께 즉시 반환됩니다. 다른 변수의 경우 값은 다음과 같습니다.

• 이름이 0 값이 아닌 경우
• 그렇지 않으면 명명된 변수에 할당된 값

@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

try() 와 동일한 사용 사례를 처리하기 위해 2개의 작지만 범용 언어 기능을 추가해야 합니다.

1. 할당문에서 func /closure를 호출하는 기능.
2. break , continue 또는 return 이상의 레벨을 사용할 수 있습니다.

이 두 가지 기능을 사용하면 _"마술"이 되지 않으며, 이 기능을 사용하면 이해하기 쉽고 우리 모두에게 친숙한 관용적 Go 코드와 더 일치하는 Go 코드가 생성될 것이라고 믿습니다.

나는 제안을 읽었고 시도가 어디로 가고 있는지 정말 좋아합니다.

시도가 얼마나 널리 퍼질 것인지를 감안할 때 더 기본 동작으로 만드는 것이 더 쉽게 처리할 수 있는지 궁금합니다.

지도를 고려하십시오. 이것은 유효합니다:

v := m[key]

그대로:

v, ok := m[key]

try가 제안한 대로 정확하게 오류를 처리하지만 내장을 제거하면 어떻게 될까요? 따라서 다음과 같이 시작하면:

v, err := fn()

쓰는 대신:

v := try(fn())

대신 다음과 같이 작성할 수 있습니다.

v := fn()

err 값이 캡처되지 않으면 try와 동일하게 처리됩니다. 익숙해지는 데 시간이 조금 걸리지만 v, ok := m[key] 및 v, ok := x.(string) $ 와 매우 유사합니다. 기본적으로 처리되지 않은 오류로 인해 함수가 반환되고 err 값이 설정됩니다.

설계 문서 결론 및 구현 요구 사항으로 돌아가려면 다음을 수행합니다.

• 언어 구문이 유지되고 새로운 키워드가 도입되지 않습니다.
• try와 같은 구문 설탕이 계속 사용되며 설명하기 쉬울 것입니다.
• 새로운 구문이 필요하지 않습니다.
• 이전 버전과 완전히 호환되어야 합니다.

기본 차이점이 구문 설탕을 트리거하는 내장 기능이 아니라 err 필드가 없기 때문에 이것이 try와 거의 동일한 구현 요구 사항을 가질 것이라고 생각합니다.

따라서 제안서의 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 의미론이 try와 정확히 동일할 것이라고 생각했기 때문에 최소한 err 유형을 선언해야 합니다. 따라서 다음과 같이 시작하면:

func foo() error {
  _, err := fn() 
  if err != nil {
    return err
  }

  return nil
} 

시도 제안을 이해하면 간단히 다음을 수행하십시오.

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()
}

루프 내에서 계속 사용할 수 있습니다.

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 )는 defer 내부에서 호출되지 않으면 nil을 반환할 수 있습니다.

또 다른 대안은 funcerror가 "Errorer" 인터페이스를 반환하여 읽기 전용으로 만드는 것입니다.

type interface Errorer() {
        Error() error
}

@savaki 저는 try() 를 생략하고 지도 또는 유형 주장을 테스트하는 것과 같도록 허용하는 귀하의 제안을 실제로 좋아합니다. 훨씬 더 _"가는 것 같아요."_

그러나 여전히 눈에 띄는 한 가지 문제가 있으며, 이는 이 접근 방식을 사용하는 모든 오류가 return 를 트리거하고 기능을 종료한다고 가정하는 귀하의 제안입니다. 고려하지 않은 것은 현재 for 중 break $#$ 또는 현재 for 에 대해 continue 를 발행하는 것입니다.

초기 return s는 여러 번 메스가 더 나은 선택일 때 큰 망치입니다.

그래서 저는 break 및 continue 가 유효한 오류 처리 전략으로 허용되어야 한다고 주장하며 현재 귀하의 제안은 return 만 가정하는 반면 try() 는 이를 가정하거나 오류를 호출합니다 핸들러 자체는 return 만 가능하고 break 또는 continue $ 는 불가능합니다.

savaki와 비슷한 아이디어가 있는 것 같습니다. 원하는 경우 오류를 처리하기 위해 블록 의미 체계를 추가했습니다. 예를 들어 단락 등을 원하는 루프에 대한 컨텍스트 추가

@mikeschinkel 내 확장 기능을 참조하십시오. 그와 저는 비슷한 아이디어를 가지고 있었습니다. 방금 선택적 블록 문으로 확장했습니다.

@제임스 로렌스

@mikeskkinkel 내 확장 기능을 참조하십시오. 그와 나는 비슷한 아이디어를 가지고 있었습니다. 방금 선택적 블록 문으로 확장했습니다.

귀하의 예를 들면:

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의 오류 처리에 매우 만족합니다. 나는 이 제안에서 어떤 것도 매우 유용하다고 보지 않습니다. 나는 우리가 그것을 할 준비가되어 있지 않다면 golang에 가장 자연스러운 적합성을 제공하려고 시도하고 있습니다.

_"반환을 자동으로 삽입하는 아이디어는 마법과 같습니다."_

당신은 거기에서 나에게서 어떤 논쟁도 얻지 못할 것입니다.

_"이것은 이 전체 제안에서 진행되는 가장 마법 같은 일이 아닙니다."_

나는 _"모든 마법은 문제가 있다"라고 주장하려고 했던 것 같다.

_"게다가 오류가 선언되었다고 주장하고 싶습니다. 범위가 지정된 블록의 컨텍스트 내부에서 마지막에..."_

그래서 err2 라고 부르고 싶다면 이것도 작동할까요?

f := os.Open("foo.txt"); err2 {
  return errors.Wrap(err, "some context")
}

따라서 세미콜론 뒤에 err / err2 의 특별한 경우 처리를 제안한다고 가정합니다. 즉, nil 또는 nil 이 아닌 것으로 가정합니다. 지도를 확인할 때와 같이 bool nil ?

if _,ok := m[a]; !ok {
   print("there is no 'a' in 'm'")
}

나는 일반적으로 오류 패키지에 곧 추가될 go의 오류 처리에 매우 만족합니다.

저도 break 및 continue _( return 는 아님)_ 오류 처리에 만족합니다.

있는 그대로, 나는 이 try() 제안이 도움이 되기보다는 해롭다고 생각하며, 제안된 대로 구현하는 것 외에는 아무 것도 보고 싶지 않습니다. #jmtcw.

@beoran @mikeschinkel 이전에 제네릭을 사용하여 이 버전의 try 를 구현할 수 없다고 제안했는데, 이는 제어 흐름을 변경하기 때문입니다. 내가 올바르게 읽고 있다면, 당신은 둘 다 panic 를 호출하도록 하여 try 를 구현하기 위해 제네릭을 사용할 수 있다고 제안하고 있습니다. 그러나 try 의 이 버전은 매우 명시적으로 panic 하지 않습니다. 따라서 이 버전의 try 를 구현하기 위해 제네릭을 사용할 수 없습니다.

예, 제네릭(https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md의 디자인 초안보다 훨씬 더 강력한 제네릭 버전)을 사용하여 함수를 작성할 수 있습니다. 오류가 발생하면 패닉이 발생합니다. 그러나 오류에 대한 패닉은 오늘날 Go 프로그래머가 작성하는 오류 처리 유형이 아니며 나에게 좋은 생각처럼 보이지 않습니다.

@mikeschinkel 특수 처리는 블록이 오류가 있을 때만 실행되는 것입니다.
```
f := os.Open('foo'); err { return err } // 여기서 err은 항상 nil이 아닙니다.

@ianlancetaylor

_"예, 우리는 제네릭을 사용할 수 있습니다... 그러나 오류에 패닉하는 것은 오늘날 Go 프로그래머가 작성하는 오류 처리 유형이 아니며 나에게 좋은 생각처럼 보이지 않습니다."_

나는 실제로 이것에 대해 당신의 의견에 강력하게 동의합니다. 따라서 당신이 내 의견의 의도를 잘못 해석한 것으로 보입니다. Go 팀이 panic() 를 사용하는 오류 처리를 구현할 것이라고 제안한 것은 아닙니다. 물론 그렇지 않습니다.

대신에 나는 실제로 다른 문제에 대한 많은 과거 의견에서 귀하의 리드를 따르려고 노력 했으며, 사용자 영역에서 대신 가능하기 때문에 절대적으로 필요하지 않은 Go 변경을 피하도록 제안했습니다. 따라서 _if_ 제네릭이 해결된 _그때_ try() 를 원하는 사람들은 panic() 를 활용하더라도 실제로 스스로 구현할 수 있었습니다. 그리고 그것은 팀이 Go를 위해 추가하고 문서화해야 할 기능이 하나 줄어들 것입니다.

내가 하고 있지 않은 것(아마도 명확하지 않았을 수도 있음)은 사람들이 실제로 $# try() panic() 를 사용한다는 것을 옹호하는 것이었습니다. 단지 그들이 정말로 원하기만 하면 할 수 있고 제네릭.

그게 명확해 졌나요?

나에게 panic 을 호출하는 것은 완료되었지만 try 에 대한 이 제안과 상당히 다릅니다. 그래서 나는 당신이 말하는 것을 이해한다고 생각하지만 그것들이 동등하다는 데 동의하지 않습니다. 패닉을 일으키는 try 버전을 구현하기에 충분히 강력한 제네릭이 있더라도 이 제안에 제시된 try 버전에 대한 합리적인 욕구가 여전히 있을 것이라고 생각합니다.

@ianlancetaylor 인정합니다. 다시, 나는 try() 를 추가하는 방법을 찾는 것보다 추가할 필요가 없는 이유를 찾고 있었습니다. 위에서 말했듯이 여기에 제안된 대로 try() 를 사용하는 것보다 오류 처리에 대해 새로운 것이 없는 것이 훨씬 낫습니다.

나는 개인적으로 순전히 시각적인 측면을 기반으로 한 초기 check 제안을 이것보다 더 좋아했습니다. check 는 try() 와 같은 힘을 가지고 있지만 $#$ bar(try(foo())) bar(check 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가 패닉에서 복구된다는 것을 기억하고 패닉과 관련된 프로덕션 문제 디버깅을 상상해 보십시오. 계측을 보면 recordMetric 호출에서 db 호출 실패가 급증하는 것을 볼 수 있습니다. 이것은 후속 라인의 패닉인 진정한 문제를 가릴 수 있습니다.

이것이 실제로 얼마나 심각한 문제인지는 잘 모르겠지만 (슬프게도) defer가 오류 처리를 위한 이상적인 메커니즘이 아니라고 생각하는 또 다른 이유일 수 있습니다.

다음은 제기된 우려 사항 중 일부에 도움이 될 수 있는 수정 사항입니다. $#$ return $#$ 대신 try 를 goto 처럼 취급하십시오. 내 말을 들어. :)

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을 수정해야 합니다.

크레딧: 이 아이디어의 변형은 작년 GopherCon에서 @griesemer 가 직접 제안한 것입니다.

@josharian 여기서 panic 와의 상호 작용에 대해 생각하는 것이 중요합니다. 그리고 당신이 그것을 꺼내서 기쁩니다. 그러나 당신의 예는 나에게 이상하게 보입니다. 다음 코드에서 defer가 항상 "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 예, 이것은 우리가 작년에 논의한 버전과 거의 비슷합니다(단, try check 을 사용했다는 점만 제외). error 레이블에 도달하면 나머지 함수 본문으로 "뒤로" 점프할 수 없다는 것이 중요하다고 생각합니다. 그러면 goto 가 다소 "구조화"됩니다(스파게티 코드는 불가능). 제기된 한 가지 문제는 오류 처리기( error: ) 레이블이 항상 함수의 끝에서 끝날 것이라는 것입니다(그렇지 않으면 어떻게든 이 레이블을 건너뛰어야 함). 개인적으로 나는 오류 처리 코드가 (끝에) 방해가 되지 않는 것을 좋아하지만 다른 사람들은 처음부터 바로 보여야 한다고 느꼈습니다.

@mikeshenkel 루프에서 돌아오는 것을 음수가 아닌 플러스로 봅니다. 내 생각에는 개발자가 루프의 내용을 처리하기 위해 별도의 함수를 사용하거나 현재와 같이 명시적으로 err을 사용하도록 권장할 것입니다. 이 두 가지 모두 나에게 좋은 결과로 보입니다.

내 POV에서 이 시도 구문이 사용할 필요가 없다고 생각하는 것처럼 모든 사용 사례를 처리해야 한다고 생각하지 않습니다.

V, 확인:= m[키]

지도에서 읽은 양식

handle / check 제안 을 단순화된 형태로 되살리면 goto 레이블이 핸들러를 함수의 끝으로 강제하는 것을 피할 수 있습니다. 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 로 끝나는 것을 정말 싫어합니다.

나에게 내장 기능을 "시도"하고 체인을 활성화하는 데는 두 가지 문제가 있습니다.

• go의 나머지 제어 흐름과 일치하지 않습니다(예: for/if/return/etc 키워드).
• 코드 가독성이 떨어집니다.

나는 괄호 없이 진술하는 것을 선호한다. 제안서의 예는 여러 줄이 필요하지만 더 읽기 쉬워집니다(즉, 개별 "시도" 인스턴스는 놓치기 더 어려울 것입니다). 예, 외부 파서를 중단하지만 일관성을 유지하는 것을 선호합니다.

삼항 연산자는 go에 무언가가 없고 더 많은 키 입력이 필요하지만 동시에 가독성/유지 보수성을 향상시키는 또 다른 위치입니다. 이 보다 제한된 형식에 "시도"를 추가하면 표현력과 가독성 사이의 균형이 더 잘 맞을 것입니다(IMO).

FWIW, panic 는 제어 흐름에 영향을 미치고 괄호가 있지만 go 및 defer 도 흐름에 영향을 미치고 그렇지 않습니다. 나는 try 가 특이한 흐름 연산이라는 점에서 defer 와 더 비슷하다고 생각하는 경향이 있습니다 try (try os.Open(file)).Read(buf) 어쨌든, 하지만 어쨌든. 어느 쪽이든 괜찮습니다.

모든 사람이 최종 오류 반환 변수의 암시적 이름을 싫어할 것이라는 제안: $err . try() IMO보다 낫습니다. :-)

@griesemer

_"개인적으로, 나는 방해가 되는 에러 핸들링 코드를 좋아한다(마지막에)"_

거기에 +1!

나는 오류가 발생하기 _before_ 구현된 오류 처리가 오류가 발생한 _after_ 구현된 오류 처리보다 추론하기가 훨씬 어렵다는 것을 알았습니다. 정신적으로 점프하고 논리 흐름을 따라가야 하는 것은 1980년에 Basic with 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 range{} 와 유사한 for error{} 구조를 허용하지만 오류 발생 시에만 입력되고 한 번만 실행됩니다.

2. <object>.Error() string 를 구현하는 반환 값 캡처를 생략 할 수 있지만 for error{} 구문이 동일한 func 내에 있는 경우에만 가능합니다.

3. func 가 마지막 반환 값에서 _"오류"_를 반환할 때 프로그램 제어 흐름이 for error{} 구조의 첫 번째 줄로 점프 하도록 합니다.

4. _"오류"_를 반환할 때 Go는 <error>.Source() 로 검색할 수 있는 오류를 반환한 함수에 대한 참조를 할당합니다.

_"오류"_란 무엇입니까?

현재 _"오류"_는 Error() string 를 구현하는 모든 개체로 정의되며 물론 nil 는 아닙니다.

그러나 RESTful API의 성공 결과에 필요한 값을 반환할 수 있도록 _성공한 경우에도_ 오류를 확장해야 하는 경우가 종종 있습니다. 따라서 Go 팀에 err!=nil 가 _"오류"를 의미한다고 자동으로 가정하지 말고 대신 오류 개체가 IsError() IsError() 가 true 를 반환하는지 확인하도록 요청합니다. $ nil 가 아닌 값이 _"오류"라고 가정하기 전에 true

_( 필연적 으로 표준 라이브러리의 코드에 대해 말하는 것은 아니지만 주로 _"오류"에서 분기하도록 제어 흐름을 선택하는 경우입니다. err!=nil 만 보면 우리가 할 수 있는 것이 매우 제한적일 것입니다. 우리 함수의 반환 값 측면에서 할 수 있습니다.)_

BTW, 모든 사람이 동일한 방식으로 _"오류"_ 테스트할 수 있도록 하려면 새로운 내장 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()
}

_"오류"_의 포착을 허용하지 않는 것의 부수적 이점

func 호출에서 마지막 _"error"_를 캡처하지 않도록 허용하면 나중에 리팩토링이 처음에는 오류를 반환할 필요가 없는 func 에서 오류를 반환할 수 있습니다. 그리고 이 형태의 오류 복구를 사용 하는 기존 코드를 손상시키지 않고 이 리팩토링을 허용하고 func 를 호출합니다.

나에게 _"간단함을 호출하기 위해 오류를 반환해야 하나요 아니면 오류 처리를 포기해야 하나요?"_라는 결정은 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() 함수에는 위에서 설명한 '래핑 오류' 기능이 없습니다.

_"이 두 가지 모두 나에게 좋은 결과로 보입니다."_

우리는 여기에 동의하지 않는 데 동의해야 합니다.

_"이 시도 구문(꼭 필요하지 않음)은 모든 사용 사례를 처리합니다."_

그 밈이 아마도 가장 문제가 될 것입니다. 적어도 바둑 팀/커뮤니티가 광범위하게 적용할 수 없는 과거의 변화에 ​​얼마나 저항했는지를 감안할 때.

여기에서 정당화를 허용한다면 광범위하게 적용할 수 없기 때문에 거절되었던 과거 제안을 다시 검토할 수 없는 이유는 무엇입니까?

이제 우리는 선택된 엣지 케이스에만 유용한 Go의 변경 사항에 대해 논의할 수 있습니까?

제 생각에는 이 선례를 세우는 것이 장기적으로 좋은 결과를 낳지 못할 것입니다...

_"@mikeshenkel"_

추신: 맞춤법 오류로 인해 처음에 귀하의 메시지를 보지 못했습니다. _(이것은 나를 화나게 하지 않습니다. 단지 내 사용자 이름의 철자가 틀렸을 때 알림을 받지 못할 뿐입니다...)_

try 를 키워드가 아닌 내장으로 만들도록 동기를 부여하는 이전 버전과의 호환성에 대한 약속에 감사드립니다. 그러나 제어 흐름( panic 및 recover 는 극히 드문 경우입니다.), 궁금한 점이 생겼습니다. 오픈 소스 코드베이스에서 식별자로 try 의 빈도를 대규모로 분석한 사람이 있습니까? 궁금하고 회의적이어서 다음과 같은 사전 검색을 했습니다.

• https://github.com/google/go-github
• https://github.com/cockroachdb/cockroach
• https://github.com/golang/net
• https://github.com/exercism/xgo
• https://github.com/GoogleCloudPlatform/kubernetes
• https://github.com/syncthing/syncthing
• https://github.com/mitchellh/packer
• https://github.com/drone/drone
• https://github.com/coreos/etcd
• https://github.com/docker/docker
• 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/lime
• https://github.com/flynn/flynn
• https://github.com/dropbox/godropbox
• https://github.com/hashicorp/consul
• https://github.com/hashicorp/terraform

이 저장소에 있는 11,108,770개의 중요한 Go 라인에서 try 가 식별자로 사용된 인스턴스는 63개 에 불과했습니다. 물론, 나는 이러한 코드베이스(크고 널리 사용되며 그 자체로 중요함)가 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 구문은 기존 "compound 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는 매우 간단한 이유 때문에 항상 도움이 되기보다 혼란스러워 보였습니다. 조건문은 일반적으로 작업 _후에_ 발생하고 결과 처리와 관련이 있습니다. 작업이 조건문 내부에 끼어 있으면 발생하는 것이 덜 명확합니다. 눈이 산만하다. 게다가, 정의된 변수의 범위는 라인에서 가장 왼쪽에 있을 때만큼 즉각적으로 명확하지 않습니다.
• 오류 핸들러는 의도적 으로 함수로 정의되지 않았습니다 (또는 함수와 유사한 의미와 유사하지 않음). 이것은 우리를 위해 몇 가지 일을 합니다:
  
  
  
  • 컴파일러는 참조되는 곳마다 명명된 핸들러를 간단히 인라인할 수 있습니다. 함수 호출보다 간단한 매크로/코드 생성 템플릿에 훨씬 가깝습니다. 런타임은 핸들러가 있다는 사실조차 알 필요가 없습니다.
  
  
  • 핸들러 내부에서 할 수 있는 일에는 제한이 없습니다. check / handle 에 대한 "이 오류 처리 프레임워크는 구제금융에만 적합합니다"라는 비판을 피할 수 있습니다. 우리는 또한 "핸들러 체인" 비판을 피합니다. 임의의 코드는 이러한 처리기 중 하나에 배치할 수 있으며 다른 제어 흐름은 암시되지 않습니다.
  
  
  • super return 를 의미하기 위해 핸들러 내부에서 return 를 하이재킹할 필요가 없습니다. 키워드 도용은 매우 혼란스럽습니다. return 는 return 를 의미하며 $# super return 는 실제로 필요하지 않습니다.
  
  
  • defer 는 오류 처리 메커니즘으로 달빛을 받을 필요가 없습니다. 주로 리소스 등을 정리하는 방법으로 계속 생각할 수 있습니다.
  
  
• 오류에 컨텍스트 추가와 관련하여:
  
  
  
  • 핸들러를 사용하여 컨텍스트를 추가하는 것은 매우 간단하며 기존 if err != nil 블록과 매우 유사합니다.
  
  
  • " 핸들러 없이 시도 " 구성이 컨텍스트 추가를 직접 권장하지는 않지만 핸들러 양식으로 리팩토링하는 것은 매우 간단합니다. 그 용도는 주로 개발 중이며 처리되지 않은 오류를 강조 표시하기 위해 go vet 검사를 작성하는 것은 매우 간단합니다.
  
  

이러한 아이디어가 다른 제안과 매우 유사하다면 죄송합니다. 모든 제안을 따라잡으려고 노력했지만 많은 기회를 놓쳤을 수 있습니다.

@brynbellomy 키워드 분석에 감사드립니다 - 매우 유용한 정보입니다. try 를 키워드로 사용해도 괜찮을 것 같습니다. (당신은 API가 영향을 받지 않는다고 말합니다. 사실이지만 try 가 여전히 매개변수 이름 등으로 표시될 수 있으므로 문서를 변경해야 할 수도 있습니다. 하지만 해당 패키지의 클라이언트에는 영향을 미치지 않을 것이라는 데 동의합니다.)

당신의 제안에 대해: 명명된 핸들러가 없어도 괜찮을 것입니다. 그렇지 않나요? (그것은 전력 손실 없이 제안을 단순화할 것입니다. 인라인 처리기에서 단순히 로컬 함수를 호출할 수 있습니다.)

당신의 제안에 대해: 명명된 핸들러가 없어도 괜찮을 것입니다. 그렇지 않나요? (그것은 전력 손실 없이 제안을 단순화할 것입니다. 인라인 처리기에서 단순히 로컬 함수를 호출할 수 있습니다.)

@griesemer 실제로 — 나는 그것들을 포함하는 것에 대해 꽤 미지근한 느낌이 들었습니다. 확실히 더 Go-ish 없이.

반면에 사람들은 return 한 줄짜리 오류 처리를 포함하여 한 줄짜리 오류 처리 기능을 원하는 것 같습니다. 일반적인 경우는 로그이고 return 입니다. else 절에서 로컬 함수로 쉘 아웃하면 아마도 다음과 같이 손실될 것입니다.

a, b := try SomeFunc() else err {
    someLocalFunc(err)
    return 0, err
}

(저는 여전히 if를 합성하는 것보다 이것을 선호합니다.)

그러나 앞서 스레드에서 논의한 간단한 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/Go2ErrorHandling피드백

@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. try(매개변수, 레이블)
4. try(params, 패닉)

1은 단순히 오류 반환 매개변수(ERP)에 대한 포인터를 반환하거나 없는 경우(#4만) nil을 반환합니다. 이것은 추가 내장을 추가할 필요 없이 명명된 ERP에 대한 대안을 제공합니다.

2는 현재 예상한 대로 정확하게 작동합니다. nil이 아닌 오류는 즉시 반환되지만 defer 문으로 장식할 수 있습니다.

3은 @josharian 이 제안한 대로 작동합니다. 즉, nil이 아닌 오류에서 코드가 레이블로 분기됩니다. 그러나 그 경우가 이제 #2로 변질되기 때문에 기본 오류 처리기 레이블이 없습니다.

이것은 일반적으로 더 간단하고 빠르기 때문에 defer 보다 오류를 장식하는(또는 로컬로 처리한 다음 nil을 반환하는) 더 나은 방법인 것 같습니다. 그것을 좋아하지 않는 사람은 여전히 ​​# 2를 사용할 수 있습니다.

함수의 끝 부분에 오류 처리 레이블/코드를 배치하고 함수 본문의 나머지 부분으로 다시 이동하지 않는 것이 가장 좋습니다. 그러나 컴파일러가 유용하고 어떤 경우에도 시행이 어려울 수 있기 때문에 컴파일러가 시행해야 한다고 생각하지 않습니다.

따라서 일반적인 레이블 및 goto 동작은 제목( @josharian 이 말한 대로)을 #26058이 먼저 수정되도록 적용하지만 어쨌든 수정되어야 한다고 생각합니다.

레이블 이름은 #4와 충돌하므로 panic 가 될 수 없습니다.

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's 코드에서 반환은 항상 /^\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 을 가질 의도인지 확실하지 않습니다. 어쨌든 try 로 시작하는 2-3줄에 걸쳐 그것을 퍼뜨리도록 요구하는 것이 더 나을 것입니다.

@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 가 적용되는 곳에서 거의 모든 블록을 좀 더 읽기 쉽게 만든다는 것입니다.

두 번째는 이들 중 10분의 1 미만인 극소수만이 다른 표현식 안에 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)
        ...
}

이것은 다른 표현식 내부에서 시도하는 예는 아니지만 가독성을 향상시키기 때문에 호출하고 싶습니다. c 및 t 의 값이 if 문의 범위를 벗어나 있음을 여기에서 훨씬 더 쉽게 알 수 있습니다.

그물/http

net/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의 인기 있는 패키지에 대해 생성된 diffs의 샘플을 읽는 것은 흥미로울 것입니다. 그러한 프로그램의 출력은 제안의 효과에 대한 추가 통찰력을 제공할 수 있습니다.

@crawshaw 이렇게 해주셔서 감사합니다. 실제로 작동하는 것을 볼 수 있어서 좋았습니다. 그러나 실제로 작동하는 것을 보니 지금까지 무시해 왔던 인라인 오류 처리에 대한 주장을 더 진지하게 받아들이게 되었습니다.

이것은 try 를 명령문으로 만드는 @thepudds 의 흥미로운 제안과 매우 가깝기 때문에 해당 구문을 사용하여 모든 예제를 다시 작성했으며 표현식- 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 -ed여야 하는 여러 필드가 있는 경우 try 표현식과 함께 사용하는 것이 틀림없지만 저는 여전히 이 절충안의 균형을 선호합니다.

        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

최소한 패닉 및 무시 작업에 대해서는 하위 표현식 구문이 필요합니다(Russ는 이것이 요구 사항이라고 말했습니다).

먼저 @crawshaw 가 시간을 내어 대략 200개의 실제 사례를 살펴보고 위의 사려 깊은 글을 작성해 주신 데 대해 박수를 보냅니다.

둘째, @jimmyfrasche , http2Framer 예시에 대한 귀하의 응답은 다음과 같습니다.

나는 if try 가 합법인지 또는 합법이어야 하는지 나 자신과 토론했지만, 왜 그것이 되어서는 안 되며 여기에서 아주 잘 작동하는지 합리적인 설명을 제시할 수 없었습니다.

```
func (f *http2Framer) endWrite() 오류 {
...
시도 n := fwWrite(f.wbuf); n != 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 가 행의 첫 번째 항목이어야 하는 경우 함수에서 더 "신성한" 반환을 보류합니다.

@crawshaw 언급:

두 번째는 10분의 1도 되지 않는 아주 적은 수의 사람들이 다른 표현식 안에 try를 넣을 것이라는 점입니다. 일반적인 경우는 x := try(...) 또는 ^try(...)$ 형식의 명령문입니다.

아마도 try 의 보다 제한된 형식으로 10개 중 1개의 예제를 부분적으로만 도움이 되는 것이 좋습니다 try 라인에서 가장 먼저 해야 합니까?

@jimmyfrasche

@crawshaw 이렇게 해주셔서 감사합니다. 실제로 작동하는 것을 볼 수 있어서 좋았습니다. 그러나 실제로 작동하는 것을 보니 지금까지 무시해 왔던 인라인 오류 처리에 대한 주장을 더 진지하게 받아들이게 되었습니다.

이것은 try 를 명령문으로 만드는 @thepudds 의 흥미로운 제안과 매우 가깝기 때문에 해당 구문을 사용하여 모든 예제를 다시 작성했으며 표현식- 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 ) 이름을 지정할 수 없습니다. expression- try 를 사용하면 중간 변수가 필요하지 않으므로 이 문제가 발생하지 않습니다.

차라리 익명으로 남겨두는 것이 더 나은 이름을 짓기 위해 정신적 노력을 들일 필요가 없습니다.

try (키워드)가 줄의 시작 부분으로 이동된 마지막 몇 개의 게시물 뒤에 제 지원을 제공하게 되어 기쁩니다. return 와 같은 시각적 공간을 공유해야 합니다.

Re: @jimmyfrasche 가 try 를 복합 if 명령문 내에서 허용하도록 제안했습니다. 바로 이것이 몇 가지 이유로 여기 많은 사람들이 피하려고 하는 것입니다.

• 그것은 두 개의 매우 다른 제어 흐름 메커니즘을 단일 라인으로 통합합니다.
• try 표현식이 실제로 먼저 평가되고 함수가 반환되도록 할 수 있지만 if 뒤에 나타납니다.
• 그들은 완전히 다른 오류를 반환합니다. 그 중 하나는 실제로 코드에서 볼 수 없고 다른 하나는
• try 블록이 핸들러 블록과 매우 유사해 보이기 때문에 try 가 실제로 처리되지 않는다는 것을 덜 명확하게 만듭니다(완전히 다른 문제를 처리하고 있음에도 불구하고)

사람들이 try 를 처리하도록 하는 약간 다른 각도에서 이 상황에 접근할 수 있습니다. try / else 구문에 후속 조건( err 및 n 을 모두 반환하는 많은 I/O 함수의 공통 패턴)을 포함하도록 허용하는 것은 어떻습니까?

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 @crawshaw
나는 이것에 대해 Daves의 의견에 동의하는 경향이 있습니다. @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

net/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)
  }
}

이는 nil 핸들러 함수의 모호성에 대한 @griesemer 의 우려와 상충되며 err 이름을 지정해야 하는 것 외에도 자체 defer 및 func(err error) error 상용구가 있습니다. err 는 외부 함수에 있습니다.

try 가 키워드로 끝나는 경우 아래에 설명된 catch 키워드도 있는 것이 합리적일 수 있습니다.

구문상 handle 와 비슷합니다.

catch err {
  return handleThe(err)
}

의미적으로 위의 내부 처리기 코드에 대한 설탕이 됩니다.

defer func() {
  if err != nil {
    err = handleThe(err)
  }
}()

다소 마술적이기 때문에 이름이 지정되지 않은 경우에도 외부 함수의 오류를 잡을 수 있습니다. ($# catch err 뒤의 err는 catch 블록의 매개변수 이름과 비슷합니다.)

catch 는 try 와 동일한 제한을 가지며 최종 오류 반환이 있는 함수에 있어야 합니다. 둘 다 그것에 의존하는 설탕이기 때문입니다.

이는 원래의 handle 제안만큼 강력하지는 않지만 이를 처리하기 위해 오류 이름을 지정해야 하는 요구 사항을 없애고 내부 처리기에 대해 위에서 논의한 새로운 상용구를 제거하는 동시에 외부 처리기에 대해 별도의 버전의 함수가 필요합니다.

복잡한 오류 처리는 try 를 사용하지 않는 것과 마찬가지로 catch 를 사용하지 않아야 합니다.

둘 다 설탕이므로 try catch 를 사용할 필요가 없습니다. catch 핸들러는 함수가 nil 가 아닌 오류를 반환할 때마다 실행되며, 예를 들어 빠른 로깅을 계속할 수 있습니다.

catch err {
  log.Print(err)
  return err
}

또는 반환된 모든 오류를 래핑합니다.

catch err {
  return fmt.Errorf("foo: %w", err)
}

@ianlancetaylor

_" 후행 error 매개변수를 추가하기 위해 함수가 변경되면 기존 코드가 계속 컴파일되지만 매우 다르게 작동하기 때문에 이는 잘못된 생각이라고 생각합니다."_

업스트림 코드와 다운스트림 코드를 모두 제어할 수 있는 경우 오류를 반환하기 위해 함수 서명을 변경해야 하는 경우 그렇게 할 수 있습니다.

하지만 누군가가 자신의 패키지의 업스트림이나 다운스트림을 제어하지 않을 때 어떤 일이 발생하는지 생각해 보시기 바랍니다. 또한 오류가 추가될 수 있는 사용 사례와 오류를 추가해야 하지만 다운스트림 코드를 강제로 변경할 수 없는 경우에는 어떻게 됩니까?

누군가가 서명을 변경하여 반환 값을 추가하는 예를 생각할 수 있습니까? 저에게 그들은 일반적으로 _"오류가 발생할 줄 몰랐습니다"_ 또는 _"게으름을 느끼고 오류가 발생하지 않을 것이기 때문에 노력하고 싶지 않습니다."의 범주에 속합니다. _

두 경우 모두 오류를 처리해야 하는 것이 분명해지기 때문에 오류 반환을 추가할 수 있습니다. 그럴 때 내 패키지를 사용하는 다른 개발자와의 호환성을 깨고 싶지 않아 서명을 변경할 수 없으면 어떻게 해야 합니까? 내 생각에 대부분의 경우 오류가 발생하고 오류를 반환하지 않는 func를 호출한 코드는 _어쨌든._ 매우 다르게 작동할 것입니다.

사실 나는 후자를 거의 하지 않지만 전자는 너무 자주 한다. 하지만 타사 패키지가 있어야 할 위치에서 캡처 오류를 자주 무시한다는 사실을 알게 되었고, GoLand의 코드를 모든 인스턴스에 밝은 주황색으로 표시할 때 이를 알고 있기 때문입니다. 내가 많이 사용하는 패키지에 오류 처리를 추가하기 위해 pull 요청을 제출할 수 있기를 원하지만 대부분의 경우 수락하지 않을 것입니다. 왜냐하면 내가 그들의 코드 서명을 깨뜨릴 것이기 때문입니다.

함수에서 반환할 오류를 추가하는 이전 버전과 호환되는 방법을 제공하지 않음으로써 코드를 배포하고 사용자를 위해 손상되지 않도록 하는 개발자는 오류 처리를 포함하도록 패키지를 발전시킬 수 없습니다.

코드가 다르게 작동한다는 문제를 고려하기 보다는 문제를 능동적으로 오류를 캡처하지 않는 메서드의 단점을 최소화하는 방법에 관한 엔지니어링 문제로 볼 수 있습니까? 그것은 더 광범위하고 장기적인 가치를 가질 것입니다.

예를 들어 오류를 무시할 수 있기 전에 설정해야 하는 패키지 오류 처리기를 추가하는 것을 고려하시겠습니까?

솔직히 말해서, 정기적인 반환 값에 추가하여 오류를 반환하는 Go의 관용구는 더 나은 혁신 중 하나였습니다. 그러나 개선할 때 종종 발생하는 것처럼 다른 약점을 노출하는 경우가 많으며 Go의 오류 처리가 충분히 혁신적이지 못했다고 주장합니다.

우리 Gophers는 예외를 던지기 보다는 오류를 반환하는 데 몰두하게 되었습니다. 그래서 제가 가지고 있는 질문은 _"왜 우리는 모든 함수에서 오류를 반환하지 않아야 합니까?"_ 오류 처리 없이 코드를 작성하는 것이 항상 그렇게 하는 것은 아닙니다. 그것으로 코딩하는 것보다 더 편리합니다. 따라서 오류 처리에서 벗어날 수 있다고 생각되면 오류 처리를 생략합니다. 그러나 종종 우리는 잘못 추측합니다.

그래서 정말로, 코드를 우아하고 읽기 쉽게 만드는 방법을 알아낼 수 있다면 반환 값과 오류는 실제로 별도로 처리되어야 하고 _every_ 함수는 과거 함수 서명에 관계없이 오류를 반환할 수 있어야 한다고 주장할 것입니다. 그리고 현재 오류를 생성하는 코드를 정상적으로 처리하기 위해 기존 코드를 얻는 것은 가치 있는 노력이 될 것입니다.

나는 실행 가능한 구문을 상상할 수 없었기 때문에 아무 것도 제안하지 않았지만, 우리 스스로에게 정직하고 싶다면 이 스레드의 모든 것과 일반적으로 Go의 오류 처리와 관련된 것은 오류 처리 및 프로그램 로직이 이상한 동료들이므로 이상적으로는 오류가 어떤 방식으로든 대역 외에서 가장 잘 처리될 것입니까?

try 키워드는 확실히 가독성(함수 호출 대비)에 도움이 되며 덜 복잡해 보입니다. @brynbellomy @crawshaw 시간을 내어 예제를 작성해 주셔서 감사합니다.

내 일반적인 생각은 try 가 너무 많은 일을 한다는 것입니다. 함수 호출, 변수 할당, 오류 확인 및 존재하는 경우 오류 반환을 해결합니다. 나는 대신 범위를 줄이고 조건부 반환에 대해서만 해결할 것을 제안합니다. "마지막 인수가 nil이 아닌 경우 반환".

이것은 아마도 새로운 생각이 아닐 것입니다... 그러나 오류 피드백 위키 에서 제안을 훑어본 후, 나는 그것을 찾지 못했습니다(그것이 거기에 없다는 것을 의미하지는 않습니다)

조건부 반환에 대한 미니 제안

발췌:

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 에 두어 적임)를 설정한다는 것입니다. (즉, nil이 아닌 오류). 일종의 회로 차단기이며, 디자인이 흥미롭지 않은 경우로 제한되어 가장 낮은 상용구를 단순히 줄이기 위해 가치를 추가할 수 있다고 생각합니다. 원격으로 복잡한 모든 것은 일반 Go 코드에 의존해야 합니다.

나는 또한 표준 라이브러리를 살펴보는 그의 작업에 대해 cranshaw를 칭찬하지만, 나는 매우 다른 결론에 도달했습니다... 거의 모든 코드 조각을 읽기 어렵게 만들고 더 오해하기 쉽게 만드는 것 같습니다.

        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 팔로우하고 있는지 잘 모르겠습니다. 이름이 마음에 들지 않거나 아이디어가 마음에 들지 않습니까?

어쨌든, 나는 이것을 대안으로 여기에 게시했습니다 ... 합법적 인 관심이 있다면 토론을 위해 새 문제를 열 ​​수 있습니다.이 스레드를 오염시키고 싶지 않습니다 (아마도 너무 늦었습니까?) 원래 아이디어에 대한 엄지 손가락이 줄 것입니다 우리 의미... 물론 다른 이름에 열려 있습니다. 중요한 부분은 "할당 처리를 시도하지 않고 조건부 반환"입니다.

@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로 해결되지 않음)을 사용할 때의 주요 문제는 err이 불필요하다는 것입니다. fmt.HandleErrorf 와 같은 처리기에 대한 호출을 연기할 때 오류 반환 값에 대한 포인터를 제외하고 합리적인 첫 번째 인수가 없습니다. 사용자에게 실수를 할 수 있는 옵션을 제공하는 이유는 무엇입니까?

catch와 비교하여 주요 차이점은 핸들러가 미리 정의된 핸들러를 제자리에 정의하기 위해 더 장황하게 만드는 대신 미리 정의된 핸들러를 호출하기가 조금 더 쉽다는 것입니다. 이것이 이상적이라고 확신할 수는 없지만 원래 제안에 더 부합한다고 생각합니다.

@yiyus catch , 정의한 대로 catch 를 포함하는 함수에 err 이름을 지정할 필요가 없습니다.

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 의 기존 기능과 직교해야 합니다. 즉, 핸들과 지연이 상호 작용할 때 이상한 코너 케이스를 생성하지 않고 제안된 핸들링 메커니즘이 그 자체로 필요하다는 것이 분명할 만큼 충분히 달라야 합니다.

try /handle에 대한 대체 메커니즘을 논의할 때 이러한 요구 사항을 염두에 두십시오.

@carlmjohnson 요점 2에 대한 @jimmyfrasche 의 catch 아이디어가 마음에 듭니다. defer 에 대한 구문 설탕일 뿐이므로 2줄을 절약하고 오류 반환 값의 이름을 지정할 필요가 없습니다. 또한 아직 지정하지 않은 경우 다른 모든 항목의 이름을 지정해야 합니다. defer 이기 때문에 defer 와 직교성 문제를 일으키지 않습니다.

@ubombi 가 말한 내용을 반영합니다.

try() 함수 호출은 상위 함수에서 코드 실행을 중단합니다.; return 키워드는 없지만 코드는 실제로 반환합니다.

Ruby에서 procs와 lambdas는 try 가 하는 일의 한 예입니다... proc은 return 문이 블록 자체가 아니라 호출자로부터 반환하는 코드 블록입니다.

이것이 바로 try 가 하는 일입니다... 그냥 미리 정의된 Ruby proc입니다.

우리가 그 길을 간다면 실제로 proc functions 를 도입하여 사용자가 자신의 try 함수를 정의하도록 할 수 있을 것입니다.

나는 여전히 if err != nil 를 선호하는데 가독성이 더 높지만 사용자가 자신의 proc을 정의한다면 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 를 노출, 비공개 또는 내부로 만들 수도 있습니다.

또한 각 함수가 아닌 전체 코드베이스에 대해 한 번만 정의할 수 있기 때문에 원래 Go2 제안의 handle {} 절보다 낫습니다.

가독성에 대한 한 가지 고려 사항은 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(파일 이름))
제안이 조언하는 대로 정확하게 수행할 수 있지만 함수(또는 실제로 "핸들러 함수")로서 개발자는 함수가 하는 일, 다른 경우에 오류 형식을 지정하는 방법에 대해 훨씬 더 많은 제어 권한을 갖게 되며, 유사한 핸들러를 전체적으로 사용합니다. 매번 fmt.Errorf("error opening file %s ....")를 작성하는 대신 os.Open을 처리할 코드(말하자면).
이것은 또한 "try"가 정의되지 않은 것처럼 강제로 오류를 처리합니다. 이는 컴파일 시간 오류입니다.

@guybrand 이러한 2단계 반환 return2 (또는 Smalltalk에서 일반적인 개념이 "비로컬 반환"이라고 함)을 갖는 것은 좋은 범용 메커니즘이 될 것입니다(또한 #32473에서 @mikeschinkel 이 제안함) . 하지만 try 이(가) 귀하의 제안에 여전히 필요한 것 같으므로 return2 에 대한 이유를 알 수 없습니다. try 는 return 를 수행할 수 있습니다. try 를 쓸 수도 있으면 더 흥미로울 것이지만 임의의 서명에는 불가능합니다.

@griesemer

_" return2 에 대한 이유를 알 수 없습니다. try 는 return 를 할 수 있습니다."_

한 가지 이유는 — #32473 _(참고에 감사합니다)_ — return 외에도 break 및 continue 의 여러 수준을 허용하는 것입니다.

새로운 의견을 주신 모든 분들께 다시 한 번 감사드립니다. 토론을 따라잡고 광범위한 피드백을 작성하는 것은 상당한 시간 투자입니다. 때로는 열렬한 논쟁에도 불구하고 이것은 지금까지 다소 시민적인 스레드였습니다. 감사 해요!

여기에 또 다른 빠른 요약이 있습니다. 이번에는 좀 더 압축되었습니다. 내가 언급하지 않았거나, 잊었거나, 잘못 표현한 사람들에게 사과합니다. 이 시점에서 몇 가지 더 큰 주제가 등장하고 있다고 생각합니다.

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 는 2-argument try 의 아이디어를 되살려 두 번째 인수가 오류 핸들러가 될 것입니다.

@klaidliadon , @networkimprov 는 try f, # := os.Open() 와 같은 특수 "할당 연산자"를 선호합니다. @networkimprov 는 이러한 접근 방식을 조사하는 보다 포괄적인 대안 제안을 제출했습니다(문제 #32500 참조). @mikeschinkel 은 또한 오류 관련 try 가 아닌 오류 처리에도 사용할 수 있는 두 가지 새로운 범용 언어 기능을 도입할 것을 제안하는 대안 제안서를 제출했습니다(문제 #32473 참조). @josharian 은 작년 GopherCon에서 try 가 오류 발생 시 반환되지 않고 대신 error 라는 레이블로 점프( goto 사용)하는 가능성을 되살렸습니다. , 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에 대한 참조 덕분에 공통점이 많습니다.

~에 관하여

그러나 귀하의 제안에 여전히 시도가 필요한 것 같습니다.
내 제안은 예약된 "build in/keyword/expression"이 아닌 "any" 핸들러로 구현할 수 있지만 "try()"가 나쁜 생각이라고 생각하지 않습니다(따라서 반대 투표를 하지 않았습니다). "확대"하기 위해 - 더 많은 장점을 보여줄 것이므로 많은 사람들이 "일단 go 2.0이 도입될 것"이라고 예상했습니다.

마지막 요약에서 보고한 "혼합된 분위기"의 원인일 수도 있습니다. "try()는 오류 처리를 개선하지 않습니다." - 물론 "Go 3.0이 다른 주요 오류를 해결하기를 기다리는 중입니다. "고통 처리" 위에서 언급한 사람들이 너무 길어 보입니다. :)

나는 "오류 처리의 고통"에 대한 설문 조사를 수행하고 있습니다(그리고 고통 중 일부는 단지 "나는 좋은 관행을 사용하지 않습니다"라는 것입니다. 반면에 일부는 사람들(대부분 다른 언어에서 온)이 하고 싶어하는 것을 상상조차 하지 못했습니다. WTF로).

조만간 흥미로운 결과를 공유할 수 있기를 바랍니다.

마지막으로 - 놀라운 작업과 인내에 감사드립니다!

현재 제안된 구문의 길이와 현재 사용 가능한 구문을 비교하면 처리하지 않고 오류를 반환하거나 장식하기만 하면 되는 경우가 가장 편리합니다. 지금까지 내가 가장 좋아하는 구문의 예:

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 (편집: 입력이 nil일 때 nil을 반환한다고 가정함)와 같은 조건부 오류 기능은 초기 주석에서 잘 작동하므로 else 를 추가합니다. 불필요합니다.

a, b, err := doSomething()
try fmt.HandleErrorf(&err, "Decorated "...)

여기 있는 다른 많은 사람들과 마찬가지로 저는 try 를 표현식보다 명령문으로 사용하는 것을 선호합니다. 그 이유는 대부분 제어 흐름을 변경하는 표현식이 Go에서 완전히 이질적이기 때문입니다. 또한 이것은 표현식이 아니므로 줄의 시작 부분에 있어야 합니다.

나는 또한 이름이 적절하지 않다는 @daved 에 동의합니다. 결국, 여기서 우리가 달성하려는 것은 보호된 할당이므로 Swift에서와 같이 guard 를 사용하고 else 절을 선택 사항으로 만들지 않겠습니까? 같은 것

GuardStmt = "guard" ( Assignment | ShortVarDecl | Expression ) [  "else" Identifier Block ] .

여기서 Identifier 는 다음 Block 에 바인딩된 오류 변수 이름입니다. else 절이 없으면 현재 함수에서 반환하기만 하면 됩니다(필요한 경우 지연 처리기를 사용하여 오류를 장식합니다).

처음에는 else 절이 마음에 들지 않았습니다. 그 이유는 $# guard 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 의 경우 try if 를 사용하는 것보다 이점이 있습니다. 하지만 장점이 너무 미미해서 내가 좋아하긴 하지만 그 자체로 정당화되기가 어렵습니다.

세 가지 모두 개별 오류에 대해 특별한 오류 처리가 필요한 것이 일반적이라고 가정합니다.

모든 오류를 동등하게 처리하는 것은 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
}

특정 오류가 특별한 처리가 필요한 경우가 있다는 것을 확실히 알고 있습니다. 기억에 남는 사례들입니다. 하지만 그런 일이 100번 중 1번만 일어난다면 try 를 단순하게 유지하고 그러한 상황에서 try 를 사용하지 않는 것이 더 좋지 않을까요? 반면에 10번 중 1번 이상이라면 else /handler를 추가하는 것이 더 합리적으로 보입니다.

else /handler가 없는 try 대 else가 있는 else try 의 실제 분포가 유용할 것이라는 실제 분포를 보는 것은 흥미로울 것입니다. 그것은 수집하기 쉬운 데이터가 아닙니다.

@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 기능으로 인해 제어 흐름에 대해 걱정하지 않는 사고 방식을 채택하도록 권장합니다. 나는 그 통제의 흐름이 그 언어를 아는 사람들에게 곧 제2의 천성이 될 것이라고 생각하지만, 아마도 잘못되었습니다. 정상적인 경우에는 사람들이 오류의 경우에 무슨 일이 일어나는지에 대해 걱정하지 않을 것이라고 믿습니다. if err != nil { return err } 위에 이미 유약을 바르듯이 try 위에 유약을 바르면서 이러한 예를 읽어보십시오.

여기 있는 모든 내용을 읽고 추가로 숙고한 결과, try 를 추가할 가치가 있는 문장으로 볼 수 있을지 확신이 서지 않습니다.

1. 그 근거는 오류 처리 보일러 플레이트 코드를 줄이는 것 같습니다. IMHO는 코드를 "정리"하지만 실제로 복잡성을 제거하지는 않습니다. 그것은 단지 그것을 흐리게 할 뿐입니다. 이것은 이유가 충분하지 않은 것 같습니다. "가" 구문은 동시 스레드를 시작하는 것을 아름답게 캡처했습니다. 여기에서는 그런 종류의 "아하!" 느낌을 받지 못합니다. 기분이 좋지 않습니다. 비용/편익 비율이 충분히 크지 않습니다.

2. 그 이름은 그 기능을 반영하지 않습니다. 가장 간단한 형태로, 그것이 하는 일은 다음과 같습니다: "만약 함수가 오류를 반환한다면, 호출자로부터 오류를 반환합니다." 그러나 그것은 너무 깁니다 :-) 최소한 다른 이름이 필요합니다.

3. try의 암시적 오류 반환을 사용하면 Go가 마지 못해 예외 처리를 지원하는 것처럼 느껴집니다. 즉, A가 try 가드에서 호출되고 B가 try 가드에서 C를 호출하고 C가 try 가드에서 D를 호출하는 경우 D가 실제로 오류를 반환하면 로컬이 아닌 goto가 발생한 것입니다. 너무 "마법적"으로 느껴집니다.

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 != 부분이 없고 범위를 생성하지 않거나

비슷하게

시도 a, b, 오류 := f() {
반환 없음, 오류
}

여분의 두 줄을 유지하지만 여전히 읽을 수 있습니다.

2019년 6월 11일 화요일, 20:19 Dmitriy Matrenichev, [email protected]
썼다:

@ianlancetaylor https://github.com/ianlancetaylor
"다른 시도" 제안을 올바르게 이해하면 else가 차단되는 것 같습니다.
선택 사항이며 사용자 제공 처리를 위해 예약되어 있습니다. 귀하의 예에서
try a, b := f() else err { return nil, err } else 절은 실제로
중복되며 전체 표현식은 단순히 try, b :=로 작성할 수 있습니다.
에프()

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/golang/go/issues/32437?email_source=notifications&email_token=ABNEY4XPURMASWKZKOBPBVDPZ7NALA5CNFSM4HTGCZ72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LDNMVXH
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/ABNEY4SAFK4M5NLABF3NZO3PZ7NALANCNFSM4HTGCZ7Q
.

@ianlancetaylor

어쨌든 내 요점은 우리가 무언가를 변경하려는 경우 상용구를 크게 줄이거나 훨씬 더 읽기 쉬워야 한다는 것입니다. 후자는 꽤 어렵기 때문에 모든 변경 사항은 실제로 전자에서 작동해야 합니다. 상용구에서 약간의 감소만 얻는다면 제 생각에는 할 가치가 없습니다.

동의합니다. else 는 구문상의 설탕(이상한 구문이 있습니다!)일 뿐이며 거의 사용되지 않을 가능성이 높으므로 그다지 신경 쓰지 않습니다. 그래도 try 를 진술로 사용하고 싶습니다.

@ianlancetaylor Echoing @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 화합물이 겪는 이상한 범위 지정을 줄일 수 있는 기회를 주세요.

처리되지 않은 try 가 가장 일반적일 것입니다.

@ianlancetaylor

if err != nil { return err } 이미 유약을 바르듯이 유약을 바르는 동안 이 예제를 읽어보십시오.

나는 그것이 가능하다고 생각하지 않습니다. 복잡한 줄에 try가 있는지, 정확히 무엇을 감싸는지, 또는 한 줄에 여러 인스턴스가 있다는 것을 놓치면... 이것들은 리턴 포인트를 쉽고 빠르게 표시하고 그 안의 세부 사항에 대해 걱정하지 않는 것과 다릅니다.

@ianlancetaylor

나는 정지 신호를 볼 때 인쇄된 단어를 읽고 그 깊은 의미를 숙고하는 것보다 모양과 색상으로 더 많이 인식합니다.

내 눈은 if err != nil { return err } 이상으로 빛날 수 있지만 동시에 여전히 명확하고 즉각적으로 등록됩니다.

try -statement 변형에 대해 내가 좋아하는 것은 그것이 상용구를 줄여주지만 유약을 바르기는 쉽지만 놓치기 어려운 방식이라는 것입니다.

여기 저기에 추가 줄을 의미할 수 있지만 이는 현재 상태보다 여전히 적은 수입니다.

@brynbellomy

1. 다음과 같이 여러 값을 반환하는 함수를 처리하는 방법은 무엇입니까?
   func createMergeCommit(r *repo.Repo, 인덱스 *git.Index, 원격 *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("error with head : %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)

즉, 반환된 err != nil인 경우 호출되는 함수 호출 오른쪽에 -> handler 가 있습니다. 핸들러는 오류를 단일 인수로 받아들이고 선택적으로 오류를 반환하는 함수입니다(예: func(error) 또는 func(error) error ). 핸들러가 nil 오류를 반환하면 함수가 계속 진행되고 그렇지 않으면 오류가 반환됩니다.

따라서 a := b() -> handler 는 다음과 같습니다.

a, err := b()
if err != nil {
  if herr := handler(err); herr != nil {
    return herr
  }
}

이제 바로 가기로 a := b() -> throw 의 약어인 try 내장(또는 키워드 또는 ?= 연산자 등)을 지원할 수 있으므로 다음과 같이 작성할 수 있습니다.

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 함수와 @thepudds 가 제안한 try 문은 모두 언어에 합당한 추가가 될 것 같습니다. 나는 바둑팀이 무엇을 하든 잘 될 것이라고 확신한다.

제안서에서 try가 정의된 방식과 이것이 향후 확장에 어떤 영향을 미칠 수 있는지에 대한 사소한 문제라고 생각하는 것을 제기하고 싶습니다.

Try는 다양한 인수를 취하는 함수로 정의됩니다.

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

try(f()) 에서와 같이 함수 호출 결과를 try 에 전달하는 것은 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())

끝에 놓으면 아마도 작동하지만 try는 인수 목록의 시작 부분 에 varargs 매개변수가 있는 유일한 함수이기 때문에 언어에서 고유할 것입니다.

이러한 문제 중 어느 것도 눈에 띄는 것은 아니지만 try 가 나머지 언어와 일치하지 않는 느낌을 주므로 try 이 제안 상태.

@마법 같은

핸들러를 갖는 것은 아마도 다음과 같이 강력합니다.
나는 당신이 이미 h를 선언했습니다.

당신은 할 수 있습니다

var h handler
a, b, h = f()

또는

a, b, h.err = f()

함수와 같은 경우:

h:= handler(err error){
 log(...)
 return ....
} 

그러자 제안이 있었다.

a, b, h(err) = f()

모두 핸들러를 호출할 수 있습니다.
또한 일부 제안된 대로 오류(계속/중단/반환)를 반환하거나 캡처만 하는 처리기를 "선택"할 수도 있습니다.

따라서 varargs 문제가 사라졌습니다.

@brynbellomy의 else 제안에 대한 대안:

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 를 사용할 수 있습니다(오늘날처럼).

즉, https://github.com/golang/go/issues/32437#issuecomment -500949780의 @brynbellomy의 예에 표시된 try 의 시각적 정렬에 대해 좋은 점이 있습니다.

이러한 접근 방식이 균일한 오류 장식을 위해 선택된다면 이 모든 것이 여전히 defer 와 함께 작동할 수 있습니다(또는 이론상으로 장식 기능을 등록하는 대체 형식이 있을 수 있지만 이는 별도의 요점입니다).

어쨌든 여기에서 가장 좋은 것이 무엇인지 잘 모르겠지만 다른 옵션을 명시적으로 만들고 싶었습니다.

다음은 @thepudds 가 https://github.com/golang/go/issues 에서 지적한 멋진 정렬을 유지하기 위해 var try 함수로 다시 작성된 @brynbellomy 의 예입니다. /32437#issuecomment -500998690.

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와 같은 도구에 대한 결과를 명시적으로 언급하면 ​​좋을 것입니다. 보이지 않는 오류 제어 흐름으로 인해 과소 계산되지 않을까 걱정됩니다.

@thepudds

try, b := f() else 장식

아마도 내 뇌 세포의 화상이 너무 심해서

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개의 var를 반환한다는 사실을 강조하고 우리는 하나를 마술처럼 버리고 "magic Returns 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 문은 이 경우 네이키드 리턴이 허용되지 않으므로 모든(일반적으로 0) 결과 값을 열거해야 합니다. 특히 함수가 오류를 꾸미지 않고 많은 오류를 반환하는 경우 이러한 명시적 반환( return nil, err 등)이 상용구에 추가됩니다. 현재 제안과 명시적인 return 가 필요하지 않은 대안은 이를 제거합니다. 반면에 오류를 꾸미고 싶다면 현재 제안은 오류 값에 액세스하기 위해 오류 결과에 이름을 지정하고 다른 모든 결과에 이름을 지정하도록 _요구합니다_. 이것은 명시적 핸들러에서 네이키드 리턴을 사용할 수 있고 다른 모든 결과 값을 반복할 필요가 없다는 좋은 부작용이 있습니다. (네이키드 리턴에 대해 강한 느낌이 있다는 것을 압니다. 그러나 현실은 우리가 관심 있는 모든 것이 오류 결과일 때 다른 모든(일반적으로 0) 결과 값을 열거해야 하는 것은 정말 성가신 일입니다. 코드의 이해). 즉, 오류 결과를 장식할 수 있도록 이름을 지정해야 하므로 상용구를 더욱 줄일 수 있습니다.

@magical 지적 해 주셔서 감사합니다. 나는 제안을 게시한 직후 동일한 것을 알아차렸습니다(그러나 더 이상 혼란을 일으키지 않기 위해 언급하지 않았습니다). try 는 확장할 수 없다는 것이 맞습니다. 다행히 수정은 충분히 쉽습니다. (우리의 이전 내부 제안에는 이 문제가 없었습니다. 출판을 위해 최종 버전을 다시 작성하고 기존 매개변수 전달 규칙과 더 가깝게 일치하도록 try 를 단순화하려고 시도할 때 도입되었습니다. 좋은 것 같았습니다. - 그러나 결과적으로 결함이 있고 대부분 쓸모가 없습니다. try(a, b, c, handle) 를 쓸 수 있다는 이점이 있습니다.)

try 의 이전 버전은 대략 다음과 같이 정의했습니다: try(expr, handler) 는 하나(또는 아마도 두 개) 표현식을 인수로 사용합니다. 여기서 첫 번째 표현식은 다중 값일 수 있습니다(표현식이 다음과 같은 경우에만 발생할 수 있습니다. 함수 호출). 해당(다중값) 표현식의 마지막 값은 error 유형이어야 하며 해당 값은 nil에 대해 테스트됩니다. (등 - 당신이 상상할 수있는 나머지).

어쨌든 요점은 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 문을 사용하십시오). 그러나 이것은 중요하지 않은 것 같습니다.

이 경우에는 네이키드 리턴이 허용되지 않으므로 return 문은 모든(일반적으로 0) 결과 값을 열거해야 합니다.

알몸 반환은 허용되지 않지만 시도는 허용됩니다. 내가 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. 많은 오류 검사가 필요한 비교적 간단한 여러 줄 문

그러나 try 로 각 행을 시작하는 것이 각 명령문의 중요한 부분(정의되는 변수 또는 실행되는 함수)을 방해하는 것처럼 보인다는 @ianlancetaylor 의 의견에 동의합니다. 하지만 같은 위치에 있고 너비가 고정되어 있기 때문에 여전히 눈에 띄면서 광택이 나는 것이 훨씬 쉽다고 생각합니다. 그러나 사람마다 눈이 다릅니다.

또한 코드에서 영리한 단일 라이너를 권장하는 것은 일반적으로 나쁜 생각이라고 생각합니다. 첫 번째 예에서와 같이 강력한 한 줄짜리 라이너를 만들 수 있다는 사실에 놀랐습니다. 너무 많은 일을 하기 때문에 자체 전체 기능을 사용할 가치가 있는 스니펫입니다. 하지만 축소하지 않았다면 한 줄에 맞습니다. 가독성을 위해 다중으로. 한 줄에 모두:

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 에 대해서도 비슷한 작업을 수행합니다.

이것이 전부입니다. 언어를 왜곡하는 대가로 나쁜 코드를 불법화하기 위해 너무 열심히 노력하지 말자. 기본적으로 사례별로 사람의 판단을 포함하는 것에 더 적합한 코드를 깨끗하게 유지하기 위한 다른 메커니즘이 있습니다.