나는 이것을 두 번째. 나는 모든 오류를 반환하기 전에 데코레이션하여 사람이 읽을 수 있는 문서를 소스에 추가하는 방식을 정말 좋아합니다(일반적으로 우리는 오류를 "할 수 없는 [이 코드 줄]: [이전 오류]"로 형식 지정) 및 사용자에게도 읽기 오류.

이 방법으로 생성된 오류는 스택 추적보다 매우 유익하고 읽기 쉽습니다. 스택 추적을 포함하는 인쇄된 오류는 일반적으로 소스에 대한 준비된 액세스 권한이 있고(관리자는 이러한 액세스 권한이 없을 수 있음) 실제로 코드에서 사용자의 방식을 알고 있다고 가정합니다.

어떤 형태의 컨텍스트나 추적이 없는 오류(베어 문자열 "EOF")는 절대적으로 쓸모가 없습니다. 네이키드 오류를 쉽게 반환할 수 있는 바로 가기가 있으면 Go 프로그램이 쓸모없는 오류를 많이 인쇄하게 될 것이라고 생각합니다.

만약 있다면, 우리는 새로운 수의사 및 린트 규칙을 사용하여 컨텍스트와 함께 오류를 데코레이팅하는 것을 밀어붙이고 지원해야 합니다.

나는 또한 명시적인 오류 검사를 좋아합니다. try 는 혼란스럽고 암시적 반환은 이상합니다.

오류에 대해 다시 생각하는 대신 이러한 검사를 더 짧게 만드는 다른 접근 방식을 시도할 수 있다고 생각합니다.

다음은 내가 반드시 동의하지 않는 예입니다.

value, err := foo()
return err if err != nil

이것은 더 짧지만 여전히 명시적인 접근을 허용합니다. 그리고 컨텍스트를 추가할 수 있습니다!

그렇긴 하지만 인라인 if는 Ruby이고 Goish가 별로 느껴지지 않지만 이것은 단지 브레인스토밍일 뿐입니다. 어쩌면 우리는 다른 것을 찾을 수 있습니다.

편집: 여기에 제안을 추가했습니다: https://github.com/golang/go/issues/32860

일을 하는 방법은 한 가지뿐이어야 합니다.

[...]왜 그대로 두지 않습니까?

나는 우리 모두가 이것에 대한 답을 알고 있다고 말하는 것이 공평하다고 생각합니다. 진심으로 모른다면 답을 찾으려면 다양한 제안 중 하나를 읽어보기만 하면 됩니다.

IMO, 여기에 집중 토론을 하기에는 세부 사항이 너무 적으며(즉, 제안으로 적합하지 않다고 생각합니다.) 곧 코드 가독성을 떨어뜨리는 아이디어로 가득 찬 또 다른 자전거 창고로 바뀔 것입니다. .

이만큼.

틀림없이 나는 이 명시적 오류 처리 때문에 Go에 입문했습니다. 그것은 많은 언어가 사용하는 암시적 try-catch와 사용자에게 반환되고 명시적으로 처리되는 것을 선호하는 Option 또는 Maybe와 같은 함수 유형 사이 어딘가에 있습니다.

새로운 구조가 이 문제를 정말로 해결할 수 있을지 확신할 수 없습니다. if err := nil 를 이와 같은 도우미 함수로 래핑하면 약간 도움이 될 수 있습니다(내 녹슨 Go를 용서하십시오).

func handleErr(err error, cb func(error)) {
        if err := nil {
                cb(err)
        }
}

그러나 이 도우미 함수를 일반적으로 덜 유용하게 만드는 문제는 다른 주제인 유형 시스템입니다.

나는 이것을 두 번째. if err != nil { return err } 는 우리 코드 베이스의 어떤 코드에도 포함되어 있지 않습니다. 따라서 시도 "매크로"는 전혀 의미가 없습니다. 컨텍스트를 설명하는 메시지와 함께 래핑된 오류만 반환합니다.

defer를 통해 컨텍스트를 추가하는 것도 의미가 없습니다. 다른 종류의 오류를 구별하기 위해 다른 오류 메시지를 반환하기를 원하기 때문입니다. 그러나 try(fn(), "my error message: %w") 가 유용할 수 있습니다. 그러나 그때에도 if err != nil 구문이 더 짧은 줄 길이 때문에 여전히 선호될 수 있습니다.

솔직히 저는 try 제공하는 암시적 반환을 원하지 않습니다. 제네릭이 있다면 대신 모나드 방식의 동작을 사용하는 솔루션을 훨씬 더 선호할 것입니다.

type Result<T> interface {
  Expect(err error) T
  OrElse(defaultValue T) T
}

func From<T>(value T, err error) Result<T> { ... }

나에게 이것은 현재 제안된 내장보다 훨씬 깨끗하지만 (값, 오류) 및 Result

오류를 명시적으로 장식할 방법이 없는 현재 try 제안은 내 요구를 충족하지 않습니다. 나는 그것을 사용하는 것을 상상할 수 없다. 솔직히 code_smell 좋습니다.

잘못된 문제를 해결하려고 하기 때문에 변경하는 것이 이치에 맞지 않을 수 있습니다.

우리에게 익숙한 코드는 오류 처리가 아닙니다.

if err != nil {
  return err
}

nil 처리 오류입니다. 이 패턴의 어떤 지점에서도 처리된 오류 값이 없습니다.

이것을 다른 언어로 시연한다면 Ruby.

begin
 some_method_that_raises_an_error
rescue => e # catch any exception
  retry e        # throw it up again
end

이것은 golang 코드와 동일한 동작을 전달합니다. 예외가 발생했음을 감지한 다음 다시 발생시킵니다. 우리는 그것을 스택에 던집니다.

golang에서는 return 입니다.

실제 _오류 처리_는 어디에서 발생합니까?

우리는 모두 이 패턴의 실패에 대해 비슷한 경험을 했습니다. 예를 들어, file not found 오류를 수신한 다음 이 오류의 원래 _thrower_를 추적하는 데 많은 시간을 소비합니다.

이것이 내가 try 제안(및 기타)에 결함이 있다고 생각하는 이유입니다. 실제로 오류를 처리하기 위한 좋은 패턴이 없습니다.

실제로 오류를 검사하기 위해 err.Error() 문자열 검사, 유형 주장 등을 보았습니다.
이 불일치에 대한 패턴이 필요합니다. xerrs 이 문제를 해결할 수 있을 것 같지만 아직 완전하지 않은 것 같습니다.

나는 err!=nil 체크를 있는 그대로 유지하는 것을 지지합니다.

상당한 규모의 Go 코드 기반을 파헤칠 때마다 어떻게 하면 상용구를 줄일 수 있을지 자문합니다. 나는 항상 다음으로 돌아옵니다.

• 이러한 코드 경로는 어떤 식으로든 존재합니다.
• 코드 경로를 숨길 필요가 없더라도 사람들에게 숨길 수 있는 기회를 제공하면 기본 동작이 됩니다.
• 기본 동작이 코드 경로를 숨기면 새로운 "누락된 정리" 버그를 찾고 있습니다.
• 반환된 오류의 의미와 패턴은 이 제안이 인식된 문제의 일부만 캡처할 정도로 다양합니다.
• 일부만 캡처되면 많은 솔루션을 얻을 수 있습니다.
• 많은 솔루션을 사용하면 롤업할 수 있는 유스 케이스 적응형 마법을 사용하려는 유혹이 올 것입니다.
• 이것이 실제로 문제라면 사람들은 자유롭게 자신만의 간단한 솔루션을 만들거나 대량 채택된 패턴을 사용할 수 있습니다. 나는 그런 것을 본 적이 없다. 어쩌면 내가 충분히 열심히 보지 않았을 수도 있습니다.

이슈 트래커는 많은 경우에 유용하지만 유용하지 않은 한 가지는 복잡한 주제에 대한 자세한 논의입니다. 이슈 트래커는 스레딩을 제공하지 않으며 특정 메시지에 응답하는 것이 어색합니다. 여기에는 실제 제안이 없고 다른 제안에 대한 응답일 뿐이므로 이 토론을 golang-nuts 메일링 리스트로 가져갈 것을 강력히 권장합니다.

할 수 있다면 이것이 답이라고 생각합니다. 이 새로운 오류 제안은 언어의 목표와 직접적으로 충돌합니다.

내가 golang을 좋아하는 이유는 제어 흐름의 단순성과 명확한 사용 때문입니다. Java에서 내가 가장 경멸하는 것 중 하나는 try throw 구조입니다. 정말 역겹다. 그것은 끔찍한 오류 처리를 조장합니다. 호출 스택 위로 예외를 보내는 것은 제어 흐름을 처리하는 끔찍하고 역겨운 방법입니다. 무엇보다도 자체 문서화 및 각 오류 상황의 명시적 처리 대신 모든 것을 거대한 수표로 포장하고 하루라고 부르는 것을 권장합니다.

If err != nil이 좋은 오류 처리를 권장하고 자체 문서화되며 특정 사례에 대한 좋은 문서화를 권장하며 솔직히 이것은 내가 go에 대해 가장 좋아하는 것 중 하나입니다. 지저분하고 다소 모호한 반환 및 매개변수, 혼란스러운 의미를 사용하여 이 새로운 제어 흐름을 인터럽트하게 만드는 것은 내가 좋아하게 된 언어의 정신이 아닙니다 .

장황한 것은 나쁜 것이 아닙니다. 불필요한 장황함은 있지만 go의 오류 처리가 불필요하지 않다고 주장합니다. 그것은 언어의 매력의 일부입니다.

더 동의할 수 없습니다. 명시적 오류 처리는 언어 IMO의 가장 좋은 기능 중 하나입니다. 나는 항상 그것에 대해 귀찮게하는 많은 사람들이 아직 익숙하지 않다고 느낍니다.

문제가 분리되는 것은 좋지 않지만, 이번 경우에는 두 개의 의견이 하나의 의견으로 병합되는 것이라고 생각합니다.

1. 우리는 새로운 구문을 좋아하지 않습니다(try 또는 새로운 if-err 구문)
2. 어쨌든, 우리는 새로운 구문을 추가하고 싶지 않습니다

GitHub 투표 아이콘은 두 번째를 해석할 수 없습니다.

go의 명시적 오류 처리는 내가 golang을 사랑하는 이유 중 하나입니다. 나는 왜 어떤 go 개발자가 그것을 다른 방식으로 원할지 이해하지 못합니다. 새로운 구문을 추가하자는 제안은 대부분 다른 언어에서 사용되는 구문을 사용하는 데 익숙한 사람들의 제안이라고 생각합니다. 익숙해지는 데 시간이 걸릴 수 있지만 익숙해지면 완벽하게 작동합니다.

저는 #32811을 썼고 이 제안을 더 지지합니다... 차라리 오류 처리를 그냥 두겠습니다. 이 제안에 대한 이모티콘 반응은 많은 것을 말해줍니다.

나는 개인적으로 오류 처리를 그대로 두는 데 동의합니다. 내가 Go에 대해 좋아하는 것 중 하나는 언어가 최소화되고 일반적으로 말하면 일을 하는 한 가지 방법이 있다는 것입니다. 오류 처리를 위한 새 구문을 추가하여 코드의 x%가 현재 방법을 사용하고 y%가 새 방법을 사용하는 세계를 만들 것입니다. 이는 이미 논의된 다른 문제 중에서 일관성 없는 코드 기반을 생성합니다. 저는 개인적으로 기존 구문이 충분/충분하다고 생각하기 때문에 새로운 오류 처리 구문의 가치가 절충할 가치가 있다고 생각하지 않습니다.

내가 찾을 것을 Golang, 것들 중 하나에 새로운 사람으로 언어에 대해 새로 고침하면 명시 적 오류 처리입니다. Java, Ruby, Python 및 Node에서 꽤 많이 작업했으며 오류를 처리하는 것이 Go에서보다 훨씬 더 번거롭습니다. 나는 오류를 더 모호하게 만드는 일부 언어 구성에 의해 암시되기보다 명확한 '경로' 오류를 보고 싶습니다.

ˋreturn ... if ...ˋ @andreynering 의 제안은 실제로 상당히 똑똑합니다. 상용구(한 줄짜리)를 줄이는 동안 코드를 명시적으로 유지합니다(숨겨진 제어 흐름 중단 없음).

동의합니다. if err != nil 그대로 두십시오.

현재 형식을 선호합니다. 명확하고 가르치기 쉬운 패턴입니다. 새로운 엔지니어가 하나의 간단한 패턴을 배우고 반복할 수 있으므로 속도를 높이는 것은 간단합니다. 또한 사용자에게 최소한 현재 컨텍스트에서 오류를 고려하도록 요청하여 최소한 엔지니어가 여기에서 오류가 발생할 수 있음을 인정하고 내가 무엇을 해야 하는지에 대해 생각해야 합니다.

나는 #32804를 썼고 나는 차라리 변하지 않는 것을 보고 싶습니다. 코드가 길다면 많은 일을 하기 때문입니다. 오류 처리 코드가 많다면 모든 경우를 잘 처리하고 있기 때문입니다.

단지 물건을 추가하기 위해 물건을 추가하지 마십시오.

나는 오류 처리의 단순함을 그대로 즐긴다.

기대는 단지 아나그램일 뿐이며 나는 그것을 사용하지 않을 것입니다. 시작해주셔서 감사합니다.

제 성배를 바꾸지 말아주세요.

보다 간소화된 오류 처리를 요청하는 커뮤니티 피드백이 압도적으로 많았습니다(연간 설문조사에서). Go 팀은 현재 이 문제를 해결하고 있습니다.

@icholy 물론입니다. 하지만 현재 제안은 많이 남아 있습니다. 그것들은 모두 오류 처리를 난독화하거나, 더 많은 try/catch/finally 스타일 구현으로 되돌리거나, 오류 처리를 컨텍스트에서 제외하거나, 그렇지 않으면 더 복잡하게 만드는 것 같습니다. Go는 단순한 언어이기 때문에 많은 사람들이 간단한 옵션을 원했을 것입니다. 개인적으로 마음에 드는 걸 본 적이 없어서 현재의 패턴을 유지하는 것이 더 나은 선택이라고 생각합니다.

한 가지 불만 사항은 입력해야 한다는 것이었지만 거의 모든 편집기에는 코드 조각을 삽입할 수 있는 바로 가기가 있으므로 큰 문제는 아닙니다. 아마도 1.0 이전부터 Go를 사용한 내 경험일지 모르지만 나는 단순함을 좋아하고 중복성에 신경 쓰지 않습니다.

@kevineaton try 이 복잡하다고 생각하십니까?

나는 이것에 완전히 동의합니다. 저는 개인적으로 우리가 어떤 조치를 취해야 한다고 확신하지도 않습니다. if err != nil 수표가 처음에는 얼굴을 붉힐 때 어색해 보인다는 데 동의하지만 실제로 진행 중인 바로 그 사항을 광범위하게 위반하지 않으면서 문제를 해결하는 제안을 본 적이 없습니다. 에 대한 인기.

@icholy 는 Go 이전에 Java와 Python을 작성하는 데 10년을 보낸 후 가능하다고 생각합니다. 나는 당신이 Pokemon 예외 잡기, 또는 여러 예외의 catch chaining에 부딪치고 그렇지 않으면 더 많은 오버헤드와 상용구를 도입한다고 생각합니다. 나는 그것을 피할 수만 있다면 그 스타일의 오류 처리로 돌아가지 않을 것입니다. 특히 가르칠 때 거의 항상 두통과 혼란을 야기하기 때문입니다. 또한 소프트웨어 설계자로서의 일상 업무 외에 컴퓨터 과학을 가르치기 때문에 새로운 개발자를 가르치고 멘토링하는 데 편향되어 있습니다. Go를 선택하면 더 복잡하거나 미묘한 오류 처리보다 단순한 오류 처리입니다.

이슈 트래커는 많은 경우에 유용하지만 유용하지 않은 한 가지는 복잡한 주제에 대한 자세한 논의입니다.

_그것은_ 진실이 아닙니다. 하지만 여기 있습니다.

if err != nil 는 try 를 추가해도 사라지지 않습니다. try 는 오류 전달이 많거나 많은 다른 오류가 하나의 지연 오류 처리기에서 쉽게 요약될 수 있는 코드 경로에 약간의 명확성을 추가할 것이라고 믿습니다. . try 가 빈 if-err-return-err 의 무리보다 훨씬 더 많은 오류를 처리하지 않도록 권장하는 방법을 모르겠습니다. try 가 있든 없든 실제로 오류를 처리하는 것을 무시하기 쉽습니다. 나는 try 가 그것을 사용하는 코드를 읽기 쉬울 것 같기 때문에 아직까지 오류 처리를 위한 최고의 제안 중 하나라고 생각합니다.

내 요청하지 않은 2센트, 그것은 그다지 "가는" 느낌이 아닙니다. 너무 마술적이어서 우리는 명시적 구성보다 암시적 구성을 사용하려고 합니다.

Go FAQ에서

Go에 ?: 연산자가 없는 이유는 무엇입니까?
_Go에는 삼항 테스트 작업이 없습니다. 다음을 사용하여 동일한 결과를 얻을 수 있습니다._

if expr {
   n = trueVal
} else {
    n = falseVal
}

Go에서 ?:가 없는 이유는 언어 설계자가 작업이 너무 자주 사용되어 꿰뚫을 수 없을 정도로 복잡한 표현식을 만드는 것을 보았기 때문입니다. if-else 형식은 더 길지만 의심할 여지 없이 더 명확합니다. 언어 에는 조건부 제어 흐름 구조 가 합니다 .

@ianlancetaylor

이슈 트래커는 많은 경우에 유용하지만 유용하지 않은 한 가지는 복잡한 주제에 대한 자세한 논의입니다. 이슈 트래커는 스레딩을 제공하지 않으며 특정 메시지에 응답하는 것이 어색합니다. 여기에는 실제 제안이 없고 다른 제안에 대한 응답일 뿐이므로 이 토론을 golang-nuts 메일링 리스트로 가져갈 것을 강력히 권장합니다.

특정 메시지에 답장할 수 있습니다. 나는 방금 당신에게 대답했습니다. :)

여기에는 실제 제안이 없고 다른 제안에 대한 응답만 있으므로,

나에게 제안이란 변화를 요구하는 것입니다. 이 특정 문제는 변경 방지입니다. 오류 처리를 변경하지 _않도록_ 제안하시겠습니까? 나는 제안 시스템이 훌륭하다고 생각하지만 현상 유지가 과소 대표됩니다.

Java 및 Python을 작성하는 데 10년을 보낸 후 ... 저는 소프트웨어 설계자로서의 일상 업무 외에 컴퓨터 과학도 가르칩니다.

@kevineaton 자기 거시기 빨기 다 됐어?

이 문제는 기본적으로 누구나 쉽게 제안에 대해 찬성 또는 반대 투표를 할 수 있는 반공식적인 장소에서 장기간 진행되는 투표의 기능을 합니다.

if err != nil 를 제거하기 위해 언어를 변경하지 않는 것은 기본적으로 추가 세부 사항이 필요하지 않은 완벽하게 큰 제안입니다. 문제가 무엇인지 잘 모르겠습니다. 아니요, 신이 끔찍하고 길지 않습니다. 그것이 틀리거나 나쁘거나 불충분하지 않습니다.

+1, 더 나은 것이 없다면 좋은 것은 정말 좋은 스택 추적 정보(프레임 댄스 항목 제외)가 될 것입니다. x/errors 이미 이것을 달성한 것 같습니다. 그러나 가까운 장래에 마킹과 같은 신속한 것을 원합니다 func error + try 키워드를 반환하는 throws 키워드를 사용하여

func a() (int) throws {
  throw &someError{}
}

anInt, err := try a()

@icholy 정말

현재 오류 처리는 사람이 실수하기 쉽습니다. 현재 err 를 확인하는 것을 잊어버리기 쉽습니다. 범위에 이미 검사가 있는 경우(대부분의 경우) 컴파일러는 unused variable 종료되지 않습니다. 오류 처리는 엄격해야 합니다. _ 오류를 확인하거나 오류를 확인하십시오.

@kevineaton try 이 복잡하다고 생각하십니까?

try 는 코드 냄새입니다. 한 지점이 아닌 전체 코드 블록 사이에 들여쓰기를 강제합니다. 게다가 예외 처리의 "버블업(bubble-up)" 특성은 코드 및 여러 종료 지점에서 사실상 비결정적 동작을 생성합니다.

try 대신 여러 반환 값을 사용하는 장점은 함수가 완료될 때 확인할 값이 하나 있고 함수의 종료 지점이 하나 있다는 것 입니다(물론 가드 문이나 기타 명시적 반환을 사용하지 않는 한).

try 블록은 다중 반환의 전체 목적을 무효화합니다.

@fillest 코드 가독성이 조금

현재 오류 처리는 사람이 실수하기 쉽습니다. 순간에 오류를 확인하는 것을 잊는 것은 쉽습니다. 범위에 이미 검사가 있는 경우(대부분의 경우) 컴파일러는 사용되지 않은 변수로 종료되지 않습니다. 오류 처리는 엄격해야 합니다. _ 오류를 확인하거나 확인해야 합니다.

@fillest 오류 처리에 제안된 변경 사항은 "레그슈팅"을 더 쉽게 만들고 오류를 느리게 처리할 수 있기 때문에 더 두드러집니다.

나는 제네릭 부족, 상용구 성향, GC, 리소스 제한/회계 부족 및 컴파일러가 하는 일을 이해하지 못하는 PHP 멍청이들로부터 생성된 워크로드 때문에 Go 사용을 중단했습니다. Haskell, C# 및 기타는 오류 처리를 꽤 잘 해결했습니다... Go 2 제안이 이전과 같이 명시적인 대소문자 처리가 있는 경우(확실하지 않음) 괜찮아 보입니다.

오류 처리는 프로그래밍의 핵심입니다. 비즈니스 로직을 모델링하는 것은(아무리 복잡하더라도) 이 로직이 생성하는 잘못된 조건에 응답하는 것보다 항상 간단합니다. 단순히 오류를 전달하는 것은 코드 냄새입니다. Go가 이러한 행동을 장려하지 않고 오류 관리 패턴을 장려하기를 바랍니다. 초보자는 오류 관리가 어떻게 중앙 집중식인지 깨닫지 못했기 때문에 이 모든 오류 처리 코드와 혼동되는 경우가 많습니다.

try 내장은 오류를 감싸고 정보를 추가하는 데 약간의 도움이 되지 않기 때문에 전적으로 동의합니다.

try 다시 쓰기 전에 :

_, err := doSomething()
if err != nil {
    return nil, errors.Wrap(err, "failed to do something")
}

_, err = doOtherThing()
if err != nil {
  return nil, errors.Wrap("failed to do the other thing")
}

try 다시 작성한 후의 결과를 상상해 보십시오.

try 이미 인수를 괄호로 묶어 1인자 함수처럼 작동하므로 오류 래핑 코드인 두 번째 인수를 받아들일 수 있습니다.

try(extract_value(try(get_data(1), errors.Wrap(err, "failed to get data")), errors.Wrap(err, "failed to get data")))

err 값이 암시적으로 도입되어야 하는 경우(위생적인 방식으로). 그런 다음 try 가 1-인수 함수로 사용되면 변경되지 않은 오류를 반환합니다.

동의합니다. 오류 처리를 조금 더 단순하게 만들 수 있는 유일한 "구문적 설탕"은 함수에서 여러 반환이 있을 때 다음과 같은 작업을 수행할 수 있도록 하는 것입니다... 밑줄은 반환 유형이 무엇이든 기본값일 뿐입니다.

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

@sorenvonsarvort 나에게 그렇게 나쁘지 않은 것 같습니다.

var errContext string 

defer func() {
  // err is a named return
  if err != nil {
    err = fmt.Errorf("%v: %w", errContext, err)
  }
}()

errContext = "failed to do something"
_ := try(doSomething())

errContext = "failed to do other thing"
_ := try(doOtherThing())

내 이해에 따르면 코드의 특정 섹션에 대해 더 명확하다면 if err != nil { ... } 계속 사용할 수도 있습니다.

try 는 다른 경우에 빛납니다. 다음과 같은 것을 상상해보십시오.

func trySomeComplexOp() (r result, err error) {
  a := try(step1())
  b := try(step2(a))
  c, d := try(step3(b))
  return try(lastStep(c, d)), nil
}

위의 코드와 같은 코드는 if err != nil 블록에 뿌려야 하는 것보다 훨씬 깨끗할 수 있습니다. Go는 "선형 가독성"에 관한 것이므로 try 가 그런 방향으로 잘 작동한다고 생각합니다.

보다 간소화된 오류 처리를 요청하는 커뮤니티 피드백이 압도적으로 많았습니다(연간 설문조사에서). Go 팀은 현재 이 문제를 해결하고 있습니다.

이것은 소수의 보컬이며 그들 중 상당수는 Go를 사용하지도 않습니다.

@sirkon 그 진술의 근거는 무엇입니까?

@sorenvonsarvort 나에게 그렇게 나쁘지 않은 것 같습니다.

위의 코드와 같은 코드는 if err != nil 블록에 뿌려야 하는 것보다 훨씬 깨끗할 수 있습니다. Go는 "선형 가독성"에 관한 모든 것이므로 try 가 그런 목적으로 잘 작동한다고 생각합니다.

러시아에서는 이것을 «экономия на спичках»라고 부릅니다. Google 번역을 사용하여 의미를 얻으십시오.

아직 읽지 않은 이 스레드의 경우 원래 try 제안 문제에 대한 이 의견 을 읽는 것이 좋습니다. 일반적인 오류 컨텍스트 모범 사례와 이를 try 로 표현하는 방법에 대해 설명합니다.

나는 아마도 오류 컨텍스트가 Go 커뮤니티에서 약간 독단화되었다고 생각합니다. 나는 개인적으로 이것에 빠졌고 내 오류를 과도하게 맥락화하여 메시지가 매우 길고 반복적이며 읽기 어렵다는 것을 알고 있습니다. 오류를 맥락화해야 할 때와 하지 말아야 할 때와 관련하여 많은 뉘앙스가 있습니다.

try 는 기본적으로 바로 가기이며 일부 상용구 코드를 줄여줍니다. 그러나 추가 정보로 오류를 감쌀 수 있는 능력을 잃게 됩니다. 그러나 다음 변경 사항으로 문제가 해결될 수 있습니다.

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

된다

f := try(os.Open(filename), "open data file")

물론, 그보다 더 많은 작업을 수행해야 하는 경우 err != nil 검사를 수행하는 "전체" 방법을 계속 사용할 수 있습니다.

이에 동의하지만 최종 의견을 듣기 전에 변경 사항을 더 많이 경험해 달라는 go 팀의 요청을 존중하겠습니다.

그러나 변화에 대한 나의 예비 경험은 그것이 정말로 불필요하다는 것을 뒷받침하는 것 같습니다. 나는 각각 약 10,000개의 라인이 있는 2개의 "실제" 프로그램을 가지고 있으며 두 프로그램 모두에서 tryhard 를 실행 tryhard 는 그 중 하나에서 try 를 사용할 수 있는 1개의 경우를 찾았지만 그게 전부입니다.

나는 다른 사람들이 나와 다르게 오류를 취급할 수 있음을 인정하고 try 가 긍정적인 방식으로 사용될 수 있다는 가능성을 인정합니다. tryhard 소스 코드 자체에는 return err 의 연속적인 경우가 있습니다. try 를 사용하면 가독성이 그다지 손상되지 않을 것이라고 생각합니다. 그러나 오용이 가독성에 영향을 미치기 때문에 오용이 두렵습니다. 여기에 좋은 예가 제공

또한 사람들이 스스로 go를 프로그래밍하지 않더라도 일반적으로 go 코드를 읽을 수 있는 방식을 좋아합니다. 이것은 그들이 다른 언어에서 본 다른 try 와 다른 일을 하기 때문에 특히 try 가 하는 마법을 배워야 합니다. 이것은 언어를 처음 접하는 사람들에게도 해당되며, "필요한 기능만"이 있는 단순함을 자랑스럽게 여기는 언어로 배워야 하는 또 다른 기능입니다.

기다리고 보자. 이 변경 사항을 더 많이 실험해 보겠습니다. 하지만 내 위치가 변경될지 확신하지 못합니다.

보다 간소화된 오류 처리를 요청하는 커뮤니티 피드백이 압도적으로 많았습니다(연간 설문조사에서). Go 팀은 현재 이 문제를 해결하고 있습니다.

@icholy 내가 말했듯이, 나는 오류에 컨텍스트를 추가하고 싶습니다. 그런 점에서 "더 간소화된 오류 처리"는 해당 컨텍스트를 제공하고 정보를 얻을 수 있는 더 나은 방법을 의미합니다. 예를 들어, 내 오류에 추가한 모든 컨텍스트에서 오류가 시간 초과로 인해 발생한 경우 "컨텍스트"를 묻는 것은 간단해야 합니다. 하지만 그렇지 않습니다. 일반적으로 pkg/error 를 사용하고, 자신만의 "오류 구조"를 만들거나 구현에 따라 문자열 검색에 의존할 수 있는 작업 방법을 만들어야 합니다. 기껏해야 아주 가끔 if 하나를 절약하는 것보다 전체 구조체와 메서드를 만드는 데 도움이 되는 것을 보고 싶습니다. 그리고 이전에 말했듯이 이 변경이 기본적으로 오류를 실제로 처리하지 않는 더 편리한 방법을 제공할 때 이를 "오류 처리"라고 부를 수 있습니까?

try 이 복잡하다고 생각하십니까?

try 를 따로따로 보면 복잡하지 않지만 언어 변경은 따로 고려하지 않습니다. 고려하다:

• 새로운 내장의 의미를 학습하여 인지 부하 증가
• if err != nil {return ... errors.Wrap() } 를 대신 사용해야 하는 경우 더 짧아서 try 사용으로 인한 가독성 감소

나는 오류를 확인하는 간단한 방법보다 단순함(오류를 확인하는 단일 방법을 갖는 것)이 더 중요하다는 감정을 상기합니다.

오류를 처리하는 go의 방법은 해당 전역 문을 통한 것이 아니고 이것이 무시되어야 하는 것이라면 패닉 상황은 어떻게 처리됩니까? 다른 프로그래밍 패러다임이 오늘날 오류를 처리하지만 무시하지 않기 때문에 더 나은 오류 처리를 지원합니다.

try 제안에 문제가 없다고 생각하십니까?
이전 동작을 사용하거나 다른 방식으로 오류를 처리해야 하는 경우 이전 방식을 다시 사용하지 않는 이유는 무엇입니까? try 구문을 사용하여 목에 칼을 대고 누르는 사람이 없습니까?
try 구문은 간단하고 상용구 코드를 줄이는 아름다운 방법입니다. gopher가 새디즘 방식을 좋아하는 이유를 모르겠습니다.

블록이 한 줄에 남아 있으면 한 문장으로 gofmt가 변경되면 어떻게 될까요?

그렇게 하면 대부분의 경우에 3줄이 아닌 한 줄만 처리하는 래핑된 오류를 처리할 수 있습니다. 이렇게 하면 오류 처리가 차지하는 수직 공간이 줄어들고 오류 처리가 평균 함수에서 수직 공간의 절반 이상을 차지하지 않는 것처럼 보입니다.

다음과 같이 표시됩니다.

// we already have an err in scope
err = frub.Confozzle(foo, bar, baz)
if err != nil { return errors.Wrap(err, "confozzling didn't work") }

나는 아마도 오류 컨텍스트가 Go 커뮤니티에서 약간 독단화되었다고 생각합니다. 나는 개인적으로 이것에 빠졌고 내 오류를 과도하게 맥락화하여 메시지가 매우 길고 반복적이며 읽기 어렵다는 것을 알고 있습니다. 오류를 맥락화해야 할 때와 하지 말아야 할 때와 관련하여 많은 뉘앙스가 있습니다.

오류 래핑 및 스택 프레임/오류 인쇄 작업은 훨씬 더 간단해집니다. 시간이 지나면 이에 대한 좋은 솔루션이 있을 것이라고 생각하지만 지금은 아닙니다. 개인적으로 나머지 기능을 설계할 때 잠재적으로 유용할 수 있기 때문에 매개변수 다형성이 해결될 때까지 더 강력한 go2 기능을 도입하는 것을 기다리는 것을 선호합니다.

그대로 두는 것에 전적으로 동의합니다. 약간 너무 장황하지만 따라하기에는 꽤 간단합니다.

줄일 수만 있다면

if err := foo.x(a, b); err != nil {
    return err
}

if err := foo.y(); err != nil {
    return err
}

if err := foo.z(c); err != nil {
    return err
}

뭔가에

if err := check foo.x(a, b), foo.y(), foo.z(c); err != nil {
    return err
}

관용구를 너무 많이 변경하지 않고 IMHO도 좋을 것 입니다.

@henvic 나는 당신이 같은 방식으로 세 가지 오류를 처리하기를 원한다고 가정한다는 것이 문제라고 생각합니다. Go는 각 오류를 개별적으로 처리하는 방법에 대해 생각하도록 강요합니다. 별도의 오류 검사를 하면 이를 명확하게 알 수 있습니다. 그것들을 하나로 통합하면 개발자가 인지적으로 돌아가 확인해야 합니다. 이러한 오류를 _정말_ 동일한 방식으로 처리해야 할까요? 나는 이 제안을 통해 우리가 명확성을 잃어버리고 몇 번의 키 입력이 덜한 오류에 대해 강제로 생각해야 한다고 생각합니다.

@sanbornm , 당신이 맞습니다. 나는 동의한다.

이 check 도 checkNonZero 연산자일 수 있습니다. 이 연산자는 반환 인수를 하나만 사용하고 0이 아닌 첫 번째 값(예: null)에서 반환합니다. 그러나 너무 모호하고 언어에 훨씬 더 영향을 미칩니다. 예를 들어 io.EOF가 예상되는 경우 사용해서는 안 된다는 힌트를 약간만 줄 뿐입니다. 또 다른 가능성은 아마도 go vet 를 사용하여 가장 일반적인 경우(예: 파이프에서 읽을 때 io.EOF)를 알려주는 것입니다... 하지만 이 아이디어는 잘 들리지 않습니다. 모두 나에게.

try 제안에 문제가 없다고 생각하십니까?
이전 동작을 사용하거나 다른 방식으로 오류를 처리해야 하는 경우 이전 방식을 다시 사용하지 않는 이유는 무엇입니까? try 구문을 사용하여 목에 칼을 대고 누르는 사람이 없습니까?
try 구문은 간단하고 상용구 코드를 줄이는 아름다운 방법입니다. gopher가 새디즘 방식을 좋아하는 이유를 모르겠습니다.

우리는 모두 공동체 속에 살고 있습니다. 매일 나는 다른 사람들이 작성한 많은 코드로 작업합니다. 그래서 언어의 변화는 내가 그것을 사용하지 않더라도 나에게 영향을 미칠 것입니다.

대규모 프로젝트에서 최악의 로그는 "Pokemon" 예외 핸들러가 처리할 때까지 아무 것도 포착하지 못한 일반 new Exception() 를 던진 라이브러리를 호출하는 라이브러리를 호출하는 라이브러리를 호출하는 누군가 작성하는 것을 잊어버린 함수에 의해 생성됩니다. 일반 오류를 기록했습니다. 두 번째로 나쁜 것은 동일하지만 수백 줄의 스택 추적이 불가해한 관계로 결국 원인을 파악할 수 있다고 생각합니다(다행히 github.com/<us>/<ourproject> 검색하는 것만으로도 대부분의 관련 정보를 찾을 수 있지만 가끔 많이). 이름에도 불구하고 "예외"는 큰 Java 프로젝트에서 비참할 정도로 예외적입니다.

한편, 중복 컨텍스트가 많은 경우에도 "narf: Error unpoiting the zort: foo: Unexpected bar in baz: {\"ork\": \"morpork\"}" 와 같은 간단한 Go 오류 문자열은 (내 경험상) 중요한 컨텍스트를 실제 오류 값. 중요한 컨텍스트가 누락된 것으로 판명되면 이는 _또한_ 일반적으로 상당히 분명합니다. 이러한 경우 "수정"은 더 많은 컨텍스트를 추가하고 다른 오류를 기다리는 것이므로 완벽하지는 않지만 균형을 유지하면서 스택 추적을 스크롤하거나 "throw"에 대한 종속성의 종속성에 의존하는 것보다 여전히 이것을 선호합니다. " 또는 "발생" 정상적인 오류 메시지. panic() 라는 이름이 대부분의 Go 개발자가 본질적으로 동일한 언어 기능을 자유롭게 배포하는 것을 막는 것처럼 보이는 것에 대해 정말 감사합니다. error 와 panic 결국 같은 것으로 만들지 맙시다.

나는 때때로 함수에 12개 정도의 실패 모드가 있고 그 대부분이 동일한 오류 메시지를 받을 자격이 있는 상황에 부딪쳤습니다. 반복은 저를 귀찮게 하지 않지만 일반적으로 저희 팀에는 귀찮게 하는 다른 사람이 있으므로 일반적인 오류를 처리하기 위해 함수 시작 시 클로저를 선언하여 절충합니다.

func foo(a, b, c SomeArgType) (x, y, z SomeReturnType, err error) {
  handleError := func(handleErr error) (x, y, z SomeReturnType, err error) {
    log.WithFields(logrus.Fields{
      "package": "foo",
      "func": "foo",
      "arguments": map[string]SomeArgType{"a": a, "b": b, "c": c},
      "error": handleErr,
    }).Error("Error fooing the bar")
    return reasonable, default, values, handleErr
  }

  err := doABunchOfThings()
  if err != nil {
    return handleError(err)
  }
}

물론 이것은 _여전히_ 어떤 면에서 불완전한 솔루션입니다. 하지만 이렇게 하면 제어 흐름이 너무 많이 뛰어다니지 않고도 미래의 개발자가 foo 가 언제 그리고 무엇을 반환하는지 이해할 수 있다는 점이 마음에 듭니다.

어떻게 해서든 이 반복 "문제"가 환원 불가능하게 복잡한 패키지의 환원 불가능하게 복잡한 소수의 기능에 국한되지 않고 수많은 패키지 전체에서 매우 일반적이라면 프로젝트 전체의 "펑터"를 다음과 같이 사용할 수 있습니다. 비슷한 끝, 그리고 (한숨) 매개변수 유형의 개념이 언어에 추가되면 try/catch에 의존할 필요 없이 오류 처리 공장 뒤에 훨씬 더 자세한 정보를 숨길 수 있습니다.

@thomasf

오류 래핑 및 스택 프레임/오류 인쇄 작업이 훨씬 더 간단해집니다.

나는 동의한다.

개인적으로 나는 파라메트릭 다형성이 나머지 기능을 디자인할 때 잠재적으로 유용할 수 있기 때문에 더 강력한 go2 기능을 도입할 때까지 기다리는 것을 선호합니다.

원래 try 제안서의 몇몇 사람들은 제네릭 대기에 대해서도 논의했지만 매개변수적 다형성이 try 제안서를 어떻게 다르게 만들지 나에게는 명확하지 않습니다. 이미 내장되어 있기 때문에 우리가 언어로 표현할 수 있는 것의 한계에 국한되지 않습니다.

@icholy

보다 간소화된 오류 처리를 요청하는 커뮤니티 피드백이 압도적으로 많았습니다(연간 설문조사에서). Go 팀은 현재 이 문제를 해결하고 있습니다.

이것에 응답하기 위해; 또한 영국에서는 브렉시트를 찬성하는 과반수가 있었습니다. 물론 EU도 일반 대중이 반응한 몇 가지 불리한 점이 있다. 그러나 모든 대안이 제기되면 결국 EU에 머무르는 것이 그렇게 나쁘지 않을 것 같았습니다.

이제 이것을 정치화하려는 것은 전혀 내 의도가 아니며, 당신은 위의 내용에 동의하지 않을 수도 있습니다. 그러나 내가 보여주고자 하는 것은 대다수가 처음에 어떤 것을 성가신 것으로 간주하더라도 모든 대안을 검토한 후에는 여전히 최상의 솔루션이 될 수 있다는 것입니다.

나는 오류 처리에 대해 강한 의견을 갖고 있지는 않지만, 그것은 있는 그대로 두는 것에 대한 논쟁이 될 수 있습니다.

전문적인 코딩 환경에서 우리는 현재의 오류 처리 방식을 활용하여 추적 시스템에 주석을 달고 로그를 장식합니다. 제쳐두고, 암시적 반환은 즉각적인 흐름 제어 가독성을 흐리게 한다는 점에서 내보낸 라이브러리 함수에서 패닉을 사용하는 것과 비슷합니다.

@icholy

보다 간소화된 오류 처리를 요청하는 커뮤니티 피드백이 압도적으로 많았습니다(연간 설문조사에서). Go 팀은 현재 이 문제를 해결하고 있습니다.

이것에 응답하기 위해; 또한 영국에서는 브렉시트를 찬성하는 과반수가 있었습니다. 물론 EU도 일반 대중이 반응한 몇 가지 불리한 점이 있다. 그러나 모든 대안이 제기되면 결국 EU에 머무르는 것이 그렇게 나쁘지 않을 것 같았습니다.

이 사람의 주장을 심각하게 고려할 필요는 없습니다. 이모티콘 수는 사람들이 일반적으로 try 제안을 좋아하지 않으며 일반적으로 "있는 그대로 두는" 제안을 좋아한다는 것을 보여줍니다.

내 실습에서 PS 메인 도메인(네트워크 서비스, CLI 유틸리티)에서 Go를 싫어하는 대다수의 사람들은 사용조차 하지 않습니다. 그래서 나는 그들의 의견을 무시하고 싶습니다.

우리는 try 제안보다 더 좋고 덜 논란의 여지가 있는 옵션이 필요합니다.
나는 성급한 해결책이 시급하다고 보지 않습니다.

@velovix 나는 try/catch 오류 "처리"보다 매개변수 다형성을 더 싫어한다고 생각하지만 그것이 언어 기능이 된다면 다른 내장 언어 기능에 대한 필요성을 피할 수 있는 몇 가지 방법을 볼 수 있습니다.

한 가지 예로, 사람들이 반복하고 싶지 않은 코드는 다음과 같은 상용구입니다.

foo, err := Foo()
if err != nil {
  log(err)
}
bar, err := Bar(foo)
if err != nil {
  log(err)
}
// ...

그러면 매개변수 함수, 유형 추론, _아마도_ 또는 _선택적_ 스타일의 객체 디자인 패턴의 일부 조합이 이상한 비선형 제어 흐름 전략에 의존하지 않고 상용구를 간단하게(헤) 줄일 수 있습니다.

func<T> DoWithErrorLogging(f func(any...) (T, error), args... any) T {
  t, err := f(args...)
  if err != nil {
    log(err)
  }
  return t
}
// ...
foo := DoWithErrorLogging(Foo)
bar := DoWithErrorLogging(Bar, foo)

IMO는 이 모든 것이 Go1보다 훨씬 더 나쁠 것입니다. 그러나 언어에서 이 _plus_ try/catch 키워드를 사용하는 것보다 낫습니다.

솔직히... 현재 상황에서 Go2에 대한 내가 가장 좋아하는 "중단" 변경 사항은 net/http 기본값이 변경 가능한 공유 전역 안에 중첩되는 가변 공유 전역과 같은 Go1의 모든 작은 불편을 해결할 것이라고 생각합니다. 기본적으로 Hashicorp의 cleanhttp 표준을 만들거나 (*time.Timer).Reset() 에 대해 알아야 할 쓸모없는 반환 값 을 가지거나 전체 syscall 패키지를 만들 수 있습니다. Go3는 사람들이 자라기를 원하는 종양과 함께 거의 즉시 출시될 수 있습니다. 작고 큰 주요 변경 사항을 단일 릴리스에서 모두 수행해야 하는 이유를 모르겠습니다.

나는 try ...을(를) 드물게 사용합니다. 나는 인기있는 프로젝트가 try를 사용해도 괜찮은 경우에 대한 지침을 추가할 것이라고 생각합니다. 그리고 소규모/신규/1인 프로젝트는 try 로 인해 가끔 잘못된 오류로 인해 사용 부족을 겪을 것입니다.

언어에 try 를 추가하는 것이 그렇게 끔찍하다고 생각하지 않습니다. 사람들의 최악의 경우에 대한 두려움이 근거가 있는 것으로 판명되면 그 사용은 눈살을 찌푸리게 될 것입니다. 경험이 없는 사람들은 그것을 무분별하게 사용할 것이고 다른 사람들은 그렇지 않을 것입니다. 세상의 끝이 아닙니다.

try 가 추가되면 경우에 따라 사용하게 될 것 같습니다. 이러한 경우는 오류가 반환되지만 실제로 오류가 있을 가능성은 매우 낮아 컨텍스트 추가의 요점을 알지 못하고 단순히 오류를 있는 그대로 반환합니다. 예를 들어 1TB로 알고 있는 디스크를 채우는 파일 시스템을 방금 생성했다면 1kb 파일이나 디렉토리를 생성할 공간이 있다고 확신할 수 있습니다. 그것이 실패하면 오류를 무시하고 싶지 않습니다. 다른 곳의 버그, 하드웨어 오류 등을 나타낼 수 있습니다. 그러나 모든 미친 가능성이 있는 오류에 주석을 추가하는 데 노력을 기울일 가치가 없습니다.

나는 try(..)가 타이핑할 때 생각할 수 있도록 코더의 마인드 스택에 한 쌍의 괄호/대괄호를 추가하는 방식이 마음에 들지 않습니다. 그리고 내가 상상할 수 있는 가장 긴 시간 동안!

그래서 이것은 더 좋습니다:
값, 오류 := foo()
err != nil이면 오류를 반환합니다.

그러나 이것은 여전히 ​​일반적입니다. 그래서 나는 이와 같은 sm이 어떻게 든 가능할 수 있기를 바랍니다.

값, 오류 확인 := foo()

Go가 읽을 수 있는 언어가 되고 싶다면 읽거나 이해하기 어려운 생각을 할 수 있는 능력을 최소화해야 합니다.

Go가 좋은 오류 처리를 원하면 오류가 호출 스택을 올라갈 때 추가 컨텍스트를 갖도록 권장해야 합니다. defer를 사용하여 오류를 처리해야 하는 요구 사항은 혼란스러워 보입니다. 오류 처리기에 오류가 있으면 어떻게 합니까? Defers는 스택 순서로 실행됩니다. 핸들러를 역순으로 선언해야 합니까?

If 문은 간단하고 여기에 모호성을 위한 여지를 거의 남겨 두지 마십시오. try 가 실제 엔지니어링 문제라기 보다는 핵심을 해결하는 것 같습니다. 나는 이 제안을 좋아하는데, 침묵하는 다수가 이러한 복잡한 제안의 모든 측면을 완전히 이해하지 못한 채 마침내 성명을 발표할 수 있기 때문입니다.

@icholy 정중히 부탁드립니다. Gopher 행동 강령: https://golang.org/conduct를 숙지

여러분: 위의 제 댓글(https://github.com/golang/go/issues/32825#issuecomment-506740412) 외에도 https://golang.org/wiki/NoPlusOne을 알아두시기 바랍니다. '동의합니다' 또는 '동의하지 않습니다' 정도의 댓글을 작성하는 것은 도움이 되지 않습니다. 대신 이모티콘 버튼을 사용하세요. 감사 해요.

@sanbornm

(나는 메시지에 답장을 보낼 수 있다는 점에 동의한다. 나는 그것이 어색한 것이지 불가능한 것은 아니라고 말했다. 그리고 이 작은 쓰레드가 다른 댓글의 눈보라 속에서 길을 잃는다는 점에서 쓰레드에 대한 나의 요점은 여전히 ​​유효하다.)

나에게 제안이란 변화를 요구하는 것입니다. 이 특정 문제는 변경 방지입니다. 오류 처리를 변경하지 않는 제안을 생성할 것을 제안합니까? 나는 제안 시스템이 훌륭하다고 생각하지만 현상 유지가 과소 대표됩니다.

제안 B를 채택하지 말아야 한다는 제안 A를 만들 필요는 없습니다. 대신 제안 B에 투표하십시오. 제안 B에 대한 자세한 논의는 해당 제안 또는 메일링 리스트를 사용하십시오.

(이 경우 제안 B가 잠겨 있음을 이해합니다. 이 제안에 하루도 채 되지 않는 기간에 77개의 댓글이 있다는 사실이 그 이유를 보여줍니다. 이 수준의 토론은 문제 추적기보다는 메일링 리스트에서 더 잘 작동합니다.)

@ianlancetaylor

(나는 메시지에 답장을 보낼 수 있다는 점에 동의한다. 나는 그것이 어색한 것이지 불가능한 것은 아니라고 말했다. 그리고 이 작은 쓰레드가 다른 댓글의 눈보라 속에서 길을 잃는다는 점에서 쓰레드에 대한 나의 요점은 여전히 ​​유효하다.)

충분히 합리적입니다. 메일링 리스트는 훌륭하지만 개인적으로 이 경우 GitHub를 통해 기여하는 것이 더 쉽다는 것을 알게 되었습니다. 현재 오류 처리가 훌륭하고 그대로 유지되기를 바랍니다. 이모티콘/투표는 이에 적합합니다. 100명의 "투표"로 충분할 메일링 리스트에 100명이 "오류 처리를 그대로 두십시오"라고 쓰는 것을 원하지 않을 것입니다.

이 문제는 잠겨 있기 때문에 더 이상 이모티콘으로 "투표"할 수 없습니다. 그렇기 때문에 이 문제가 처음부터 만들어졌다고 생각합니다.

부수적이지만 관련된 종속성 관리가 제대로 처리되지 않았습니다. Dep은 훌륭하게 작동했고 go mod가 갑자기 선택되었습니다[1]. 이것이 제안 시스템이 만들어진 이유임을 이해합니다. 이 경우 제안 시스템이 문제가 잠겨 있고 메일링 리스트로 이동하라는 지시를 받으면 커뮤니티를 과소 대표할 수 있다고 생각합니다.

[1] https://twitter.com/_rsc/status/1022588240501661696

편집: Go 팀과 커뮤니티는 대부분 커뮤니티 피드백을 경청하는 놀라운 일을 합니다. 나는 그것에 들어가는 모든 작업에 감사드립니다. Go 설문조사가 좋은 예입니다.

@sanbornm

Dep은 훌륭하게 일했습니다.

여기에 동의하지 않을 필요가 있습니다. Go 모듈은 마침내 https://proxy.golang.org 의 영구 캐싱으로 잘 알려지지 않은 "gobindata" 문제를 해결했습니다.

그 dep 친구는 문제를 인식하지도 못하고 대신 VCS를 통해 멋진 "보장"을 가지고 놀고 있었습니다.

@sirkon 이것은 약간 벗어난 주제이지만 Dep과 같은 벤더 dep라면 그런 것은 필요하지 않습니다.

한 줄에 1개의 try 문과 같이 더 많은 제약 조건이 추가되지 않는 한 그대로 두는 것이 낫다고 생각합니다. 이유는 제안 에서 이 예를 고려하기 때문입니다. info := try(try(os.Open(file)).Stat()) 만큼 무해해 보이지만 정상적인 제어 흐름의 범위를 넘어 파일 핸들이 누출됩니다. io.Closer 구현 또는 사람들이 더 간결한 코드를 추구하기 위해 회피할 수 있는 기타 정리 기능으로 파일 리소스 누수가 증가할 것이라고 생각합니다.

f가 더 이상 작동하지 않아 즉시 GC에 적합하고 어느 시점에서 종료자가 f가 닫혀 있는지 확인하기 때문에 일부 사람들은 이것이 중요하지 않다고 생각할 것입니다. 나는 그것이 기능 블록에 묶인 오늘 defer를 사용하는 이전의 명확한 (린터 지원) 규칙을 변경한다고 생각합니다. 기능 블록이 종료되면 리소스가 해제됩니다. 가비지 수집기에 의존한다고 해서 리소스를 소진하지 않는다는 보장은 없습니다(일반적인 파일 열기 핸들 제한 기본값은 1k에서 4k 사이일 수 있음). 이는 파일을 닫지 않는 간단한 filepath.Walk로 쉽게 초과됩니다.

요약하면 구현된 이 구문은 ctor/dtor가 없고 리소스 누출을 방지하기 위해 코드 블록에서 멀리 떨어진 낮은 수준의 GC 기계에 의존하기 때문에 Go에서 리소스 관리에 미묘한 위험을 제공한다고 생각합니다. 무해해 보이는 것을 잠재적인 오류 조건으로 바꾸는 것(열린 파일이 너무 많음).

var n int
for _, name in try(os.Readdir(...)) {
   n += try(getSize(name))
}
func getSize(name string) (int, error) {
   return try(try(os.Open(name)).Stat()).Size
}

편집하다:
제약 조건의 경우 실제로 a, b := try(get("a")), try(get("b")) 가 충분히 합리적이기 때문에 한 줄에 1을 말하는 것보다 할당의 오른쪽에서만 유효하다고 생각합니다. 그러나 여전히 try(os.Open(name)).Stat() 를 수행할 수 있는 기능은 남습니다. try()를 무효로 만들려면 할당의 RHS에 있지 않을 때만 다음과 같이 그다지 기능하지 않는 무언가가 남습니다. 모두.

@cstockton 와우 대단한 발견!

Rust는 실제로 이 try 의미하는 바를 정확히 수행하는 유사한 매크로(제 기억이 맞다면 ? )를 가지고 있지만 거기에는 적절한 raii가 있으므로 해당 언어에서는 문제가 되지 않으며 우리의 경우 구멍

@sanbornm 네, 저장소에 인터넷의 절반을 보관하는 것은 정말 좋은 생각인 것 같습니다.

누군가 가 try 가 시간/노력을 절약할 수 있는 장소의 수를 계산하는 유틸리티를 언급했기 때문에 가장 큰 작업 프로젝트와 이전 GOPATH GitHub 디렉토리의 다른 모든 항목에 대해 이 유틸리티를 실행하기로 결정했습니다.

| 프로젝트 | 위치* | 후보자를 시도 |
|------------|------|----------------|
| 칼1 | 2047 | 3 |
| 펌프1 | 1030 | 0 |
| 문서1 | 4576 | 8 |
| 휴구틸 | 604 | 1 |
| 다른 모든 것 | 8452 | 23 |

• cloc 유틸리티에 따라 주석을 제외하고 코드만 이동합니다.

"다른 모든 것"의 내용에는 내가 바둑을 배울 때 작성한 빠른 해킹과 코드가 포함되어 있음을 명심하십시오.

내 전반적인 결론은 적어도 나에게 try 제안은 내 오류 처리를 합리화하는 데 도움이 되지 않는다는 것입니다.

내가 go를 좋아하는 가장 큰 이유는 그 사양이 코더를 다른 언어에서 사용할 수 있는 구문의 작은 하위 집합으로 제한하기 때문입니다. 매우 작은 기능 세트이기 때문에 전체 기능 세트를 쉽게 배울 수 있습니다. 미래의 개발자는 아마도 내 코드를 보고 내가 한 일을 알 수 있을 것입니다. 언어에 새로운 것이 추가될 때마다 미래의 개발자가 그 내용을 알 가능성이 줄어듭니다. 미끄러운 경사의 극단은 C++ 또는 스칼라와 같이 복잡성으로 인해 grok하기 어려운 언어입니다.
go 1에 구문 추가가 없는지 확인하고 싶습니다. 대신 go 2에 넣으십시오.

@miekg https://github.com/golang/go/issues/32825#issuecomment -506882164 이 링크를 제안서에 추가 try 키워드의 전체 아이디어를 완전히 무효화합니다.

그대로 두는 것에 전적으로 동의합니다. 약간 너무 장황하지만 따라하기에는 꽤 간단합니다.

줄일 수만 있다면

if err := foo.x(a, b); err != nil {
  return err
}

if err := foo.y(); err != nil {
  return err
}

if err := foo.z(c); err != nil {
  return err
}

뭔가에

if err := check foo.x(a, b), foo.y(), foo.z(c); err != nil {
  return err
}

관용구를 너무 많이 변경하지 않고 IMHO도 좋을 것 입니다.

"아마도" 유형에 대해 이야기하고 있다면 먼저 변형 유형이 필요합니다.

if err != nil 유지해 보겠습니다. 작동한다는 것은 분명합니다. 실제로 그렇게 장황하지 않으며 코드의 흐름에서 의미가 있습니다. 이 구성으로 코드를 읽을 때 무엇을 할 것인지 알 수 있습니다.
유지하자, try 추가하지 말자

나는 코드를 읽을 때 최소한의 오류 처리 없이 작업을 수행하는 행을 명확하게 읽을 수 있기를 원합니다.

같은 수준의 3글자 'err'이 허용됩니다. 중요한 코드가 두 번째 수준에 있기 때문에 중요한 코드를 래핑하는 일부 '확인' 기능을 원하지 않으며(lisp를 기억하십니까?) 중요한 코드가 들여쓰기되기 때문에 이전에 '시도' 행을 원하지 않습니다. 그리고 두 번째 줄에.

res, err := begin_job()
오류 != nil {
핸들 오류()
}

오류 = 계속_작업(res)
오류 != nil {인 경우
핸들 오류()
}

이 코드를 사용하면 블록의 첫 번째 줄을 읽음으로써 오류가 아닌 경우의 흐름을 읽을 수 있습니다(빨리 읽어야 할 때 문서 제목을 읽는 것처럼)

누군가 가 try 가 시간/노력을 절약할 수 있는 장소의 수를 계산하는 유틸리티를 언급했기 때문에 가장 큰 작업 프로젝트와 이전 GOPATH GitHub 디렉토리의 다른 모든 항목에 대해 이 유틸리티를 실행하기로 결정했습니다.

프로젝트 LOC* 시도 후보자
cal1 2047 3
펌프1 1030 0
문서1 4576 8
휴구틸 604 1
다른 모든 것 8452 23

• cloc 유틸리티에 따라 주석을 제외하고 코드만 이동합니다.

더 큰 프로그램에서는 try 가 더 필요하다고 생각합니다. 메모리에서 그림을 그리면 LOC 크기가 약 15-20k 이상인 프로그램이 더 많이 필요하다고 생각합니다. 그 이유는 닫힌 시스템에서 적절하게 지정되고 처리되기 때문에 오류를 전달해야 하는 레이어를 얻을 수 있기 때문입니다. 보내는 쪽과 받는 쪽 모두. 어떤 종류의 프로그램인지에 따라 많이 다릅니다. 나는 아마도 더 작은 프로그램에서도 많이 사용하지 않을 것입니다

더 큰 프로그램에서는 시도가 더 필요하다고 생각합니다.

좋은 지적. 나는 heptio/contour, 28.7k 라인의 소스 텍스트에 대해 tryhard를 시도했고, tryhard는 12개의 대체 항목을 찾았습니다.

더 큰 프로그램에서는 시도가 더 필요하다고 생각합니다.

좋은 지적. 나는 heptio/contour, 28.7k 라인의 소스 텍스트에 대해 tryhard를 시도했고, tryhard는 12개의 대체 항목을 찾았습니다.

우와! 12 대 28.7K 라인, 이것은 정말 전용 키워드가 필요합니다!

글쎄, 나는 이것 에 대한 당신의 POV에 더 관심

stat := try(try(os.Open(fileName)).Stat())

귀하의 프로그램이 좀 더 모놀리식이고 많은 서비스 간의 서비스 통합의 일부가 아닌 경우 더 일반적이라고 생각합니다. 해당 저장소( heptio/contour )의 github에서 fmt.errorf 또는 errors 를 검색하면 결과가 거의 없으므로 빠른 개요를 얻기가 어렵습니다. 더 큰 프로그램의 경우에도 프로그램마다 많이 다를 수 있다고 말했습니다.

외부 라이브러리를 많이 사용하지 않는 단일 프로그램이 있다고 가정해 보겠습니다. 그런 다음 이미 사용자 메타 데이터를 포함하고 실제로 필요한 항목을 크게 변경하지 않고도 몇 개의 레이어를 변경하지 않고 전파할 수 있는 특정 AuthorizationError를 가질 수 있습니다(반환된 모든 오류는 이미 처리되고 래핑된 모든 io 오류로 충분히 구체적임). 요청 계층까지 처리합니다.

귀하의 프로그램이 좀 더 모놀리식이고 많은 서비스 간의 서비스 통합의 일부가 아닌 경우 더 일반적이라고 생각합니다. 해당 저장소의 github에서 fmt.errorf 또는 errors 를 검색하면 결과가 거의 없으므로 빠른 개요를 얻기가 어렵습니다. 그러나 내가 말했듯이 아마도 프로그램마다 많이 다를 수 있습니다. 더 큰 프로그램의 경우에도 프로그래밍할 수 있습니다.

외부 라이브러리를 많이 사용하지 않는 단일 프로그램이 있다고 가정해 보겠습니다. 그런 다음 이미 사용자 메타 데이터를 포함하고 요청 계층까지 실제로 처리해야 하는 항목에 많은 변경 없이 몇 계층을 변경하지 않고 전파될 수 있는 특정 AuthorizationError를 가질 수 있습니다.

당신은 아이디어를 얻을 수 없습니다. 주석은 오류가 발생한 경로를 쉽게 찾기 위한 것입니다. 유사하게 os.NotExist 있지만 이것은 오류 경로에 대한 좋은 힌트가 아닙니다.

@thomasf 는 몇 년 된 juju/juju 작업 사본의 또 다른 데이터 포인트입니다.

529628 소스 라인, tryhard가 1763(0.3%) 대체품을 찾았습니다.

네, 물론입니다. 당신이 두 가지 모두에 관여했기 때문에 그들은 아마도 프로그램을 작성하는 다양한 방법의 좋은 예가 아닐 것입니다. 나는 tryhard 프로그램 atm을 시도할 시간이 없고 다양한 소스에서 적절한 실행을 덜 수행합니다(github를 통해 수집되는 경우 닫힌 소스 코드를 생략하기 때문에 어쨌든 수집하는 것이 불가능할 수 있음)

529628 소스 라인, tryhard가 1763(0.3%) 대체품을 찾았습니다.

누군가 (인용 필요) 현명하게 말했듯이 try 는 오류 처리를 더 쉽게 만들지 않습니다. 그것들을 다루지 않기가 더 쉽습니다.

코드를 분석하고 많은 try 대체품을 찾으면 코드가 오류를 반환하는 것 외에는 아무 것도 하지 않는다는 것을 알 수 있습니다. 그것은 아마도 훌륭한 코드가 아닐 것입니다. 사람들이 더 쉽게 게으르고 오류에 대해 걱정하지 않도록 해야 합니까? 그것이 바로 Go에 예외가 없는 이유 중 하나가 아니겠습니까? 정확히 그것을 피하기 위해서입니까?

나는 그것에 대해 입장을 취하지 않을 것입니다. 그러나 내가 찾은 것은

NS. 기존 go 코드베이스에 try 를 적용할 수 있는 위치가 많이 있습니다.
NS. 일반적으로 오류 처리는 내 자신의 측정값과 Go 팀이 제안한 숫자를 기반으로 SLOC의 상당 부분을 구성합니다(참조 https://youtu.be/RIvL2ONhFBI?t=440 타임코드 07:26).

코드를 분석하고 많은 try 대체품을 찾으면 코드가 오류를 반환하는 것 외에는 아무 것도 하지 않는다는 것을 알 수 있습니다. 그것은 아마도 훌륭한 코드가 아닐 것입니다. 사람들이 더 쉽게 게으르고 오류에 대해 걱정하지 않도록 해야 합니까? 그것이 바로 Go에 예외가 없는 이유 중 하나가 아니겠습니까? 정확히 그것을 피하기 위해서입니까?

1. 당신은 어떤 것이 좋은 습관이 아닌지 전혀 알지 못하는 이론적인 코드에 대해 가치 판단을 내리고 있습니다.
2. try 가 우리가 지금 가지고 있는 것보다 어떻게 오용하기 쉬운지 알 수 없습니다. go에는 오류 처리를 적용하는 기능이 없으며 이미 건너뛰기가 매우 쉽습니다. 나를 위해 try 이 핸들 오류를 필요로하지 않는 경우 읽기 쉽게 코드를 만드는 방법에 대한 것입니다.

많은 곳에서 필요하지 않기 때문에 try 가 필요하지 않을 수도 있지만 그냥 심술궂게 생각하기 보다는 아이디어를 즐겁게 하고 유스 케이스를 생각해 봅시다...

실제 사용하는 상황이 많이 생각나지 않지만 아직 존재하지도 않아서 존재한다면 다르게 디자인할지 어떨지 장담하기 어렵습니다.. 생각나는 한 가지는 아마도 do는 try를 사용하여 이와 같은 익명 함수의 여러 작업을 그룹화하고 호출자를 반환하기 전에 오류를 처리합니다. 일부 코드를 훨씬 더 읽기 쉽게 만들 수 있습니다.

var v1, v3 string
if err := func() error {
    try(onething())
    v = try(twothing())
    try(otherthing())
    v3 = try(somethingg())
}(); err != nil {
  ... handle error...
}

이 시점에서 tryhard 에 대한 데이터를 다른 패키지에 보관하고 시각화하는 웹 사이트를 작성하는 것이 좋습니다. golang/gddo(godoc.org)를 약간 수정하면 작업을 수행할 수 있습니다.

나는 if err != nil 혼자 두는 것을 선호합니다. 그러나 오류 처리를 위해 무언가를 추가해야 한다면 여기에 throws 키워드를 추가하는 새로운 제안이 있습니다.

32852

여기에 이미 나와 있는 몇 가지 주장을 반복하지 않고 if err != nil 를 그대로 두는 느낌을 되풀이합니다.

제가 제안할 수 있는 관점은 다음과 같습니다. 수백 명의 신규 이민자(프로그래밍과 바둑 모두에 대해)를 가르친 사람으로서 if err != nil 는 그들에게 결코 문제가 되지 않았습니다. 내 워크샵의 숙련된 프로그래머는 처음에는 이상하다고 생각하지만 Go에서 오류 처리의 명시적 특성을 사랑하는 법을 빨리 배웁니다.

언어로 해결할 수 있는 더 큰 문제가 있으며 이 문제에 대한 커뮤니티의 명확한 반응은 if err != nil 가 그 중 하나가 아니라고 말합니다.

Go는 여러 가지 이유로 완벽합니다. 그 중 가장 중요한 것은 "if err != nil"입니다. 장황하게 보일 수 있지만 코딩을 배우는 사람들에게는 코드를 디버그하고 코드를 수정하는 것이 더 쉽습니다.

@davecheney

나는 그것에 대해 입장을 취하지 않을 것입니다. 그러나 내가 찾은 것은

NS. 기존 go 코드베이스에 try 를 적용할 수 있는 위치가 많이 있습니다.
NS. 일반적으로 오류 처리는 내 자신의 측정값과 Go 팀이 제안한 숫자를 기반으로 SLOC의 상당 부분을 구성합니다(참조 https://youtu.be/RIvL2ONhFBI?t=440 타임코드 07:26).

현재 상황에서 우리가 찾은 모든 예제는 "그건 아마도 좋은 코드가 아닐 것"으로 무시될 것입니다.

다음은 예입니다.

llorllale:~/go/src/github.com/hyperledger/fabric$ cloc --exclude-dir=vendor .
    2406 text files.
    2256 unique files.                                          
    3130 files ignored.

http://cloc.sourceforge.net v 1.60  T=6.69 s (272.8 files/s, 58350.9 lines/s)
--------------------------------------------------------------------------------
Language                      files          blank        comment           code
--------------------------------------------------------------------------------
Go                             1751          54365          34149         294005
YAML                             35            547           2171           2060
Bourne Shell                     26            354            325           1312
make                              3            135             96            418
CSS                               1             40             14            140
HTML                              3              7              5             63
Python                            1             50            103             57
Bourne Again Shell                1              1              6             50
Java                              3              7              4             26
XML                               2              1              4              2
--------------------------------------------------------------------------------
SUM:                           1826          55507          36877         298133
--------------------------------------------------------------------------------

llorllale:~/go/src/github.com/hyperledger/fabric$ tryhard -l . | grep -v vendor | less | wc -l
1417

공평하게 말하면, tryhard가 찾은 위치의 수에 대한 데이터는 래핑 오류가 필요한 규칙으로 인해 혼동될 수 있습니다. 예를 들어 회사 규칙이

if err != nil {
   return errors.Wrap(err) 
} 

...
if err != nil {
   return errgo.Notef(err, "error doing x") 
} 

그것은 tryhard에 의해 보고되지 않을 것입니다.

우리 회사에는 그런 컨벤션이 있습니다. 간단한 검색 및 바꾸기를 수행하여 해당 오류를 기본 오류 반환으로 되돌리면 다음과 같은 결과가 나타납니다.

Language                             files          blank        comment           code
---------------------------------------------------------------------------------------
Go                                    2488          40317          15901         297038

tryhard는 2736개의 대체품을 보고하지만 나머지 래핑에 대한 수동 검토를 수행하면 약 1850개만큼 과소 계산되는 것처럼 보이므로 300k 라인의 코드베이스에서 총 ~4500 try 사용량을 추정합니다.

(개인적으로, 나는 오류 처리의 현재 명시성에 찬성하며 그것에 대해 신경 쓰지 않습니다.)

예를 들어 회사 규칙이
[사용자 정의 메시지로 오류 래핑]
그것은 tryhard에 의해 보고되지 않을 것입니다.

이것이 요점입니다. try 제안은 if err != nil return err 네이키드 리턴을 단순화할 뿐 사용자 정의 메시지 및 컨텍스트로 오류를 래핑하는 것은 지원하지 않습니다.

if err != nil 의 유일한 반복성은 다른 반환 값의 0 값도 지정해야 수정될 수 있다고 생각합니다. 이를 제거하기 위해 언어를 업데이트할 수 있습니다. 예를 들어:

오늘의 Go에서 이 서명이 있는 함수가 있는 경우:

func add(x, y string) (int, error)

함수의 어딘가에 다음과 같이 작성해야 합니다.

func add(x, y string) (int, error) {
    // ...
    if err != nil {
        return 0, err
    }

작성자가 함수 전체에서 동일한 0 값을 반복하도록 합니다.

언어가 오류가 아닌 반환 값에 대해 0 값을 자동으로 채울 수 있다면 훨씬 더 쉬울 것입니다.

func add(x, y string) (int, error) {
    // ...
    if err != nil {
        return ..., err
    }
    // ...
}
func main() {
    add("8", "beep") // returns 0, error(`strconv.ParseInt: parsing "beep": invalid syntax`)
}

DB 쿼리 및 호출과 상호 작용하는 많은 코드에 대한 경험으로 볼 때 함수 전체에서 0 값을 반복해야 하는 것은 Go 스타일 오류 처리의 유일한 단점이라고 말할 수 있습니다. 그렇지 않으면 나는 이 제안의 의견에 동의합니다. if err != nil 그대로 두십시오!

참고: 예, 명명된 반환 값은 _sort of_ 이 작업을 수행할 수 있지만(https://play.golang.org/p/MLV8Y52HUBY), 이 기술을 사용하여 내 코드베이스에서 몇 가지 기능을 구현한 후 -gun 이름의 반환 값은 다음과 같습니다. 나는 항상 명명된 반환 값을 섀도잉합니다.

예를 들어 회사 규칙이
[사용자 정의 메시지로 오류 래핑]
그것은 tryhard에 의해 보고되지 않을 것입니다.

이것이 요점입니다. try 제안은 if err != nil return err 네이키드 리턴을 단순화할 뿐 사용자 정의 메시지 및 컨텍스트로 오류를 래핑하는 것은 지원하지 않습니다.

사실입니다. 설명 문자열을 추가할 수 있는 변형을 생각하고 있었습니다. 오류 반환의 대다수(~4000 / 4500)는 컨텍스트 없음 errgo.Mask(err) 이며, 설명 없음 try() 과 동등하다고 생각했지만 현재는 errgo는 스택 정보를 추가하고 try는 (아직) 하지 않기 때문에 기능입니다.

@ianlancetaylor 여기에 제안이 있습니다. @miekg 는 우리 언어의 지도자 중 한 사람으로서 더 이상 if err != nil 를 원래 Go 작성자가 결정한 오류 처리 정신과 모순되는 다른 구성으로 대체하지 않을 것을 제안합니다. 개인적으로 이 요청을 다른 제안처럼 처리하는 대신 golang-nuts 로 이동하여 이 요청의 중요성을 주장하려는 것처럼 느껴집니다. 그것은 당신의 의도가 아닐 수도 있지만, 그것은 내가 느끼는 영향입니다.

우리의 오류 처리 방법은 독특하며 다른 언어에 비해 엄청난 부가 가치가 있다고 생각합니다. 그것은 내가 구축한 시스템의 오류에 대해 생각하는 방식을 완전히 바꿨고 결과적으로 더 강력한 소프트웨어 엔지니어가 되었습니다. 더 많은 Go 개발자를 확보하기 위해 우리가 소수 또는 외부인에게 손을 대는 것을 원하지 않습니다. 나는 우리가 코드의 간결함을 절충함으로써 궁극적으로 우리를 더 낫게 만들기 때문에 오류를 처리하기로 선택한 방식과 함께 특정 사항에 대해 강경한 태도를 취해야 한다고 생각합니다.

이것은 Google 내부 팀이 커뮤니티와 더 많은 신뢰와 믿음을 구축하거나 언어, 생태계 또는 사용자에게 좋지 않은 현재 궤도를 계속할 수 있는 기회입니다.

Go 팀이 이 제안을 있는 그대로 받아들이고 더 명확한 부가가치가 있는 관련 없는 다른 언어 반복을 계속 추구할 것을 요청합니다.

트래커에 스레딩이 없을 수도 있지만 개인적으로 이 제안이 공식 자격으로 응답되고 조용히 사라질 수 있는 Google 그룹으로 분류되지 않는다는 보장을 개인적으로 훨씬 원합니다.

주제는 이미 Google 그룹에서도 논의되었습니다.

#32437의 현재 버전은 만족스럽지 않습니다. try() 내장은 훈련되지 않은 눈에 대한 많은 실행 경로를 숨깁니다. 체크와 핸들이 있는 원래 제안은 매우 이해하기 쉬웠고 체크 키워드가 눈에 띄었습니다.

이제 try() 내장은 함수처럼 보입니다. 제어 흐름을 변경할 수 있다는 것은 분명하지 않습니다. 우리는 또한 panic()을 가지고 있지만, 그것은 (내 생각에) 항상 그 자체로 줄을 서고, 저명한 이름을 가지고 있으며 그 사용은 거의 없습니다. 반면에 try()는 복잡한 표현식 안에 숨길 수 있습니다.

@theckman Robert는 Rob과 Ken과 함께 Go의 첫 번째 반복을 디자인했으며 Robert와 Russ는 일찍 팀에 합류했습니다. 그들은 처음부터 바둑을 연구해 왔습니다. 제안이 "원래 Go 작성자가 결정한 오류 처리 정신에 위배"되는지 여부를 알 수 있다고 믿을 수 있습니다.

나는 오늘날과 같이 오류 처리를 동결하는 제안의 원칙을 싫어합니다. 그러한 제안은 이 주제에 대한 모든 향후 제안을 금지합니다.

대신 디자인 반복을 수락하지 않는 이유는 무엇입니까? 확인/처리 제안이 있었습니다. 그러나 몇 가지 단점이 논의되었습니다. 이것은 시도 제안으로 이어졌습니다. 이 제안의 몇 가지 단점이 지금 논의됩니다. 아마도 이것은 올바른 접근 방식이 발견될 때까지 더 나은 또 다른 제안으로 이어질 것입니다.

우리의 오류 처리 방법은 독특합니다.

Rust의 오류 처리는 개념적으로 Go에서 수행하는 작업과 유사합니다(오류는 값, 명시적 제어 흐름이지만 합계 유형을 대신 사용할 때 여러 반환 값을 사용한다는 점을 제외하면). Rust는 Go와 같은 장황한 오류 처리 문제가 있었습니다. 이것은 Rust가 시도를 추가하도록 했습니다! 매크로, 그리고 결국 ? 운영자. Rust 커뮤니티는 오류 처리와 관련하여 Go 커뮤니티보다 훨씬 더 엄격합니다(오류 처리 RFC 및 토론은 계몽적입니다). 그들은 잘못된 오류 처리의 미끄러운 기울기 없이 오류 처리의 장황함을 줄이는 방법을 찾았습니다. 우리도 할 수 있다고 확신합니다.

현재 언어, 생태계 또는 사용자에게 좋지 않은 궤적

무슨 얘기를하는 건가요? Go는 지속적으로 개선되고 있습니다. 이렇게 훌륭한 언어, 도구 및 문서에 무료로 액세스할 수 있다는 것은 놀라운 일입니다.

@theckman Robert는 Rob과 Ken과 함께 Go의 첫 번째 반복을 디자인했으며 Robert와 Russ는 일찍 팀에 합류했습니다. 그들은 처음부터 바둑을 연구해 왔습니다. 제안이 "원래 Go 작성자가 결정한 오류 처리 정신에 위배"되는지 여부를 알 수 있다고 믿을 수 있습니다.

나는 오늘날과 같이 오류 처리를 동결하는 제안의 원칙을 싫어합니다. 그러한 제안은 이 주제에 대한 모든 향후 제안을 금지합니다.

대신 디자인 반복을 수락하지 않는 이유는 무엇입니까? 확인/처리 제안이 있었습니다. 그러나 몇 가지 단점이 논의되었습니다. 이것은 시도 제안으로 이어졌습니다. 이 제안의 몇 가지 단점이 지금 논의됩니다. 아마도 이것은 올바른 접근 방식이 발견될 때까지 더 나은 또 다른 제안으로 이어질 것입니다.

우리의 오류 처리 방법은 독특합니다.

Rust의 오류 처리는 개념적으로 Go에서 수행하는 작업과 유사합니다(오류는 값, 명시적 제어 흐름이지만 합계 유형을 대신 사용할 때 여러 반환 값을 사용한다는 점을 제외하면). Rust는 Go와 같은 장황한 오류 처리 문제가 있었습니다. 이것은 Rust가 시도를 추가하도록 했습니다! 매크로, 그리고 결국 ? 운영자. Rust 커뮤니티는 오류 처리와 관련하여 Go 커뮤니티보다 훨씬 더 엄격합니다(오류 처리 RFC 및 토론은 계몽적입니다). 그들은 잘못된 오류 처리의 미끄러운 기울기 없이 오류 처리의 장황함을 줄이는 방법을 찾았습니다. 우리도 할 수 있다고 확신합니다.

현재 언어, 생태계 또는 사용자에게 좋지 않은 궤적

무슨 얘기를하는 건가요? Go는 지속적으로 개선되고 있습니다. 이렇게 훌륭한 언어, 도구 및 문서에 무료로 액세스할 수 있다는 것은 놀라운 일입니다.

Rust 개발의 역사는 그 뒤에 있는 친구들이 자신들이 무엇을 하고 있는지 전혀 몰랐음을 보여줍니다. 그들은 기본적으로 Haskell의 오류 처리 원칙을 복사했지만 명령형(실제 세계?) 프로그래밍에는 적합하지 않습니다. ? 매크로는 초기에 실패한 오류 처리 시스템에 대한 해결 방법일 뿐입니다.

@ianlancetaylor 여기에 제안이 있습니다. @miekg 는 우리 언어의 지도자 중 한 사람으로서 더 이상 if err != nil 를 원래 Go 작성자가 결정한 오류 처리 정신과 모순되는 다른 구성으로 대체하지 않을 것을 제안합니다. 개인적으로 이 요청을 다른 제안처럼 처리하는 대신 golang-nuts 로 이동하여 이 요청의 중요성을 주장하려는 것처럼 느껴집니다. 그것은 당신의 의도가 아닐 수도 있지만, 그것은 내가 느끼는 영향입니다.

우리의 오류 처리 방법은 독특하며 다른 언어에 비해 엄청난 부가 가치가 있다고 생각합니다. 그것은 내가 구축한 시스템의 오류에 대해 생각하는 방식을 완전히 바꿨고 결과적으로 더 강력한 소프트웨어 엔지니어가 되었습니다. 더 많은 Go 개발자를 확보하기 위해 우리가 소수 또는 외부인에게 손을 대는 것을 원하지 않습니다. 나는 우리가 코드의 간결함을 절충함으로써 궁극적으로 우리를 더 낫게 만들기 때문에 오류를 처리하기로 선택한 방식과 함께 특정 사항에 대해 강경한 태도를 취해야 한다고 생각합니다.

이것은 Google 내부 팀이 커뮤니티와 더 많은 신뢰와 믿음을 구축하거나 언어, 생태계 또는 사용자에게 좋지 않은 현재 궤도를 계속할 수 있는 기회입니다.

Go 팀이 이 제안을 있는 그대로 받아들이고 더 명확한 부가가치가 있는 관련 없는 다른 언어 반복을 계속 추구할 것을 요청합니다.

그들은 60 년대의 현재 유형 시스템으로 심각한 일을 할 수 없습니다. 그들은 마침내 Go 2.0에서 80년대 아이디어를 빌려야 합니다.

무슨 얘기를하는 건가요? Go는 지속적으로 개선되고 있습니다. 이렇게 훌륭한 언어, 도구 및 문서에 무료로 액세스할 수 있다는 것은 놀라운 일입니다.

@ngrilly 마지막 부분은 아마도 더 큰 토론을 위한 것입니다. 이 제안을 탈선시키지 않고 그 의견을 어느 정도 마무리하면서 커뮤니티/생태계의 사용자와 리더십 사이의 불일치에 대한 감정이 커지고 있습니다.

나머지 토론에서는 구문에 더 많은 인지 오버헤드를 추가하는 것이 승리라고 생각하지 않습니다. 나는 그들이 그들에게 효과가 있는 것을 발견해서 기쁩니다. 우리는 그들이 아닙니다.

방금 인라인 if 문에 대한 제안을 열었습니다. https://github.com/golang/go/issues/32860

참조: https://github.com/golang/go/issues/32825#issuecomment -506707539

새로운 golang 2.0 기능에 대한 제안을 제출하는 모든 사람이 https://github.com/golang/go 의 분기 분기를 제공한다면 이 세상이 얼마나 더 좋을까? 저장소 필요) 해당 제안을 구현합니다.

동의하지 않습니까?

@av86743 이 제안의 범위를 벗어난 것 같습니다. 해당 조치를 제안하는 제안서를 제출하십시오.

제안 문서 자체에 있는 내용을 기반으로 누군가가 거절하기 전에 많은 노력을 낭비할 위험이 있는 것과 같은 문제가 있다고 생각합니다. 그런 다음 검토조차 되지 않는 포크에 그 모든 시간을 보냈습니다.

이 구문은 어떻습니까?

# call error handler
try callFunction(), errorHandler()

# error handler with anonymous function
variable := try callSomething(), func(err *Error) { # error handling }

@theckman 이 토론을 다른 곳으로 옮기

"원래 바둑 작가"를 언급 하셨기 때문에 "시도" 제안은 바둑 원작자 3명 중 한

나는 이 제안에 강력히 동의합니다. 변경해야 할 유일한 것은 go fmt, make go fmt 하나의 if 문을 허용하도록 하는 것뿐이라고 생각합니다.

난 정말 한 줄을 원해

if err != nil { return wrappedErr{err} }

세 줄 대신

if err != nil {
    return wrappedErr{err}
}

@av86743 이 제안의 범위를 벗어난 것 같습니다. 해당 조치를 제안하는 제안서를 제출하십시오.

@theckman 어떻게 하라고 말씀

제안 문서 자체에 있는 내용을 기반으로 누군가가 거절하기 전에 많은 노력을 낭비할 위험이 있는 것과 같은 문제가 있다고 생각합니다. 그런 다음 검토조차 되지 않는 포크에 그 모든 시간을 보냈습니다.

그것은 [... _간결함을 위해 생략된 완전히 적절한 언어로 된 설명_ ...]에 대한 "낭비된 노력"일 뿐입니다.

그러나 코더에게 이는 사소하지만 유용한 연습이 될 것이며 동시에 Go 커뮤니티에 대한 서비스가 될 것입니다.

@av86743 나는 당신이 제안한 것이 흥미로운 아이디어라고 생각하며 관련이 없는 문제의 논평으로 손실되는 것을 원하지 않았습니다. 공식적인 고려 대상으로 삼는 데 관심이 없으시다면 별도의 문제를 제기할 것을 옹호하는 점 사과드립니다.

이 특정 제안이 @griesemer 에서 장황함 에 대해 10년 동안 내적 분노로 끓어오르고 있다는 것이 믿기지 않습니다. 그러나 그는 뛰어난 엔지니어이고 엔지니어는 (인식된) 문제에 대한 솔루션을 제시합니다. 그들을 막는 것은 매우 어렵습니다. 우리는 문제 해결을 _좋아_합니다. 문제의 냄새를 맡는 것만으로도 모든 종류의 아이디어를 떠올리기에 충분합니다. 일단 그 사고 과정이 상당히 진전되면, 우리 중 누구도 감정적으로 우리의 추정되는 해결책을 버리고 _어쩌면 그것이 실제로 문제가 되지 않을 수도 있다고 생각하기가 어렵습니다. 결국, 우리는 지적으로 말해서 아기를 낳았고, 그것을 그냥 버리기가 쉽지 않습니다.

그만한 가치가 있기 때문에 내 개인적인 의심은 이에 대한 Go 팀의 추론 프로세스가 다음과 같이 진행되었다는 것입니다.

1. Go는 매우 인기 있고 널리 사용되기 때문에 수천 명의 사람들이 당연히 이에 대한 의견, 제안 및 불만을 가지고 있습니다.
2. 오랫동안 돌담을 쌓을 수 있습니다. Go 팀은 커뮤니티의 모든 소음에 대해 _무언가_ 해야 한다는 엄청난 압력을 받고 있습니다.
3. 이건 뭔가요.

시도에서 복구()와 같은 오류가 발견된 경우 catch()를 연기하여 catch() 함수를 추가하는 것은 어떻습니까?
예시:

func doSomthing()(err error){
    //return error
}

func main(){
    defer func(){
        if err:=catch();err!=nil{
            //found error
        }
    }()

    try doSomthing()
}

많은 기능에

func Foo() (err error) {
    defer func(){
        if err:=catch();err!=nil{
            //found error
        }
    }()

   try{
    file1 := open("file1")
    defer file1.Close()
    file2 := open("file2")
    defer file2.Close()
   }
   //without try
    file3,err := open("file3")
    defer file3.Close()
 }

시도에서 복구()와 같은 오류가 발견된 경우 catch()를 연기하여 catch() 함수를 추가하는 것은 어떻습니까?
예시:

func doSomthing()(err error){
    //return error
}

func main(){
    defer func(){
        if err:=catch();err!=nil{
            //found error
        }
    }()

    try doSomthing()
}

많은 기능에

func Foo() (err error) {
    defer func(){
        if err:=catch();err!=nil{
            //found error
        }
    }()

   try{
  file1 := open("file1")
  defer file1.Close()
  file2 := open("file2")
  defer file2.Close()
   }
   //without try
    file3,err := open("file3")
    defer file3.Close()
 }

이것이 각각의 오류를 별도의 방식으로 처리하는 데 어떻게 도움이 됩니까?

몇 가지 설명:

1. try 제안 은 일부 사람들이 이 스레드에서 주장한 것과 달리 새로운 구문이나 새 키워드를 도입하지 않습니다. 그것은 단지 새로운 기능을 추가하기 위해 할 수 있는 가장 최소한의 변경에 대한 새로운 내장 기능을 소개합니다. 중요하기 때문에 이에 대해 논의할 때 정확하게 말씀해 주십시오. 새 구문과 새 키워드를 추가하는 것과 기본 제공되는 것 사이에는 큰 차이가 있습니다. 전자는 주요 변경 사항이고 후자는 비교적 사소한 추가 사항입니다. try 제안이 제안하는 것은 비교적 사소한 추가 사항입니다.

2. 나는 이 토론이 다른 곳(golang-nuts)에서 개최되는 것이 더 낫다는 @ianlancetaylor의 의견에 동의합니다. 여기에는 제안이 없습니다.

3. 실제로 @bitfield , 저는 "Go에서 래핑되지 않은 오류 반환의 자세한 정도에 대한 내부 분노"가 없습니다 . 감사합니다 :-) 하지만 오류 검사가 아마도 필요한 것보다 더 장황하다고 생각합니다. 커뮤니티에서 이와 같은 감정을 반복적으로 제기했다는 사실은 우리(바둑 팀)만이 이러한 믿음을 갖고 있지 않다는 분명한 지표입니다. "무언가"를 해야 한다는 압박감이 크다고 말할 정도는 아닙니다. 우리는 오랫동안 이 문제를 해결해 왔으며 "올바른" 접근 방식을 기다리는 데 만족합니다. .

try 제안은 오류 검사 문제를 해결하는 (커뮤니티 기여의 상당한 도움으로) 우리가 찾은 가장 최소한의 솔루션에 관한 것입니다. try 제안은 모든 오류 테스트에서 특정 방식으로 오류를 처리해야 하는 경우 _전혀 도움이 되지 않는다는 사실에 대해 매우 명시적입니다. try 는 함수의 모든 오류가 동일한 방식으로 테스트되고 처리될 때만 도움이 됩니다(그런 다음 defer 사용하는 것이 좋습니다) 또는 단순히 반환될 때. 여기에서 더 명확하게 말하기는 어렵지만 제안 내용을 반복해 보겠습니다. try 는 모든 오류 시나리오에서 도움이 되지 않습니다. 많은 경우에 도움이 됩니다. 다른 모든 경우에는 if 문을 사용하십시오.

@griesemer try는 오류가 발생하기 쉽습니다. Go에는 RAII가 없으므로 많은 경우에 함수를 그대로 둘 수 없습니다.

@sirkon , RAII가 이 토론과 얼마나 관련이 있는지 잘 모르겠습니다. try 의 패턴 기존 대체합니다 if ..., err := f(); err != nil { return ..., err } A를 ... := try(f()) . try 를 사용하여 리소스 해제 버그가 있었다면 분명히 이전에도 존재했습니다. try 의 도입은 리소스 해제 버그를 개선하거나 방지하지 않습니다.

@sirkon , RAII가 이 토론과 얼마나 관련이 있는지 잘 모르겠습니다. try 의 패턴 기존 대체합니다 if ..., err := f(); err != nil { return ..., err } A를 ... := try(f()) . try 를 사용하여 리소스 해제 버그가 있었다면 분명히 이전에도 존재했습니다. try 의 도입은 리소스 해제 버그를 개선하거나 방지하지 않습니다.

스레드를 읽으십시오. 예가 있습니다.

info := try(try(os.Open(fileName)).Stat())

@sirkon 나는 그 예를 지금 여러 번 보았습니다. 흥미롭다는 데 동의합니다. 하지만 조금 더 생각해보자. 제안된 try 내장은 기본적으로 Go 코드에서 발견되는 특정 종류의 상용구에 대한 구문 설탕입니다. 따라서 해당 예제를 원본 코드로 변환할 수 있습니다.

    f, err := os.Open(fileName)
    if err != nil {
        return err
    }
    info, err := f.Stat()
    if err != nil {
        return err
    }

해당 코드에는 동일한 버그가 있습니다. 나는 확실히 그런 코드를 보았다. try 내장이 그 버그를 작성하기 더 쉽거나 보기 어렵게 만든다는 것은 분명하지 않습니다.

[ @ianlancetaylor 가 저를 이겼던 것 같습니다.]

@sirkon 이 버그는 이미 가능합니다. try 여부 - Go는 나쁜 코드 작성을 방지하지 않습니다. 또는 try 가 허용되지 않아야 하는 이유로 잘못된 코드를 사용하는 것은 설득력 있는 주장이 아닙니다. 대신 go vet 는 문제가 있는 경우에 플래그를 지정해야 합니다.

defer 는 함수가 반환될 때 정리하는 Go 관용구이며 잘 작동합니다. 물론 여기에 대한 올바른 접근 방식은 다음과 같습니다.

f := try(os.Open(filename))
defer f.Close()
info := try(f.Stat())

이것을 다음과 비교하십시오.

f, err := os.Open(filename)
if err != nil {
   return ..., err
}
defer f.Close()
info, err := f.Stat()
if err != nil {
   return ..., err
}

try 하면 소스는 파일의 파일 정보를 얻는 주요 관심사에 집중합니다. 전통적인 접근 방식을 사용하는 대부분의 소스 코드는 가능한 오류에 대해 우려하고 있습니다. 그리고 그것은 모두 동일합니다. 오류를 꾸미고 싶어도 try 접근 방식은 훌륭하게 작동합니다.

defer errd.Wrap(&err, "failed to do X for %s", filename)
f := try(os.Open(filename))
defer f.Close()
info := try(f.Stat())

errd 패키지와 같은 것을 사용합니다(문제 #32676 참조).

@griesemer
내 미래의 자체 코드 검토는 여전히 제어 흐름 메커니즘이 자체 라인에 있어야 한다고 계속 외치고 있습니다. 이 접근 방식이 현재 제안 내에서 유효할 수 있습니까(시행 없음)? 가독성 외에도 더 자세한 오류 처리 논리로의 리팩토링이 쉬워졌습니다.

defer errd.Wrap(&err, "failed to do X for %s", filename)
f, err:= os.Open(filename)
try(err) // check is so much a better term
defer f.Close()
info, err := f.Stat()
try(err)

또한 handle 대한 이 접근 방식은 여기에서는 훌륭해 보이지만 여러 번 연기하면 엉망이 되지 않을까요? 아니면 기능 범위 동기화가 있을 것입니까?일단 일종의 것(errd 문제에서 설명을 보지 못했습니다)? 그렇다면 익명의 함수에 자체 범위가 부여됩니까? 그리고 섀도잉... 에쉬 - 누가 1위이고 2위는 뭐야?

이 모든 것이 Go 코드를 작성하는 두 가지 "모드"가 되는 것처럼 느껴집니다. 그렇지 않다고 말합니다.

@griesemer 당신이 옳다고 생각하는 버그는 오늘날에도 가능하지만, 현재 try의 구현과 함께 미래에 더 널리

이 제안이 수락되면 if err 상용구를 피할 수 있어 익숙한 방식으로 코드를 작성할 수 있습니다. try가 생성되기 전에 작성된 stackoverflow 답변, 블로그 게시물 등에 거의 10년 동안 Go 코드가 있다는 점을 제외하고는. 그들은 try를 사용하여 오류 및 if 문을 간단히 삭제하는 방법을 빠르게 배울 것입니다. 그들은 try 제안에서 Stat() 처럼 원하는 필드에 액세스할 수 있을 때까지 try 래핑된 코드를 붙여넣을 수 있는 파일 크기를 원합니다. 익숙한 패턴이라 바둑을 쓸 때 적용하는 것은 당연하다. 가장 표적화된 Go OS가 모든 것을 파일로 취급한다는 점을 감안할 때 더 많은 리소스 누수가 발생할 것이라고 가정하는 것이 타당합니다.

이것은 내가 "오늘 이미 할 수 있다"라는 말에 강력하게 동의하지 않는 이유를 알려줍니다. 왜냐하면 단순히 할 수 없기 때문입니다. 물론입니다. 파일 핸들이 누출될 수 있습니다. 그러나 Go는 프로그래머가 범위 내 식별자를 건너뛰어 파일을 유출할 기회를 주지 않습니다. 건너뛴 각 식별자 f 는 유출된 파일 핸들입니다. 기능을 사용하려면 바둑 생태계에서 눈에 띄는 특정 관용구가 깨져야 _필요합니다_. 따라서 오늘날 설계된 대로 기능을 도입하면 Go에서 리소스가 누출될 위험이 분명히 높아집니다.

https://github.com/golang/go/issues/32825#issuecomment -506882164에서 언급했듯이 몇 가지 작은 조정이 이루어지면 실제로 try 지원할 것입니다. 언어 추가를 환영합니다. 시도가 필요하다고 생각하는 것은 할당의 RHS에서만 유효하게 만들고 반환 값을 주소 지정할 수 없도록 하는 것입니다. try 사용의 "좋은" 예(한 줄에 한 번 시도하는 경향이 있음)를 try를 사용하는 "유일한" 방법으로 만드십시오. 예:

info := try(try(os.Open(filename)).Stat()) // compiler error
f := try(os.Open(filename)) // valid
// we were forced to assign f, so we still have an identifier to Close (serve linters and users alike)
defer f.Close()
info := try(f.Stat())
a, b := try(strconv.Atoi("1")), try(strconv.Atoi("2")) // also valid 
a, b := try(strconv.Atoi("1"), strconv.Atoi("2")) // maybe?
a, b := try strconv.Atoi("1"), strconv.Atoi("2")

나는 이것이 언어에 자연스럽게 더 잘 맞을 것이라고 생각합니다. 단점 없이 try 의 모든 현재 이점(이점을 고려하는 경우 중첩 제외)을 유지합니다. 나는 try 중첩이 누구에게도 도움이 되지 않는다고 생각합니다. 절약은 거의 하지 않지만 남용에 대한 무한한 가능성을 제공합니다. 나는 오늘 특별히 기분이 좋지 않으므로 이것이 내가 할 수 있는 최선이다.

total := try(try(os.Open(filename)).Stat()).Size() + try(strconv.Atoi(try(ioutil.ReadAll(os.Stdin))))

하지만 _우리_는 당신이 우리에게 허락한다면 최악의 상황을 생각할 것입니다.

@daved try(err) 를 두 번째 줄에 넣는 것은 기존 try 제안에서 완전히 지원됩니다. try 단순히 마지막 값이 다음과 같은 하나 이상의 값으로 평가되는 인수를 원합니다. error 입력하면 try(err) 를 작성할 때 자연스럽게 만족됩니다.

defer 에 대한 귀하의 우려를 따르고 있는지 잘 모르겠습니다. 다른 처리기가 필요한 경우 defer 가 올바른 선택이 아닐 수 있습니다. 대신 기존의 if 가 필요할 수 있습니다(제안서에 명시된 대로).

@cstockton 중첩된 try 가 매우 문제가 될 수 있다는 데 동의합니다. 그러나 나는 또한 우리가 try 있었다면 대부분의 코드가 당신이 제공 한 (유효한)

스타일의 문제로, 우리는 당신이 선호하는 것과 같은 제한을 언어에 넣지 않았습니다 - 우리는 그것을 위해 go vet 를 사용했습니다. 결국, 작성된 소프트웨어의 경우 효과는 동일합니다. 그러나 언어로 되어 있지 않다고 해서 우리 자신을 묶는 것은 아닙니다. 이러한 제한 사항을 올바르게 적용하는 것은 까다롭고 사양을 불필요하게 복잡하게 만듭니다. go vet 을 조정하는 것이 훨씬 쉽고 언어 조정보다 더 많은 것을 배울 때 더 똑똑하게 만듭니다.

@griesemer 설명 감사합니다. 코드 예제에서 첫 번째 줄이 var err error 인 경우 줄 바꿈이 두 확인된 오류에 잠재적으로 영향을 줍니까? 나는 섀도잉이 미래에 다루어질 수 있는 문제라는 이야기를 본 적이 있습니다. 그것은 이것과 어떤 관련이 있습니까?

시도에서 복구()와 같은 오류가 발견된 경우 catch()를 연기하여 catch() 함수를 추가하는 것은 어떻습니까?
예시:

func doSomthing()(err error){
    //return error
}

func main(){
    defer func(){
        if err:=catch();err!=nil{
            //found error
        }
    }()

    try doSomthing()
}

많은 기능에

func Foo() (err error) {
    defer func(){
        if err:=catch();err!=nil{
            //found error
        }
    }()

   try{
    file1 := open("file1")
    defer file1.Close()
    file2 := open("file2")
    defer file2.Close()
   }
   //without try
    file3,err := open("file3")
    defer file3.Close()
 }

이것이 각각의 오류를 별도의 방식으로 처리하는 데 어떻게 도움이 됩니까?

다른 사용자가 커밋한 것처럼

func Foo() (err error) {
    defer func(){
        if err:=catch();err!=nil{
            //found error
        }
    }()

    file1 :=try open("file1")
    defer file1.Close()
    file2 :=try open("file2")
    defer file2.Close()

        //without try
       file3,err := open("file3")
       defer file3.Close()
 }

@daved 이 예에서 err 가 결과 error 의 이름이라고 가정했습니다. try 는 이름(또는 이름의 부재)에 관계없이 항상 결과 오류 변수를 설정합니다. err 라는 로컬 변수가 있으면 다른 변수입니다. 결과 오류를 참조하려면 다른 이름을 가져야 합니다. 이것은 이미 유효하지 않은 경우입니다.

func f(...) (..., err error) {
   var err error // << err already declared
   ...

반면에 다음과 같이 작성하면:

func f(...) (..., err error) {
   a, b, ... err := g() // redeclaration of err
   ...

할당의 err 는 결과 매개변수 목록에 이름이 지정된 것과 동일합니다. 아주 오랫동안 이미 그랬던 것과 다를 바가 없습니다.

추신: 우리는 try 토론을 위해 이 문제를 가로채는 것을 중단하고 원래 제안으로 돌아가야 합니다. 잠금이 해제되어 내일(7월 1일) 다시 토론을 위해 열릴 것입니다.

@godcong catch() 함수(또는 이와 유사한 것)를 사용하면 오류를 얻을 수만 있고 설정할 수는 없습니다(일반적으로 오류 처리기로 작동하는 지연된 함수에서 둘러싸는 함수의 오류를 설정하려고 함). . catch() 가 *error 를 반환하도록 함으로써 작동하도록 만들 수 있습니다. 이는 둘러싸는 함수의 오류 반환 값의 주소입니다. 그러나 언어에 새 메커니즘을 추가하는 대신 오류 결과 이름을 사용하는 것은 어떻습니까? 이에 대해 논의된 try 제안도 참조하십시오.

또한 위 의 PS를 참조하십시오.

@griesemer

여기에서 더 명확하게 말하기는 어렵지만 제안 내용을 반복해 보겠습니다. 모든 오류 시나리오에서 try가 도움이 되지는 않습니다. 많은 경우에 도움이 됩니다. 다른 모든 경우에는 if 문을 사용하십시오.

저는 이것이 try() 제안의 치명적인 결함이라고 생각합니다. 이전에는 오류 검사를 수행하는 유일한 방법이 있었지만 이제는 두 가지가 코드 기반 전체에 혼합되어 있습니다. 의 또한, 코드베이스에 적어도 내가 일하고, 20 % 미만 if err != nil 교체 할 수 있습니다 try() 정도가를 만드는 동안 중요하지 않으면 서, 가치처럼 보이지 않는, 오류 처리 스타일로 나눕니다.

개인적으로 나는 모든 if err != nil 사례의 95%를 대신할 만큼 충분히 강력한 오류 처리 구문을 선호했을 것입니다. 많은 분들이 좋아하셨을 것 같아요.

@griesemer 나는 당신이 참조하는 스타일 가이드, 모범 사례, 예제, 문서 등이 모두 구식이기 때문에 사람들이 배우고 도구가 필수가 될 것이라는 데 동의합니다. 현재 제안된 시도가 잘못된 소프트웨어를 작성하는 미묘하고 새로운 방법을 도입한다는 것이 분명하다고 생각합니다. 명확하지 않은 것은 사람들이 항상 잘못된 소프트웨어를 작성할 수 있다는 전제 하에 이 사실을 무시하는 것이 어떻게 유효한 반론입니까?

여기서 각도를 바꾸겠습니다. 내가 설명한 잠재적 부작용에 대해 충분히 강력한 중첩 try 문에 대한 사용 사례는 무엇입니까? 오늘날 Go 코드는 체인 가능 중첩 가능 try-separated 괄호 파티가 어디에서나 맹렬하게 나타날 수 있도록 함으로써 어떤 이점을 얻을 수 있습니까? 내 생각에는 그렇지 않으며 아무도 중첩 시도를 요청하지 않았다고 생각합니다. 함수로 구현되기 때문에 제안과 함께 제공되었습니다. 언어 사양을 더 복잡하게 만들기 때문에 중첩 남용 또는 미묘한 오류를 제한하기 위해 중첩 제거/주소 지정과 같은 제약 조건을 추가하고 싶지 않습니다. 언어의 복잡성을 방지하거나 오류를 처리하는 더 나은 방법을 추가하기 위한 주제입니까?

여기서 목표가 언어 사양을 더 복잡하게 만들지 않는 것이라면 선택이 명확합니다. 일반 반환 및 매개변수가 있는 새 함수를 추가하지 마십시오. 그러나 특정 내장 인터페이스를 충족하는 경우에만) 그리고 아마도 전례 없이 복잡한 기능을 잊은 것 이상일 것입니다. 목표가 오류 처리를 개선하는 것이라면 오류를 생성하는 새로운 방법을 도입하지 않고 그렇게 해야 한다고 생각합니다.

@sirkon 나는 그 예를 지금 여러 번 보았습니다. 흥미롭다는 데 동의합니다. 하지만 조금 더 생각해보자. 제안된 try 내장은 기본적으로 Go 코드에서 발견되는 특정 종류의 상용구에 대한 구문 설탕입니다. 따라서 해당 예제를 원본 코드로 변환할 수 있습니다.

    f, err := os.Open(fileName)
    if err != nil {
        return err
    }
    info, err := f.Stat()
    if err != nil {
        return err
    }

해당 코드에는 동일한 버그가 있습니다. 나는 확실히 그런 코드를 보았다. try 내장이 그 버그를 작성하기 더 쉽거나 보기 어렵게 만든다는 것은 분명하지 않습니다.

그것은 나를 통지 파일에 "느린"기존의 흐름 잎 공간을 더 닫아야에 대한 분명이 try 사람들이 먼 길을 통해 바로 가기를 선호하는 경향이 누출의이 종류를 불러 일으킨다.

@godcong catch() 함수(또는 이와 유사한 것)를 사용하면 오류를 얻을 수만 있고 설정할 수는 없습니다(일반적으로 오류 처리기로 작동하는 지연된 함수에서 둘러싸는 함수의 오류를 설정하려고 함). . catch() 가 *error 를 반환하도록 함으로써 작동하도록 만들 수 있습니다. 이는 둘러싸는 함수의 오류 반환 값의 주소입니다. 그러나 언어에 새 메커니즘을 추가하는 대신 오류 결과 이름을 사용하는 것은 어떻습니까? 이에 대해 논의된 try 제안도 참조하십시오.

또한 위 의 PS를 참조하십시오.

Go의 유형 시스템은 60년대에 갇혔기 때문에 자연스럽게 극단적인 경우를 잘 처리할 수 없었습니다. 80년대의 아이디어를 빌릴 만큼 선견지명이 있었다면 오류가 발생하기 쉬운 미묘한 흐름을 제어할 수 있는 방법이 있었을 것입니다. 당신은 지금 중세 마을에서 유리와 금속 건물을 건설하려고 합니다. 나쁜 점은 이 중세 마을에는 전기와 수도관이 없으므로 당신도 가질 수 없을 것입니다.

새롭고 개선된 오류 시설이 golang/go 자체에 어느 정도 사용될 것인지 보는 것은 흥미로울 것입니다. 만약에 전혀.

go2 fmt 일반 go1.x 를 출력하는 옵션이 있는지 확인하는 것도 흥미로울 것입니다.

내 자신의 경험에서 다음과 같이 반환된 오류에 컨텍스트를 추가한 이후로:

import "github.com/pkg/errors"
func caller(arg string) error {
  val, err := callee(arg)
  if err != nil {
    return errors.Warpf(err, "failed to do something with %s", arg)
  }

  err = anotherCallee(val)
  if err != nil {
    return errors.Warpf(err, "failed to do something with %s", val)
  }

  return nil
}

지원 팀은 프로덕션에서 발생하는 문제에 대해 내 의견을 거의 필요로 하지 않습니다.

IMHO, 저는 오류 처리를 개선하는 것이 상용구 코드를 줄이는 것이 아니라 오류에 컨텍스트를 추가하는 보다 편리한 방법을 제공한다고 믿습니다. 나는 여전히 try()를 사용하는 좋은 현명한 방법을 찾을 수 없습니다.

지연에 컨텍스트를 추가할 수 있습니다.

func caller(arg string) (err error) {
  defer func() {
    switch t := err.(type) {
      case CalleeErr:
        err = errors.Wrapf(err, "failed to do something with %s", arg)
      case AnotherCalleeErr:
        err = errors.Wrapf(err, "failed to do something with %s", val)
    }
  }()

  val := try(callee(arg))
  try(anotherCallee(val)
  return nil
}

타이핑을 많이 줄이는 것 같지는 않지만 가독성과 성능을 희생합니다.

다음과 같은 방식으로 try()를 사용할 수 있습니다.

func caller(arg string) error {
    val, err := callee(arg)
    try(errors.Warpf(err, "failed to do something with %s", arg))

    err = anotherCallee(val)
    try(errors.Warpf(err, "failed to do something with %s", val))

    return nil
  }

그것은 몇 줄을 줄입니다, 그게 다야.

나에게 이 문제에 대한 대부분의 솔루션은 예외를 사용하는 다른 언어와 분리되어 있다고 생각했던 한 가지를 깨는 것 같습니다. 오류 처리 메커니즘이 제어 흐름으로 사용되지 않습니다. 이러한 솔루션의 대부분은 일부 형태의 제어 흐름(확인/처리, 시도, 캐치, 예상)을 추가하는 지점에서 Go 팀이 예외를 추가하고 하루라고 부를 수 있다고 생각합니다.

루비와 비슷한 if 및 return 의 특별한 경우가 있으면 좋겠지

return err if err != nil

추신: 언어 디자인에 대한 저의 경험이 부족한 점을 사과드립니다. 제가 어리석은 말을 했다면 자유롭게 지적하고 저를 교육해 주십시오.

시도에서 복구()와 같은 오류가 발견된 경우 catch()를 연기하여 catch() 함수를 추가하는 것은 어떻습니까?
예시:

func doSomthing()(err error){
    //return error
}

func main(){
    defer func(){
        if err:=catch();err!=nil{
            //found error
        }
    }()

    try doSomthing()
}

많은 기능에

func Foo() (err error) {
    defer func(){
        if err:=catch();err!=nil{
            //found error
        }
    }()

   try{
  file1 := open("file1")
  defer file1.Close()
  file2 := open("file2")
  defer file2.Close()
   }
   //without try
    file3,err := open("file3")
    defer file3.Close()
 }

이것이 각각의 오류를 별도의 방식으로 처리하는 데 어떻게 도움이 됩니까?

다른 사용자가 커밋한 것처럼

func Foo() (err error) {
    defer func(){
        if err:=catch();err!=nil{
            //found error
        }
    }()

  file1 :=try open("file1")
  defer file1.Close()
  file2 :=try open("file2")
  defer file2.Close()

        //without try
       file3,err := open("file3")
       defer file3.Close()
 }

귀하의 예에서는 동일한 지연으로 모든 오류를 처리합니다. 사용자 지정 메시지와 사용자 지정 정보를 오류에 추가하려는 경우 어떻게 됩니까?

@ianlancetaylor "추론된 반환"을 지원하기 위해 ":=" 연산자를 보강할 것을 제안한 사람이

• try 기능의 이름으로 논쟁이 있었습니다. 우리가 이것을 기능으로 구현하는 한, 아무도 100% 좋게 느낄지 확신할 수 없는 이름을 지정해야 합니다.
• try 는 전례 없는 수의 일을 수행하며 append() 와 같은 입력을 가지며 유비쿼터스 패턴( if err != nil )을 대신하면서 panic() 와 같은 제어 흐름에 영향을 미칩니다. .
• try 중첩은 엄격한 기술 토론에서 파생된 부가 가치가 아니라 기능으로 구현하기로 결정한 결과입니다.
• try 는 이전 버전과의 호환성을 유지하기 위한 기능으로 구현됩니다.

유형을 수행하는 것처럼 단순히 반환을 추론하면 상황이 간결해 보이고 다음과 같이 "가기"가 더 많이 느껴집니다.

f, err := os.Open(filename)
if err != nil {
   return ..., err
}
defer f.Close()

info, err := f.Stat()
if err != nil {
   return ..., err
}

_여기에 이 ​​동작에 대한 올바른 컴퓨터 과학 설명을 삽입하세요_. 그때까지 짧은 변수 선언을 통해 추론된 수익을 해결하세요.

f := os.Open(filename)
defer f.Close()
info := f.Stat()

다음보다 훨씬 깔끔해 보입니다.

f := try(os.Open(filename))
defer f.Close()
info := try(f.Stat())

이것은 (내 의견으로는) 좀 더 "좋아요"를 느끼고 이전 버전과의 호환성을 유지하면서 위에 나열된 모든 문제를 해결합니다. 다른 모든 언어에서 try 의 보편적인 의미를 고려할 때 try() 에 대한 함수 호출에 대한 "암시적" 반환은 설명하기가 좀 더 쉬운 것 같습니다. 구현에 대해 100% 말할 수는 없지만 거의 동일한 노력으로 잠재적으로 수행할 수 있는 것 같습니까? AssignStmt 는 LHS의 어떤 표현식이 내장과 동일한 백엔드 컴파일을 알리기 위해 오류 값을 생략했는지 지정하는 필드를 추가할 수 있습니까?

오류를 있는 그대로 확인하는 것도 좋지만 이것이 진정 해결해야 할 문제라면 새 키워드가 더 나은 솔루션이 되지 않을까 생각합니다. 모든 솔루션에는 제어 흐름 변경이 포함될 수 있으며 가능한 한 명확하게 하는 것이 가장 좋습니다.

이 예에서 on 조건은 err 가 설정될 때마다 평가됩니다.

func example() (foo int, err error) {
    on err != nil {
        return foo, err
    }

    foo, err = calcThis()
    foo, err = calcThat(foo)

    return
}

이것은 함수 서명에서 반환 값의 이름을 선언하지 않고도 작동합니다.

func example() (*int, error) {
    var err error

    on err != nil {
        return nil, err
    }

    foo, err = calcThis()
    foo, err = calcThat(&foo)

    return &foo, nil
}

여러 번 설정할 수도 있습니다. 다음은 인위적인 예입니다.

func example() (*int, error) {
    var err error

    on err != nil {
        return nil, err
    }

    foo, err = calcThis()

    on err != nil {
        return &foo, err
    }

    foo, err = calcThat(&foo)

    return
}

내 눈에 이것은 Go의 스타일과 가독성을 유지하면서 err 가 설정될 때마다 해당 조건을 효과적으로 삽입하기 때문에 각 단계(패러다임을 이해하면)에서 무슨 일이 일어나고 있는지 명확하게 합니다.

다음을 수행할 수도 있습니다.

func example() (foo int, err error) {
    var message string

    on err != nil {
        return foo, errors.Wrap(err, message)
    }

    message = "failed to calc this"
    foo, err = calcThis()

    message = "failed to calc that"
    foo, err = calcThat(foo)

    return
}

마지막으로, 이것은 오류 처리를 넘어 적용할 수 있습니다. foo == 0이면 반환하고 싶습니까? 또 다른 고안된 예:

func example(i int) bool {
    on x == 0 {
        return false
    }

    x = calcSomeInt(i)
    return true
}

@cstockton

나는 그런 식으로 오류를 피하는 것이 너무 쉬울 것이라고 항의하려고 했지만:

• 이것은 json.Unmarshal 와 같이 _only_ 오류를 반환하는 함수가 있는 이미 "잡았다"입니다. IME 좋은 코드 검토자는 이것을 꽤 빨리 살펴보는 법을 배웁니다.
• http.Handler 메서드와 같이 오류 값을 반환하지 않는 함수에서는 여전히 구문 오류입니다.
• 오류를 처리하는 방법을 알고 있다면 그것에 대해 생각하고 예상하고 처리할 수 있도록 어쨌든 오류 값을 캡처할 것입니다.
• 다른 사람의 문제(호출자의 문제)로 만들기 위해 발생한 오류를 다시 전달하려는 의도인 경우 컨텍스트에 대해 더 많은 주석을 명시적으로 추가할 기회를 놓친다는 작은 단점이 있습니다.

그래서, 내가 생각할 수 있는 모든 장점을 평가하고 명백한 단점을 알아차리지 못한 후, 나는... 울타리에 있습니다. 내가 고려하지 않은 명확하지 않은 단점이 있다고 생각합니다. 그러나 나는 이것이 누구에게나 가치가 있는 것이 아니더라도 이것이 어디로 가고 있는지를 좋아하기 시작했습니다.

이것이 올바른 대응 방법이기를 바랍니다.
심각한 가짜.

19년 7월 1일에 Chris Stockton [email protected] 은 다음과 같이 썼습니다.

@ianlancetaylor 지원하기 위해 ":=" 연산자를 보강할 것을 제안한 사람이
"추론된 반환" - 기본적으로 함수 없이 try와 똑같이 동작합니다.
전화. [ ... ]

이 사건에서 내가 흥미롭게 생각하는 것은 우리에게 무언가가 있다는 것입니다
"오류"를 생략하는 "쉼표 확인" 패러다임과 유사합니다.
양수인은 일부 잘 정의된 상황에서 허용됩니다. 가치
그러나 분명히 그 자체로는 이것을 유효하게 만들기에 충분하지 않습니다.
제안.

루시오.

이 버그는 이미 가능합니다. 시도하든 말든 - Go는 나쁜 코드를 작성하는 것을 막지 않습니다. 또는 시도를 허용하지 않아야 하는 이유로 나쁜 코드를 사용하는 것은 설득력 있는 주장이 아닙니다. 대신 수의사는 문제가 있는 사례에 플래그를 지정해야 합니다.

@griesemer 동의하지 않습니다. 키 입력을 절약할 수 있지만 포인터 산술은 잘못되고 깨진 코드를 쉽게 작성할 수 있다는 전제 하에 Go에서 제외되었습니다. 나는 이것이 버그를 감지하기 더 어렵게 만드는 동일한 유형의 기능이라고 생각합니다.

data := try(ioutil.ReadAll(try(os.Open("foo.txt"))))

try 의 일반적인 예는 위와 같은 예를 사용하는데, 이는 분명히 파일 설명자를 누출합니다. (Go가 현재 구현에서 사용자에게 알려지지 않은 상태에서 런타임에서 이러한 설명자를 찾아 닫는다는 사실은 우리에게 위안을 줄 수 있지만 어쨌든 더 나은 예가 있습니다).

data := try(ioutil.ReadAll(try(http.Get("http://example.com/")).Body))

위의 코드는 올바른 코드처럼 보이지만 응답 본문을 완전히 읽은 다음 행복한 경로에서 닫는 요구 사항을 무시합니다. 충분히 길게 보면 잘못된 예제의 역겨운 우아함을 통해 미래에 이러한 유형의 버그를 보게 될 것임을 분명히 해야 합니다.

이 시점에서 코드를 작성하는 것보다 더 많은 것을 검토하는 사람으로서 나는 Go가 부정확성을 유혹하는 기능을 추가하지 않는 것을 선호합니다.

@jesse-amano 할당 연산자를 사용하면 아래의 명시적인 할당 문이 오늘날처럼 정확하게 동작하지 않고 실제로 이 경우가 가능한 것을 방지할 수 있습니다. 예:

json.Unmarshal(...)
(http.Handler)(h).ServeHTTP(w, r)

오류를 반환하는 값은 return json.Unmarshal(...) 와 같이 반환될 수 있으며 if 블록 외부에 값이 존재할 필요가 없기 때문에 보다 간결한 형태로 표현할 수도 있습니다.

if err := json.Unmarshal(...); err != nIl {
    return err
} 

이 경우 내가 흥미롭게 생각하는 것은 "오류" 양수인을 생략하는 것이 일부 잘 정의된 상황에서 허용되는 "쉼표 확인" 패러다임과 유사한 것이 있다는 것입니다. 주목할 가치가 있지만 분명히 그 자체로는 이것을 유효한 제안으로 만들기에 충분하지 않습니다.

동작은 괄호 또는 임의의 중첩 및 연결 없이 시도하는 것과 동일합니다. 대부분의 사람들이 언어를 깨뜨리지 않고는 자연스럽다고 생각하는 것을 찾기가 어려울 것이라고 생각합니다. Go 작성자가 Go에 이러한 유형의 기능을 추가하기로 결정한 것 같아서 저는 사실 try 의 현재 형태가 Go에 적합하지 않다고 절대적으로 확신하기 때문에 대안을 깊이 파고들고 있습니다. 이것은 BC를 깨뜨리지 않을 것이라고 생각할 수 있는 가장 가까운 것입니다. 어느 쪽이든 나는 시도 제안이 거부되거나 누군가 더 많은 사람들이 동의할 수 있는 무언가를 제안하기를 바랍니다.

편집: @jesse-amano 나는 당신의 요점을 완전히 놓쳤습니다 죄송합니다! 오류를 반환하지 않는 함수 안에 있으면 일반적인 할당 횟수 불일치 컴파일 오류가 표시될 것이라고 가정합니다. 나는 try가 아마도 새로운 유형의 컴파일러 오류 메시지를 도입할 것이라고 상상합니다.

@beoran 관련 https://github.com/golang/go/issues/32825#issuecomment -507126700 : 이미 상황에 따라 오류 처리가 다릅니다. 변경되지 않은 상태로 오류를 반환할 때도 있고 장식된 오류를 반환할 때도 있고 조치를 취할 때도 있습니다. 오류가 발생하면 때때로 오류를 (정확하게) 무시할 수 있습니다. 그들이 공유하는 유일한 것은(오류를 무시할 때를 제외하고) err != nil 테스트입니다(이미 한 가지 이상의 방법으로 수행할 수 있음). 새로운 언어 기능이 이러한 모든 경우(또는 그 중 95%)를 캡처하는 것이 좋은 만큼, 그러한 구성은 우리가 이미 가지고 있는 다른 제어 구성과 직교하지 않은 방식으로 간섭할 가능성이 높습니다. 즉, 우리가 기대할 수 있는 최선은 이러한 경우 중 일부(20%, 50%)를 개선하는 것입니다.

@cstockton 관련 https://github.com/golang/go/issues/32825#issuecomment -507136111: 중첩된 try 가 유일한 도로 블록이고 go vet 가 충분하지 않은 경우 , 내 생각에 중첩된 try 허용하지 않는 것을 고려할 수 있습니다. 충분히 쉬울 것입니다. 그러나 현재로서는 try 진지하게 실험한 사람이 거의 없는 상태에서 우리는 여전히 FUD(공포, 불확실성, 의심) 단계에 있다고 생각합니다. 나는 그렇게 한 사람들이 긍정적으로 보고했다는 점에 주목한다.

추신: try 문제는 피드백을 위해 다시 열려 있습니다. 계속해서 거기에 갑시다.

@cstockton 아, 물론입니다. 명확히 하자면, 대부분의 경우 오류 값을 캡처하지 않고 json.Unmarshal 와 같은 함수를 호출하는 것은 _이미_ 나쁜 습관이지만 일반적으로 defer file.Close() 대신 나쁜 습관으로 간주되지 않습니다. defer func() { err = file.Close(); if err != nil { ... }; }() , 그리고 우리는 그 차이를 아주 쉽게 구별하는 법을 배웠습니다. 따라서 (아마도) 제안된 변경 사항이 적용됩니다. 나는 처음에 누군가가 오류를 처리할 의도로 foo := strconv.ParseFloat(bar, 64) 무고하게 사용한다는 생각에 움찔했지만, 잠시 생각해 본 결과 결국 문제라고 생각하지 않습니다.

@sirkon 관련 https://github.com/golang/go/issues/32825#issuecomment -507167388 : 그러한 명확하지 않은 진술은 토론에서 제외하십시오. 기록을 위해 Go의 많은 아이디어는 실제로 60년대가 아닌 80년대(패키지, 별도의 컴파일 등)에서 나온 것이며 많은 아이디어가 훨씬 더 젊습니다(고루틴, 인터페이스). 이러한 아이디어는 여전히 오래된 것처럼 보일 수 있지만 시간의 테스트를 견뎌냈습니다(적어도 CS가 등장한 지 얼마 되지 않은 시간).

@turtleDev 관련 https://github.com/golang/go/issues/32825#issuecomment -507231353: Go는 예외 처리를 수행하고 panic 및 defer 및 recover - "예외 처리"라는 용어는 Go에 대해 오해의 소지가 있는 의미를 내포하고 있기 때문에 이를 "예외 처리"라고 부르지 않습니다. 그러나 단지 명확하게하기 위해, 이동하는 모든 작업을 수행 할 수 있습니다 raise 와 try-catch 할 수있는 등 (때문에 달리 try-catch , defer 사용할 수 있습니다 조건부). 감사 해요.

@sorenvonsarvort 관련 https://github.com/golang/go/issues/32825#issuecomment -507268293: 각 사례에 대해 다른 오류 장식을 원하면 if 문을 사용하세요. 디자인 문서를 참조하십시오. 이 질문은 지금까지 여러 번 답변되었습니다. 감사 해요.

@cstockton 관련 https://github.com/golang/go/issues/32825#issuecomment -507306652: 예, 이러한 메커니즘에 대해 생각해 보았습니다. 특히, "테이블 뒤집기"에 대해 생각하고 try 를 제공하는 대신 오류 처리기를 선언하는 handle 를 제공하면 됩니다. 핸들러가 존재하는 경우(그리고 그때만), 할당의 LHS에 err 를 남겨두고 암시적으로 검사됩니다(예: 보이지 않는 try ). 보기에는 좋아 보이지만 완전히 눈에 띄지 않는 큰 적신호입니다. 우리는 예외 처리가 코드의 모든 위치에서 명시적으로 표시되기를 원합니다. 그것 없이는 코드를 읽고 오류 검사가 일어나는 곳을 보는 것이 거의 불가능합니다.

@griesemer 명확히

@matthew-noken 관련 https://github.com/golang/go/issues/32825#issuecomment -507323973: 흥미로운 아이디어를 제안하고 계십니다. 디버거의 감시점 메커니즘과 매우 흡사합니다. 대답해야 할 몇 가지 질문이 있습니다. on 블록이 반환되어야 합니까(그렇지 않으면 스파게티 코드 영역에 들어가기 때문에 그렇게 생각합니다)? 그러한 on 문을 두 개 이상 가질 수 있습니까? on 조건이 얼마나 복잡할 수 있습니까(각 할당 시 평가되어야 함)? on 문으로 변수를 고유하게 식별해야 하므로 임의의 표현식을 가질 수 없습니다. 또한 Go: on 구문에서 다소 불명예스러운 코드는 다른 곳에서 실행될 보이지 않는 코드를 의미합니다.

이것을 더 탐구하고 싶다면 다른 곳에서 논의할 것을 제안합니다(golang-nuts, 또는 다른 새로운 제안). 감사 해요.

@as 관련 https://github.com/golang/go/issues/32825#issuecomment -507345821:

포인터 산술은 잘못되고 깨진 코드를 쉽게 작성할 수 있다는 전제 하에 Go에서 제외되었습니다.

사실, 가비지 수집을 어렵게 하거나 불가능하게 만들 수 있기 때문에 제외되었습니다(예, 안전하지 않은 코드를 작성할 수도 있습니다). 그러나 여기서 더 중요한 점은 이 결정을 뒷받침하는 구체적인 증거와 경험이 있다는 것입니다.

중첩된 try 가 널리 퍼질 것이라는 경험과 증거는 아직 없습니다. 그러나 https://github.com/golang/go/issues/32825#issuecomment -507358397을 참조

@turtleDev 관련 https://github.com/golang/go/issues/32825#issuecomment -507368167 : panic 는 _정확히_ 예외이며 지연된 함수 내부의 recover 는 본질적으로 catch . Go에서는 예외를 사용하여 코드를 작성하는 것을 권장하지 않기 때문에 프로덕션 코드에서 찾기가 더 어려울 수 있습니다. 예외적인 상황에서만 사용해야 합니다.

제어 흐름 구조의 수와 관련하여: 제안은 try 이 단순히 구문상의 설탕이며 다른 것이 아니라는 것이 매우 분명합니다.

이 스레드에 대한 이 스레드의 최근 댓글에 답변하려고 했습니다. 그러나 실제 try 문제 #32437(오늘부터 다시 잠금 해제됨)에서 try 제안에 대한 새로운 의견을 계속해 보겠습니다. leave err != nil alone 토론을 위해 이 문제를 남겨두십시오. 감사 해요.

@cstockton https://github.com/golang/go/issues/32825#issuecomment -507306652에 대한 또 다른 의견 : 이것을 구현했다면

    func f() int { ... }
    ...
    x := f()

그리고 변경

    func f() (int, error) { ... }

x := f() 이 갑자기 그리고 조용히 매우 다르다는 것을 의미합니다.

@lpar 가 모든 go 리포지토리에서 수행한 것과 유사한 몇 가지 실험을 실행했습니다. 결과는 이 요지에 있습니다: https://gist.github.com/freeformz/55abbe5da61a28ab94dbb662bfc7f763

@ianlancetaylor 나는 실제로 이것이 대부분의 경우에 매우 잘 작동하고 더 나은 오류 보고를 도입하는 것이 훨씬 덜 영향력이 있다고 생각합니다. 두 가지 주요 경우에 대한 전체 예를 고려하십시오. 먼저 호출자가 오류를 반환합니다.

func f() int { ... }
func a() error {
    x := f() // if f() is updated to return an error, we get automatic error propagation by default
    ...
}

func b() {
    x := f() // if f() is updated to return an error, we get the same compiler error 
    // assignment mismatch: 1 variable but pkg.f returns 2 values
}

일반적인 경우에 이것이 이 접근 방식의 좋은 이점이라고 생각합니다. 이것이 문제를 일으키는 코너 케이스는 이미 취약하다고 생각합니다. 내가 생각할 수 있는 유일한 것은 뮤텍스 교착 상태입니다.

func (t *T) a() error {
   t.mu.Lock()
   x := f() // if f() is updated to return an error, we get automatic error propagation by default
   if x > 15 {
     t.mu.Unlock()
     return errors.New("t > 15")
   }
   ...
}

그러나 그렇게 작성된 코드는 유효한 프로그램 상태를 갖기 위해 외부 라이브러리 호출에 의존하는 경우 이미 교착 상태에 취약하다고 생각합니다. 패닉을 넘어 살 수 있는 범위에 저장된 경우 동일한 라이브러리에서 NPE를 통해 런타임 패닉이 발생하면 교착 상태가 될 수 있습니다. 또한 이와 같은 코드를 작성하게 된 주요 동기는 힙에 존재하는 연기의 역사적 비용입니다. 스택에 있는 단일 지연의 성능 향상으로 인해 이러한 코드는 실제로 필요하지 않습니다. 나는 이러한 유형의 오류를 쉽게 유도할 수 있다고 생각합니다.

마지막으로 툴링으로 "시도"의 단점을 뒷받침하는 주장과 마찬가지로 여기에도 적용될 수 있습니다. go-modules의 채택이 증가했음을 감안할 때 "라이브러리 업그레이드 린트" 단계를 삽입하여 이러한 변경 사항을 사용자 앞에 명확하게 표시할 수 있는 좋은 기회가 있습니다.

@griesemer

제어 흐름 구조의 수와 관련하여: 제안은 try가 단순히 구문적 설탕이며 다른 것이 아니라는 것이 매우 분명합니다.

실례합니다. 하지만 try 는 매크로(C와 같은)가 되지 않을 것이므로 사실상 최종 사용자에게는 흐름 문의 또 다른 제어일 뿐입니다.

이 시점에서 객관적인 주장이 없다고 생각하므로 더 나은 오류 처리가 필요할 수 있음을 인정하지만 try 가 최상의 솔루션이 아닐 수도 있습니다.

다시 말하지만, 이것들은 제 의견이며 저는 단지 그것들을 대표할 뿐입니다. 나는 바둑 팀이 나보다 훨씬 더 많은 생각을 했다고 확신한다.

측면: try 제안서(#32437)에는 279개의 반대 투표가 있는 반면 이 문제에는 1335개의 찬성표가 있다는 것이 이상 합니다 . 나는 이것을 찬성하는 사람들이 try 제안에 반대 투표를 하기를 기대합니다. 이 두 제안은 상호 배타적이기 때문에 이에 대한 커뮤니티의 감정이 더 분명해집니다.

@griesemer

오류 처리는 이미 상황에 따라 다릅니다. 때로는 오류를 변경하지 않고 반환하고, 장식된 오류를 반환하고, 때로는 오류에 대해 조치를 취하고, 때로는 (정확하게) 오류를 무시할 수 있습니다.

거기에 동의하면 그 정도는 분명합니다.

그들이 공유하는 유일한 것은(오류를 무시할 때를 제외하고) err != nil 테스트입니다(이미 한 가지 이상의 방법으로 수행할 수 있음). 새로운 언어 기능이 이러한 모든 경우(또는 그 중 95%)를 캡처하는 것이 좋은 만큼, 그러한 구성은 우리가 이미 가지고 있는 다른 제어 구성과 직교하지 않은 방식으로 간섭할 가능성이 높습니다. 즉, 우리가 기대할 수 있는 최선은 이러한 경우 중 일부(20%, 50%)를 개선하는 것입니다.

제안된 try() 문은 또한 비직교 방식으로 if 및 return 를 "간섭"하므로 그 주장이 옳지 않다고 말하고 싶습니다. 여기에 있는 어떤 사람들은 바로 그 이유로 try() 를 싫어하지만 저는 동의하지 않습니다. Go는 Oberon이 아닙니다. 단순하지만 미니멀하지 않습니다. Go는 더 실용적입니다.

우리가 동의하지 않는 부분은 당신이 스스로 인정한 바와 같이 사용과 적용 가능성이 제한적이며 이미 if 및 return 올바르게 수행할 수 있는 언어 구성으로 귀찮게 할 가치가 있다는 것입니다 try() 너무 압도 되어 아예 갖지 않으려고 합니다. 리턴과 직교하지 않더라도 더 강력하고 일반적으로 유용한 try() 는 아마도 대부분의 Go 프로그래머가 보고 싶어하는 것입니다.

@베오란

"더 강력하고" "더 일반적으로 유용한" try() 원한다고 썼습니다.

@griesemer 는 4가지 상황을 언급했습니다.

1. 오류를 변경하지 않고 반환
2. 장식된 오류 반환
3. 오류에 대한 조치
4. 오류 무시

try() 는 의도적으로 1을 해결합니다. 말 그대로 if err != nil { return ..., err } 의 지름길입니다.

기존 언어 구조는 3과 4를 해결합니다. 우리는 이미 if err != nil { ... } 로 오류에 대처할 수 있으며 이 경우 더 간결한 구조를 찾기가 어려울 것입니다. 이미 _ 오류를 무시할 수 있습니다.

이것은 우리에게 2를 남깁니다(데코레이팅된 오류를 반환). try() 제안은 defer 문을 사용하여 오류를 장식하거나 각 오류를 다르게 장식해야 하는 경우 표준 if err != nil { ... } 구조를 사용하도록 제안합니다.

제안의 이 부분 에서 추론이 잘 설명되어 있습니다.

이 제안의 첫 번째 반복은 연산자 대신 내장을 사용하는 오류 처리의 핵심 부분 과 새로운 오류 처리기 언어 구성 대신 오류를 처리하는 일반 Go 함수의 두 가지 아이디어에서 영감을 받았습니다. 그 게시물과 달리 오류 처리기는 문제를 단순화하기 위해 고정된 함수 서명 func(error) error 을 가졌습니다. 에러 핸들러는 try 둘러싸는 함수에서 반환되기 직전에 에러가 있을 때 try 에 의해 호출됩니다. 다음은 예입니다.

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

f := try(os.Open(filename), handler)              // handler will be called in error case

이 접근 방식은 효율적인 사용자 정의 오류 처리기의 사양을 허용했지만 분명히 정답이 없는 많은 질문을 열었습니다. 처리기가 제공되었지만 nil이면 어떻게 됩니까? try 패닉을 일으키거나 결석 오류 처리기로 처리해야 합니까? 핸들러가 nil이 아닌 오류로 호출된 다음 nil 결과를 반환하면 어떻게 될까요? 이것은 오류가 "취소됨"을 의미합니까? 아니면 둘러싸는 함수가 nil 오류와 함께 반환되어야 합니까? 또한 선택적 오류 처리기를 허용하면 프로그래머가 적절한 오류 처리를 완전히 무시하게 될 것인지도 분명하지 않았습니다. 또한 모든 곳에서 적절한 오류 처리를 쉽게 수행할 수 있지만 try 의 단일 발생을 놓치게 됩니다. 기타 등등.

다음 반복에서는 오류 래핑에 defer 를 사용하기 위해 사용자 정의 오류 처리기를 제공하는 기능을 제거했습니다. 이것은 코드에서 오류 처리기를 훨씬 더 잘 볼 수 있게 했기 때문에 더 나은 접근 방식처럼 보였습니다. 이 단계에서는 오류 처리기로서의 선택적 기능에 대한 모든 질문을 제거했지만 액세스가 필요한 경우 오류 결과에 이름을 지정해야 했습니다(우리는 이것이 괜찮다고 결정했습니다).

[...]

명시적으로 제공되는 오류 처리기 함수의 형식이나 해당 문제에 대한 다른 추가 매개변수를 갖는 것이 좋은 생각이라고 판단되면 해당 추가 인수를 try 호출에 전달하는 것이 거의 가능합니다.

이 논리에 동의하지 않습니까?

나는 제안의 이 부분을 알고 있고 그것에 동의하지 않습니다. 왜냐하면 오류 처리기를 전달한다는 아이디어로 인해 질문이 열렸다는 사실이 그러한 기능이 필요하지 않다는 것을 의미하지는 않기 때문입니다. 그것은 우리가 합리적인 방식으로 그러한 질문에 답하기 위해 잘 생각해야 한다는 것을 의미합니다.

또한, 이제 우리는 널리 이해되고 일관된 Go 관용구인 if err != nil 문으로 4가지 오류 사용 사례를 모두 처리합니다. 사례 1에 대해 try() 만 사용하고, 경우에 따라 2에 대해 defer 문에서 오류 래핑을 수행하는 오버헤드에 신경 쓰지 않는다면 오류 처리를 위한 코드가 if 로 분할됨을 의미합니다 try 일관되지 않고 오류 처리가 변경되면 둘 사이를 전환해야 합니다.

모든 경우에 사용할 수 있는 더 강력한 try() 버전을 사용하면 거의 항상 try() 를 사용할 수 있으며, 이는 Go에 대한 새롭고 일관된 오류 처리 관용구가 됩니다.

그러나 지금과 같이 try() 를 사용하면 충분히 널리 적용할 수 없으며 앞서 언급한 오류 처리의 불일치를 코드 기반에 도입할 만큼의 편의성이 충분하지 않습니다. 그렇기 때문에 현재의 try() 제안에 압도당하고 아무것도 하지 않는 것이 낫다고 생각하는 이유입니다.

@beoran 사례 1과 2는 공통적으로 함수에서 오류를 반환한다고 생각합니다(각각 장식이 있거나 없는 경우). 반면 사례 3과 4는 그렇지 않습니다(각각 오류에 대해 조치를 취하고 오류를 무시함). 나는 'try()' 초점이 사례 1과 2에 있다고 생각합니다.

선택적 처리기 기능을 수락하여 try() 제안을 개선하여 사례 1 과 2를 처리할 수 있다면 어떨까요? 물론 이를 위해서는 제안서에 나열된 질문에 대한 합리적인 답변을 찾아야 하지만 다루기 쉬운 것 같습니다. 그런거 지원해줄래?

여기 나와. 이에 대한 경우 사용자가 오류를 확인하기를 원하면 확인된 오류(확인된 예외와 같은 종류)를 추가해야 합니다. 그렇게 하면 가능한 한 명시적이며 사용자는 모든 오류를 확인하고 있음을 알 수 있습니다.

진지하게 말해서, 내가 이러한 결정을 내리는 배후에 있었다면 Kotlin ? 연산자나 Rust unwrap() 동작과 같은 것을 용도 변경하고 싶습니다.

다음 중 하나가 개선될 것이라고 생각합니다.

getFile()?.getPath()?.toString()

당신이 얻을 어디 nil 다시 길을 따라 에러가 발생했을 경우 또는

get_file().unwrap().get_path().unwrap().lossy_to_string()

오류가 있으면 중간에 폭발합니다. Rust는 오류를 철저하게 검색하고 각각을 개별적으로 처리할 수 있는 표현적인 match 함수를 사용하여 두 번째 문제를 처리합니다.

19년 7월 2일 Nicolas Grilly [email protected] 은 다음과 같이 썼습니다.

@beoran 사례 1과 사례 2에는 오류를 반환한다는 공통점이 있다고 생각합니다.
기능(각각 장식 없음 및 있음), 경우 3 및 4
하지 마십시오(각각 오류에 대해 조치를 취하고 오류를 무시함). 나는 '시도()'라고 생각한다.
사례 1과 2에 중점을 둡니다.

내 제안에 대한 더 많은 토론을 볼 수 없다는 것이 다소 실망스럽습니다.
"오류 반환"의 "반환" 부분은
"오류" 부분이 아니라 해결되었습니다.

그렇다면 더 공식적인 접근 방식을 따랐어야 했을 수도 있습니다. 나는
단순히 제안을 공식화하는 데 능숙하지 않습니다.
장소.

사례 1과 2는 제 생각에 "실패" 명령으로 더 잘 제공됩니다.
(일부 익숙해진 후) 명확하게 나타내는 키워드
프로그램 흐름의 변경 사항이며 어떠한 영향도 받지 않습니다.
전체 구문과 관련하여 불편한 전통.

그러나 그 결과 우리가 좋든 싫든
마지막 반환 매개변수로 "err"의 위치는 곧
관습이 아니라 법이 된다. 그것은 많은 "의도하지 않은"또는
고려해야 할 "부수적" 결과.

최소한의 것에서 다음과 같은 결과가 많이 있을 것입니다.
비참한, 일부는 기회주의적으로
제안. 나는 개인적으로 조심하는 편에서 실수할 것이다.
바둑팀과 로버트가 특히 추구하는 이유를 이해하십시오.
저항이 그렇게 밝혀졌다는 것은 의심의 여지가 없습니다.
엄청난.

정치적 이념의 충돌, 아마도 우리는 많이 파헤쳐야 할 것입니다.
원예의 관심이 필요한 진정한 뿌리를 찾기 위해 더 깊이 있습니다.

@lootch try 가 작동하려면 마지막 반환 매개변수가 되어야 하는 오류에 대해 특별히 우려하고 있습니까? 이미 사실상의 협약 아닌가요?

(제쳐두고, 우리는 저항에 대해 "상처"하지 않습니다. 대부분은 과도한 반응에 대해 당황합니다.)

@griesemer 오래된 자동차 비유에 대해 유감스럽게 생각하지만 제안은 "우리는 모든 가솔린 자동차에 디젤 연료 시스템을 추가하거나 모든 가솔린 자동차에 배터리와 전기 모터를 추가하기로 결정했습니다." Go의 오류 처리는 충분합니다. 추가된 부가가치가 새로운 총기 및 정신적 오버헤드를 포함하여 비용보다 적을지 걱정됩니다.

Go를 많이 작성했기 때문에(저는 2009년 첫 공개 릴리스 이후로 Go를 사용하고 있습니다. 제 github 참조) 오류 처리와 관련된 인체 공학을 개선하는 것을 환영합니다. Go의 오류 처리가 명확하기는 하지만 순차 코드에서는 골칫거리이기도 합니다. 내 경험상 실제 값 자체에 대한 성찰과 타이핑의 부족은 실제로 프로그램의 탄력성을 향상시키지 않습니다.

나는 몇 년 전에 이것에 충분히 짜증이 났고 실제로 공황과 관련하여 약간의 설탕을 썼고 확인되지 않은 예외처럼 (대부분) 작동하도록 복구했습니다. https://hackthology.com/exceptions-for-go-as-a-library. HTML . 실제로 해당 래퍼를 사용하는 것은 커뮤니티가 있기 때문에 나쁜 생각입니다. 그러나 오류 처리와 관련하여 인체 공학을 개선하는 것이 승리라고 계속 믿습니다.

사람들이 오류 조건을 전파하는 데 매우 장황하지만 도움이 되지 않는 방법을 유지하기 위해 열렬히 논쟁하는 것은 미친 것 같습니다. 사람들이 if err != nil 조건을 엉망으로 만들고 버그를 만든 코드(및 다른 사람의 코드)에서 실제 버그를 작성하고 찾았습니다. 이러한 버그가 작성될 이유가 없습니다. 정적 검사는 이러한 버그를 제거하는 데 도움이 될 수 있지만 제거할 수는 없습니다.

나는 오류 처리와 관련된 인체 공학을 개선하기 위한 제안을 지지합니다.

제안 프로세스는 https://golang.org/s/proposal 을 인용하여 "Go로의 변경 제안"을 위한 것입니다.
이 문제는 변경을 제안하는 것이 아니므로 실제로는 약간의 범주 오류입니다.
누군가가 "선택만 남겨두기"라는 제목의 제안서를 제출했다면 제안서가 아닌 것으로 간주하여 닫을 것입니다.

그러나 실제로 이 문제는 #32437과 같은 다른 문제에 대한 논의의 확장일 뿐이므로 "아무것도 하지 않음"에 대해 논의하기에 좋은 장소로 남겨두겠습니다.

여기에는 특정 결정이 없고 메타 결정에 가깝다는 것을 나타내기 위해 제안 보류로 표시했습니다.

측면: try 제안서(#32437)에 _만_ 279개의 반대 투표가 있는 반면 이 문제에 1335개의 찬성표가 있다는 것이 이상합니다.

시도 제안은 내가 그것을 알게 되었을 때 잠겨 있었고 그래서 나는 그것을 반대할 수 없었습니다. 이 제안이 처음부터 시작된 이유이기도 하다고 생각합니다.

19년 7월 2일에 Robert Griesemer [email protected] 은 다음과 같이 썼습니다.

@loot 마지막이 되어야 하는 오류에 대해 특별한 우려가
try 가 작동하도록 매개변수를 반환하시겠습니까? 이미 사실상 확정 아닌가요
협약?

나는 그것이 "사실상" 돌로 주조된 것이 된다면,
그 문은 활짝 열려야 하고 "오류"를 선택적이고 특별하게 만들어야 합니다.
모든 올바른 결과에 대해
종종 잘못된 것보다 훨씬 더 자주, 그들은 또한 그렇게 될 수 있습니다
특별한 방식으로 처리됩니다.

"반환" 문을 조사해야 한다는 생각이 들면
더 깊이 (그리고 시도 제안은 그것을 암시하는 것 같습니다
방향), 오류 조건은 더 이상 "단순한 값 및
Go의 접근 방식은 최고의 카드 하우스와 유사하기 시작합니다.
날짜, 그러나 카드의 집, 그럼에도 불구하고.

나는 몇 가지 Go의 더 영리한 트릭을 꺼려하는 사용자입니다(저는
다른 곳에서 x++ 및 x-- 기능이 없다고 언급했습니다.
때때로 - 내 코드에서) "시도"는 나에게 그 중 하나로 남아 있습니다.
그러나 나는 원칙적으로 도입에 반대하지 않는다.
너무 많이 말했지만 여전히 가능한 모든 단점은 그렇지 않을 수 있습니다.
(내가 보는 것의 의도하지 않은 결과가
궁극적인 정치적 결정). 그것을 테스트하는 것이 좋을 수 있습니다.
또는 나쁜.

내가 본 것은 패닉/리커버가 나쁜 랩과 그것의 부당함을 가지고 있다는 것입니다
우리를 괴롭히기 위해 다시오고 있습니다. 다시 말하지만, 나는 아직 둘 중 하나를 사용하지 않았고 나는
나는 항아리에서 가장 날카로운 쿠키가 아니기 때문에 내가해야 할 날이 두려워
그리고 나는 그것이 매우 어렵다는 것을 알게 될 것이지만, 패닉/회복이 권장되었습니다
드문 경우에 적합한 경우(그들 중 누구도
롭 파이크(Rob Pike)가 오류를 반환하는 것에 대한 멋진 프레젠테이션을 했습니다.
값, 내가 올바르게 기억한다면), 그것은 모든 것에 훨씬 더 분명할 것입니다
Go는 이미 오류를 처리하고 필요 없이 예상할 수 있습니다.
가능한 옵션의 늪을 탐험하기 위해
경계.

즉, 테스트를 시도하는 것만큼이나 의미가 있습니다.
모두, 선택적 기능입니다. 그러나 한 가지 부작용은 이것이
교환은 "사실상"의 결과에 관한 것입니다.
"오류" 유형 인수를 갖는 강력한 오류 처리 함수
반환 매개변수 목록의 끝에? 그게 어떻게 바뀔까
"오류는 값일뿐"이라는 인식? 와 어떻게 맞물릴 것인가
이제 훨씬 더 유사한 "쉼표 확인" 패러다임? 이건 또 뭐지
새로운 원리를 일으키다?

무엇보다 이 두더지 언덕으로 만들어진 산은
바둑이 인생을 바꾸는 이정표에 도달했음을 나타냅니다. 거의
확실히, 2013년에 사실이었던 가정이 더 이상
잡고있다. 그것은 누구에게도 뉴스가 아니지만 Go2가
이전처럼 Go1과 역호환되는 것은 좋지 않습니다.
너무 단호하게 제안했습니다(내 의견으로는).

@loot 자세한 답변 감사합니다. 기존 언어를 이전 버전과 호환되는 방식으로 확장하는 것은 실제로 매우 어렵습니다. 따라서 이전 버전과의 호환성이 필요하지 않은 경우 다른 작업을 수행할 수 있다는 점에 동의합니다. 우리는 곧 (모듈이 일반화되면) 엄격한 역호환성을 요구하지 않는 언어 변경을 할 수 있을 것입니다.

당신이 말했듯이 try 는 선택적인 메커니즘이며 - 반복할 가치가 있다고 생각합니다 - 주변의 모든 난리에도 불구하고 기존 Go 기능을 사용하여 쉽게 설명할 수 있는 매우 간단한 메커니즘입니다. t Go에서 함수로 try 를 작성합니다(그리고 제네릭도 그 문제에 대해 도움이 되지 않습니다). 가능하다면 기존 코드에서 오류 처리를 위해 try 와 같은 도우미 함수를 보는 것이 매우 일반적일 것이라고 확신합니다. 오류가 값이라는 Rob Pike의 이야기는 결국 오류가 있는 프로그래밍입니다.

모든 사람이 자유롭게 무시할 수 있는 아주 작은 도우미 기능을 추가하는 것과 관련하여 난리가 났지만 사람들은 특정 스타일을 강력하게 제안하는 on error 와 같은 중요한 언어 변경을 심각하게 고려하고 있다는 것이 여전히 매우 놀랍습니다

귀하의 의견에 다시 한 번 감사드립니다. 이것은 모두 매우 흥미 롭습니다.

이 제안이 토론하기에 적합한 장소인지 확실하지 않지만 이 스레드에서 try 키워드에 대한 생생한 토론이 이미 있기 때문에 지금은 주제로 고려할 것입니다. :)

Google 직원이 내부 Golang 리포지토리에서 try 키워드를 기꺼이 구현하고 이후에 해당 키워드를 사용하도록 기존 Google 코드 기반을 변환할 의향이 있는지 궁금합니다. 내부 전용으로 유지함으로써 쉽게 되돌릴 수 있습니다(즉, 전체 커뮤니티가 아니라 단일 회사에 부담이 있음).

이를 통해 실제 high-sloc 코드 기반에서 이 기능에 대한 약간의 사례 연구를 수행할 수 있습니다. Facebook은 과거에 PHP 기능과 유사한 작업을 수행하여 커뮤니티에 제안하기 전에 특정 기능을 미세 조정할 수 있었습니다.

try 키워드가 _실제로 사용된 방식과 실제 생활에서 추가된 가치에 대한 사례 연구를 작성한다면 설득력 있는 사례를 제공할 수 있습니다. (가상적으로) 실제 가치를 제공하지 않는 경우에도 알아두는 것이 좋습니다. 때로는 문서상으로는 정말 좋아 보이지만 실제로는 잘 되지 않는 경우가 있습니다. 또는 그 반대의 경우도 마찬가지입니다.

@Freeaqingme 우리는 이미 표준 라이브러리에서 try 가 어떻게 보이는지 보여주는 임시 CL을 생성했습니다. https://go-review.googlesource.com/c/go/+/182717 (거짓이 있을 수 있습니다. 긍정적이지만 존재하는 경우 매우 드뭅니다). 우리는 코드 기반을 양방향으로 변환할 수 있는 도구를 개발하는 것을 고려하고 있습니다.

또한 코드 기반에서 tryhard 를 사용하고 다시 보고하는 것이 좋습니다.

감사 해요.

@griesemer 내가 명확하게 밝히지 않았을 수 있습니다. Google이 내부적으로 자체 Go 빌드를 사용한다고 가정합니다. 제 제안은 위에서 링크한 패치를 내부 Google 빌드에 적용한 다음 Google 코드 베이스(stdlib뿐만 아니라 특히 Go로 작성된 내부 프로젝트)를 변환하는 것입니다. Google 엔지니어가 실제 상황에서 두어 달 동안 사용한다면 실제로 어떻게 작동하는지에 대한 좋은 통찰력을 제공할 것입니다.

분명히 나 자신도 적용할 수 있고 내 자신의 코드 기반에서 사용할 수 있습니다. 하지만 저는 비교적 작은 코드 기반을 가진 단일 개발자일 뿐이므로 많은 Google 직원이 사용한다면 대표성이 없을 것입니다.

개인적으로 나는 여전히 이 기능에 대해 경계하고 있습니다. 한편으로는 매번 몇 번의 키 입력을 절약할 수 있다는 사실에 감사합니다. 그러나 때때로 나는 게으르며(결국 저는 인간입니다) 가능한 한 많은 try 문을 중첩할 수 있습니다. 이제 이 기능이 있는 경우 좀 더 훈련을 받을 것입니다. 그러나 내가 그랬다고 해도 내 코드 기반이 이 키워드로 고통받는 동안 외부 라이브러리가 이 키워드를 남용/남용할 가능성이 있습니다(디버깅 가능성, 해당 라이브러리의 확장성 측면에서).

@Freeaqingme 알겠습니다. 내부 저장소를 통해 try 를 실행할 수 있습니다. 변환하고 다시 변환할 수 있는지 확실하지 않습니다. 여기에는 상당한 비용이 듭니다. 또한 내부 세부 정보를 보고할 수 없기 때문에 이 실험에 대한 집계(통계)로만 보고할 수 있었습니다. 그것은 커뮤니티가 우리의 주장을 쉽게 확인할 수 있는 방법이 없다는 것입니다. 마지막으로 Google의 코드 기반이 대표성이 아닐 수 있습니다.

하지만 감사합니다.

@griesemer 비용이 많이 드는 노력에 감사드립니다. 그런 경우에는 하지 않을 것입니다. 단순히 노력한 프로젝트를 적용하는 문제라면 비용이 제한될 수 있습니다. 그러나 실제로 그것은 Google 직원(저는 아닙니다)이 결정할 문제입니다.

개별 Google 프로젝트 또는 내부 인프라에 대해 보고할 수 없다는 점을 이해합니다. 그러나 아마도 몇 가지 일화를 공유할 수 있습니다. 그러나 개인적으로 훨씬 더 가치 있다고 생각하는 것은 일부 Google 직원이 어떻게 작동했는지 보고하는 것입니다. 구체적으로 설명하지 않고 "X를 예상했지만 A 및 BI와 같은 사례에 부딪쳤을 때 Y가 Y임을 발견했습니다"와 같은 진술은 매우 가치가 있음을 알게 될 것입니다. 그런 종류의 보고서를 확인할 필요가 전혀 없습니다.

마지막으로 Google의 코드 기반이 대표성이 아닐 수 있습니다.

그럴 수도 있고 아닐 수도 있습니다. 그러나 Google에는 많은 사람들이 근무하고 있으므로 대부분의 코드 기반은 한 개인이 어떻게 작성하기로 결정했는지 기반이 아니라 다양한 기여자(직원)의 기여의 정점이라고 생각합니다. 그런 점에서 나는 사물이 얻을 수 있는 한 대표성이 있을 것으로 기대합니다. 아마도 100% 대표 코드 베이스와 같은 것은 없을 것입니다.

더 나은 솔루션을 찾을 때까지 그대로 두십시오. try 은(는) 우리가 찾던 것이 아닙니다. 이에 대해 편향된 조치를 취할 필요가 없습니다. 시간을 내어 Go Authors로 이동하세요. 저는 매일 전 세계의 고퍼들과 이야기하는 한 Go 커뮤니티의 대다수가 atm에서 try 제안을 받아들이지 않는다고 굳게 믿습니다.

새로운 구문을 도입한다는 것은 모두가 Go 버전을 업그레이드해야 한다는 것을 의미합니다. 내 워크플로가 go get 항목을 기반으로 한 다음 명령줄에서 사용할 수 있기 때문에 여전히 Go 1.10을 사용하고 있습니다(내 GOPATH 는 내 PATH ). . 최근에 모듈을 사용하는 다른 사람의 라이브러리를 go get 하려고 할 때 문제가 발생했습니다. .../v2 를 사용할 수 없다는 오류가 발생했습니다. 이것은 이미 코드에 분할이 있음을 의미합니다(Python 2와 3을 생각해 보세요). 나에게는 Go 1.11 이전과 Go 1.11 이후의 세계가 있습니다. 이것은 매우 성가신 일이며 Go에서 오류 처리뿐만 아니라 작동하는 것에 대한 새로운 구문을 도입하는 것은 전혀 좋은 절충안이 아닙니다. 더 많은 조각화를 도입합니다.

7/4/19에 gonutz [email protected] 은 다음과 같이 썼습니다.

새로운 구문을 도입한다는 것은 모두가 Go를 업그레이드해야 함을 의미합니다.
버전. 내 워크플로가 사실을 기반으로 하기 때문에 여전히 Go 1.10을 사용하고 있습니다.
go get 항목을 만든 다음 명령줄에서 사용할 수 있습니다(내
GOPATH 은(는) 내 PATH 있습니다. 최근에 go get 시도할 때 문제가 발생했습니다.
모듈을 사용하는 다른 사람의 라이브러리. .../v2 오류가 발생했습니다.
사용할 수 없습니다. 이것은 이미 코드에 분할이 있음을 의미합니다(
파이썬 2와 3). 나에게는 Go 1.11 이전과 Go 1.11 이후의 세계가 있습니다.
이것은 매우 성가시며 작동하는 새로운 구문을 도입합니다.
Go의 오류 처리는 좋은 절충점이 아닙니다. 그것
더 많은 조각화를 도입합니다.

조금이라도 위로가 된다면 난 정확히 같은 입장
모듈을 이동합니다. 친해질 시간과 기회를 찾지 못했다
그래서 저도 Go1.10을 고수하고 있습니다. 아마 그래야 할거야
가치가 있는 설문조사.

루시오.

--
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/golang/go/issues/32825#issuecomment -508372318

--
루시오 데 레
2 Piet Retief St
케스텔(동부 자유주)
9860 남아프리카 공화국

전화: +27 58 653 1433
휴대전화: +27 83 251 5824
팩스: +27 58 653 1435

저는 새로운 golang 개발자입니다(아직도 go에 대해 배우고 있습니다). 현재의 에러 핸들링은 에러를 쉽게 관리할 수 있어서 좋은 것 같아요. 안드로이드 개발자로서 try-catch 가 golang의 if err != nil{ } 보다 오류를 관리하기가 더 어렵다고 생각합니다. 그리고 명시적 오류 처리가 암시적 오류 처리보다 항상 낫다고 생각합니다.

추신. 내 언어에 대해 죄송합니다.

고장난게 아니다....

@Daniel1984 밈을

덧붙여서, try 제안은 if err != nil 둡니다. 의미가 있는 추가 옵션을 제공할 뿐입니다.

나는 try 가 포함되어서는 안된다고 생각합니다. try :

찬성

• 프로그래머는 키 입력 횟수를 줄입니다.
• 프로그래머는 매크로로 현재 기능에서 복귀하기 위한 약칭을 가질 수 있습니다.
• 필요하지 않습니다.
• 일반적으로 사용되었을 것입니다.
• Java의 throws 와 달리 마법이 일어나는 곳은 분명합니다.
• nil 수표의 바다를 볼 때 눈이 더 이상 빛나지 않습니다.
• 간단한 구현에서 가장 잘 작동합니다.

범죄자

• try 는 기존 작업에 대해 중복 메서드를 추가합니다.
• try 가 현재 함수에서 반환되는 것은 예상치 못한 일이며, 일명 더 많은 마법입니다.
• 오류 검사에 불일치가 추가됩니다.
• Go 경험이 없는 프로그래머는 이해할 수 없습니다.
• 오류 처리를 변경하지 않습니다.
• 덜 명확함(함수 반환과 표현식 값 사이의 불일치).
• try 에서 무슨 일이 일어나고 있는지 말로 설명하기조차 어렵습니다.

@griesemer 그게 바로 내가 좋아하지 않는 것입니다. 모든 것이 단순해야 합니다. 동일한 것을 달성하는 두 가지 방법을 사용하기 위해 언어에 복잡성을 추가하고 싶지 않습니다. 이 if err != nil 장황함을 피하기 위한 패턴이 있습니다. https://www.ardanlabs.com/blog/2019/07/an-open-letter-to-the-go-team-about-try.html

Go2 제안 #32437은 언어에 새로운 구문을 추가하여 if err != nil { return ... } 상용구를 덜 번거롭게 만듭니다.

다양한 대안 제안이 있습니다: #32804와 #32811은 원래의 것과 같이 보편적으로 사랑받지 못합니다.

혼합에 다른 대안을 던지려면: 그대로 유지하는 것이 어떻습니까?

나는 if err != nil 구조의 명시적 특성을 좋아하게 되었고, 그래서 우리가 이에 대한 새로운 구문이 필요한 이유를 이해하지 못합니다. 정말 그렇게 나쁜가요?

아주 많이 이것. 명시적 코드는 올바른 코드입니다. 내가 예외 핸들러에서 본 공포는 그 끔찍한 읽을 수 없는 구조에서 영원히 떠나기에 충분합니다.

사람들이 댓글만 달기 시작하면서 엄청난 지연이 있는 것 같습니다.
이제 신선하다는 인상을 받지 않을 수 없었습니다.
그들에게 뉴스.

그것도 고려해야 합니다. 포도나무는 분명히
생각보다 빠릅니다.

루시오.

그리고 간단한 핸드볼과 오류가 있는 단일 라인 if 문을 허용하도록 gofmt를 변경합니다.
호출 기능. 그것은 많은 혼란을 제거합니다.

대신에:

오류 = myFunction()
오류 != nil {인 경우
반환 오류
}

허용하다:

오류 = myFunction()
if err != nil { return err}

덧붙여서, try 제안은 if err != nil만 남습니다. 의미가 있는 추가 옵션을 제공할 뿐입니다.

이 정확한 정당화는 Go가 또 다른 C++, C#, Scala, Kotlin 등이 되는 방법입니다. "원하지 않으면 사용할 필요가 없습니다"는 기능이 부풀려진 언어가 만들어지는 방법입니다.

편집 - 이것은 잘못된 방법으로 올 수 있습니다. 나는 try 가 Go를 기능이 부풀려진 언어로 바꿀 것이라고 말하는 것이 아닙니다. 나는 여기서 정당화에 약간의 결함이 있다는 것을 말하고 있다

@deanveloper "try"로 이해하기 어려운 오류 동작에 대한 명확한 예가 있습니다.
https://github.com/golang/go/issues/32437#issuecomment -498932961

조금 반복적이긴 해도 OP에 동의합니다.
또한 제안된 모든 대안은 쓸모없는 복잡성을 도입합니다.

범위 안에 한 줄만 있는 경우 중괄호를 생략하는 것이 좋습니다.

@gonuts

이것은 이미 코드에 분할이 있음을 의미합니다(Python 2와 3을 생각해 보세요). 나에게는 Go 1.11 이전과 Go 1.11 이후의 세계가 있습니다.

저는 오랜 시간 Python 프로그래머이며 Go 모듈에 대해 언급한 "분할"은 Python 2에서 Python 3으로 마이그레이션하는 재앙에 비하면 아무 것도 아닙니다.

이것은 매우 성가신 일이며 Go에서 오류 처리뿐만 아니라 작동하는 것에 대한 새로운 구문을 도입하는 것은 전혀 좋은 절충안이 아닙니다. 더 많은 조각화를 도입합니다.

try 는 제안서에 내장된 기능입니다. 완전히 하위 호환됩니다. 코드가 이미 try 를 식별자로 사용하는 경우 식별자는 try 내장을 섀도우합니다.

@pongsatornw

현재의 에러 핸들링은 에러를 쉽게 관리할 수 있어서 좋은 것 같아요. 안드로이드 개발자로서 golang의 if err != nil{ }보다 try-catch가 오류를 관리하는 것이 더 어렵다고 생각합니다. 그리고 명시적 오류 처리가 암시적 오류 처리보다 항상 낫다고 생각합니다.

제안서 를 완전히 읽으셨습니까? try 는 if err != nil { return ..., err } 의 반복 을 제거하는 데 도움이 되는 내장 함수일 뿐입니다. Go에서 오류 처리의 일반적인 논리는 동일하게 유지됩니다. 여전히 명시적이며 오류는 여전히 값이며 try-catch(예외라고도 함)가 없습니다.

@kroppt

• try 는 기존 작업에 대해 중복 메서드를 추가합니다.

try 는 반복적인 코드를 인수분해합니다. append 와 동일합니다. 슬라이스에 요소를 추가할 때마다 직접 작성할 수 있지만 append 를 호출하는 것이 더 쉽습니다.

• 오류 검사에 불일치가 추가됩니다.

[...:...] 사용하여 "수동으로" 슬라이스를 조작하거나 수행하는 작업에 따라 append 사용할 수 있습니다. 불일치가 없습니다. 그것들은 다른 작업을 위한 다른 도구일 뿐입니다. 당면한 작업에 따라 일반 if err != nil { ... } 또는 try 오류와 동일합니다.

• try 가 현재 함수에서 반환되는 것은 예상치 못한 일이며, 일명 더 많은 마법입니다.

새롭기 때문에 의외입니다. 우리는 사용할수록 익숙해집니다. 그리고 나는 그것이 마술이라고 생각하지 않습니다. 시도의 사양은 매우 간단합니다.

• Go 경험이 없는 프로그래머는 이해할 수 없습니다.
• try 에서 무슨 일이 일어나고 있는지 말로 설명하기조차 어렵습니다.

바둑 경험이 없는 프로그래머는 chan , defer , 'go , iota , panic , recover , 이해하지 못할 것입니다 , , <- , type assertions, and many other things either without reading the documentation. try`는 이것에 비해 쉽습니다.

• 오류 처리를 변경하지 않습니다.

if err != nil 를 그대로 두도록 요청하는 gophers에 따르면 아마도 좋은 일입니다 ;-)

@marcopeerboom

명시적 코드는 올바른 코드입니다. 내가 예외 핸들러에서 본 공포는 그 끔찍한 읽을 수 없는 구조에서 영원히 떠나기에 충분합니다.

try 는 예외 처리와 전혀 관련이 없습니다. 전체 제안을 읽으셨습니까? 예를 들어 Java 또는 Python에서와 같이 예외 처리와 비교할 수 있는 것은 없습니다. try 는 명시적입니다. 함수 서명에 오류가 언급되어야 합니다. 오류는 호출 사이트에서 처리해야 합니다. 스택 해제가 없습니다. 등.

@gale93

범위 안에 한 줄만 있는 경우 중괄호를 생략하는 것이 좋습니다.

대부분의 고퍼가 같은 생각을 했을 거라 생각하고 이슈 트래커에서 비슷한 제안을 여러 번 읽었습니다. 하지만 try 보다 훨씬 더 큰 변화입니다. if 문에 대해서만 이 작업을 수행하는 것은 합리적이지 않습니다. 따라서 블록이 허용되는 모든 곳에서 이를 변경해야 합니다. 블록의 시작을 표시하는 { 없으면 조건식의 끝을 구분하는 방법을 지정해야 합니다. 문법, 파서, gofmt 등을 업데이트해야 합니다. 그러면 언어 표면이 완전히 변경됩니다.

@ngrilly
중재와 언어를 단순하게 유지하는 것이 중요합니다.

당신이 사용한 주장 중 일부는 사양에 대한 많은 변경을 정당화할 수 있습니다. 여기에 긍정적인 점만 있는 것은 아닙니다.

나는 그 결정이 도움이 될지, 상처가 될지를 기준으로 평가하는 것이지, 반드시 어떤 철학을 완전히 시행할 필요는 없다. 사양의 일부 항목이 go 이 된 특정 원칙을 위반한 것이 맞습니다. 그러나 이는 모두 조정에 관한 것입니다. 이 변화는 부정적인 영향을 견딜 만큼 나에게 긍정적인 영향을 미치지 않습니다.

안녕하세요 @kroppt 입니다 .

언어를 단순하게 유지하는 것이 중요합니다

나는 동의하고 우리 모두가 이것을 위해 노력한다고 생각합니다.

나는 그 결정이 도움이 될지, 상처가 될지를 기준으로 평가하는 것이지, 반드시 어떤 철학을 완전히 시행할 필요는 없다.

우리 모두는 이점과 비용을 기준으로 try 를 평가하고 있다고 생각합니다. 논의는 이러한 혜택과 비용에 대한 사실에 기반한 합의를 정의하고 찾는 것에 관한 것입니다.

사양의 일부 항목이 go가 설립된 특정 원칙을 위반하는 것이 맞습니다.

지난 몇 년 동안 나는 Go 팀이 Go와 그 디자인에 대해 출판한 거의 모든 것을 읽었지만 In은 ​​당신이 의미하는 바를 이해하지 못합니다. try 제안이 바둑의 기본 원칙을 위반한다고 생각하지 않습니다.

@ngrilly
https://talks.golang.org/2012/splash.article 은 go 차별화하는 몇 가지 개념, 즉 명확성과 단순성을 설명합니다. 나는 이것이 우리 중 일부가 이 새로운 변화에서 보게 되는 갈등이라고 생각합니다. 더 간단하지만 덜 명확합니다. 내게는 단순함의 이득이 명료함의 상실보다 작은 것 같다. 제가 틀렸을 수도 있고 조심스럽습니다.

@kroppt 이 기사를 수십 번 읽었습니다 ;-) try가 코드를 난독화한다는 생각에 동의하지 않습니다. try는 일부 반복적인 코드를 인수분해하는 데 사용되는 내장 함수일 뿐입니다. 우리는 프로그래머로서 항상 그렇게 합니다. 반복적인 패턴을 식별하면 새로운 기능에서 이를 제거합니다. 그렇지 않으면 모든 코드가 인라인된 하나의 긴 main() 함수를 갖게 됩니다.

@ngrilly
당신이 설명하는 것은 내 "프로"섹션에 있습니다.

• 프로그래머는 키 입력 횟수를 줄입니다.
• 프로그래머는 매크로로 현재 기능에서 복귀하기 위한 약칭을 가질 수 있습니다.
• nil 수표의 바다를 볼 때 눈이 더 이상 빛나지 않습니다.

다시 말하지만, 나는 우리가 여기에 보편적으로 적용하지 않을 때 원리의 보편적 적용을 언급하는 요점을 보지 못합니다.

나는 시도가 코드를 난독화한다는 생각에 동의하지 않습니다.

변경 사항은 코드를 난독화/숨기기/단순화/표시하는 것입니다. 그렇지 않으면 원래 오류 검사 블록이 표시됩니다. 문제는 그것이 의미를 덜 명확하게 만드는지 여부입니다.

go 원래 명료함을 훼손하기 보다는 기여하는 지점까지 단순함의 훌륭한 균형을 유지했다고 생각합니다. 나는 그들이 그것을 어떻게했는지 설명 할 수 없지만 내 생각에 try 는 그렇지 않습니다.

나는 우리가 장황한 문제를 고려해야한다고 생각하지 않습니다. 코드는 컴퓨터보다 시간이 더 많이 드는 인간이 읽고 이해할 수 있어야 하며 _이해_는 어렵고 시간이 많이 걸리는 부분입니다.

go 오류 처리의 들여쓰기 구조가 무슨 일이 일어나고 있는지 이해하는 데 도움이 됩니다. 모든 오류 검사는 명시적입니다. 대부분의 처리되지 않은 오류도 명시적입니다. 이것은 나를 위해 코드를 이해하기 쉽게 만듭니다.

또한 if err != nil 수표가 지루해 보일 수 있지만 실제로 _입력_할 필요는 없다고 생각합니다. 편집자에게만 하면 됩니다.

@kroppt

변경 사항은 코드를 난독화/숨기기/단순화/표시하는 것입니다. 그렇지 않으면 원래 오류 검사 블록이 표시됩니다.

그러나 모든 함수 호출에 이 인수를 사용할 수 있습니다! strings.HasPrefix("foobar", "foo") 호출하면 코드가 난독화됩니까? l := len("foo"); len("foobar") >= l && s[0:l] == "foo" 쓰기와 읽기를 선호하십니까?

@rossmcf

모든 오류 검사는 명시적입니다.

try는 여전히 명시적으로 오류를 확인하고 있습니다. 그것이 시도의 이유입니다.

또한 err != nil 검사가 지루해 보일 수 있지만 실제로 입력할 필요는 없다고 생각합니다.

타이핑하는 것은 지루하지 않습니다. 도처에 동일한 3줄이 있을 때 읽기가 지루합니다. 그것은 반복이며 프로그래머인 우리는 일반적으로 이것을 고려하지 않는 경향이 있습니다. try 에는 다른 단점이 있을 수 있지만 제 생각에는 이 단점이 아닙니다.

try는 여전히 명시적으로 오류를 확인하고 있습니다.
try 추상화와 strings.HasPrefix의 차이점은 try 암시적으로 반환된다는 것입니다.
go 코드를 읽을 때 실행 흐름이 다음을 수행할 때까지 내 함수 내에서 유지된다는 것을 알고 있습니다.

• 반환 유형이 없는 함수의 닫는 대괄호 읽기
• return , panic 키워드 읽기
• syscall.Exit(code) 읽기
  try 하면 같은 방식으로 코드를 읽을 수 없습니다. 줄을 시각적으로 스캔하고 "반환" 문이 0인 경우 더 이상 "이 줄이 모두 실행되거나 한 블록이 실행되지 않거나 프로그램이 종료됨"을 의미하지 않습니다.

@ngrilly 참고로 한 게시물에 2명 이상에게 답글을 if err != nil 입력을 방지하는 단일 이점을 보았습니다. 이것은 리소스 를 누출하는 새로운 방법, 덜 간결한 코드를 작성하는 능력, 그리고 최악 의 경우 try 중첩을 허용 하는 기능을 도입하는 대가를 치러야

나는 제안자들이 만든 사양과 주장이 오해의 소지가 있다고 생각합니다. 현재 최악의 사례는 보여주지 않고 최고의 사례만 제공하고 있습니다. 위의 부정적인 단점이나 잠재적인 완화 요소를 평가하거나 언급하지 않습니다. 제안 및 시연된 사용으로 시도의 구현을 제한하지 않는 이유를 정당화하지 않습니다. tryhard 도구는 어떤 사람들에게 주관적으로 더 나은 미학을 제공하는 보다 간결한 코드를 표시하는 데 사용됩니다. trytoohard 도구가 수행할 수 있는 모든 기능(예: 깊게 중첩된 시도)을 보여 주는 도구 없이 진술. 마지막으로 이름 자체는 프로그래밍 세계에서 예외가 있는 유비쿼터스에 연결되어 있으며 중첩 가능하고 오류와 관련되도록 허용하고 관련 없는 복구 및 패닉에 내장으로 인접하게 배치하여 단순히 제자리를 찾지 못하게 합니다. 나는 Go 작성자가 더 나은 것을 생각해 낼 수 있는 능력을 믿고 신뢰합니다.

여기에는 단일 가치 추가로 정당화하기에는 너무 많은 비용이 있습니다. 지지자들은 "더 이상 if err != nil 를 입력할 필요가 없습니다." 전체 Go 커뮤니티의 가치입니다. if err != nil 사용하여 작성된 코드가 10년 가까이 되었습니다. 동시에 가장 주목할만한 기술 발전(docker, k8s, ...) 중 일부가 모두 큰 성공을 거두었습니다.

if err != nil 닫는 것은 내장으로 숨기는 부담이 아니지만 우리 모두가 언어 성공의 핵심 요소로 인식해야 하는 것입니다. 집단적으로 부담으로 받아들인다 해도 그것을 제거하는 기준은 높고 타협이 없어야 합니다. 지금 시도의 너무 많은 측면이 타협입니다.

어떤 방법이 더 쉽다는 의견도 있지만 의견도 있습니다. 주어진 try는 간단하고 현재의 명시적 검사는 간단합니다. 두 가지 방법 모두 간단합니다. 나에게 문제는 주어진 코드의 독자와 작성자 모두의 인지 부하를 증가시킨다는 것입니다. 이제 둘 다 일을 수행하는 여러 가지 방법을 해석해야 합니다. 그리고 작가는 작업을 수행하는 방법 및/또는 작업 중인 패키지 또는 프로젝트의 나머지 부분과 다른 방식으로 작업을 수행할 위험을 선택해야 합니다. 시도가 명시적 검사를 대체하는 경우 파싱할 또 다른 것으로 암시적 반환으로 인해 인지 부하가 ​​여전히 증가합니다.

_이 모든 것을 잠시 제쳐두고 오류를 처리하는 똑같이 간단한 두 가지 방법이 있다고 생각하면 여전히 문제가 있습니다._ 단순함 은 더 이상 쉽지 않습니다 . 그리고 모든 일에 대한 문을 열어주는 것은 피하도록 설계되었습니다.

이와 같은 것을 추가하는 기준은 훨씬 더 높아야 하며, 현장의 데이터가 더 좋다는 것을 증명하기 위해 오랜 기간 동안 실험적이어야 합니다.

@cstockton

참고로 한 게시물에 한 명 이상의 사람에게 답장을 보낼 수 있습니다. 몇 시간에 10개, 한 지점에서 5개 연속으로 답글을 달면 토론을 따라가기가 어렵습니다.

Ian 은 7일 전에 이 토론을 golang-nuts로 옮기는 것이 바로 이러한 이유로 제안했습니다(특정 의견에 답장할 방법 없음, 스레딩 없음). 토론이 "공식적"이도록 하기 위해 기각된 제안입니다. 우리가 요청한 것이 있습니다.

@therealplato

try 추상화와 strings.HasPrefix의 차이점은 try가 암시적으로 반환한다는 것입니다.

그건 사실이야. 함수를 읽고 "종료" 지점을 찾을 때 반환, 패닉, log.Panic, os.Exit, log.Fatal 등을 찾고 시도해야 합니다. 그런 문제가 있습니까? 함수의 종료점 수는 동일하게 유지되며 시도 여부에 관계없이 명시적으로 표시됩니다.

키워드 return, 패닉 읽기

패닉은 키워드가 아닙니다. 내장 함수입니다. 우리 중 누구보다 언어 디자인에 더 능숙한 바둑 팀의 제안을 비판하려면 적어도 제대로 정의하는 쪽은 그들에게 호의를 베풀어야 합니다. 😉

함수를 읽고 "종료" 지점을 찾을 때 반환, 패닉, log.Panic, os.Exit, log.Fatal 등을 찾고 시도해야 합니다. 그런 문제가 있습니까?

try 표현식이 나타날 수 있는 모든 위치에 문자 그대로 나타날 수 있기 때문에 문제입니다. Go의 모든 단일 종료점은 _only_ 단일 명령문으로 발생할 수 있습니다. try 는 표현식으로 나타날 수 있는 유일한 것입니다.

@ngrilly

Ian은 7일 전에 이 토론을 golang-nuts로 옮기는 것이 바로 이러한 이유로 제안했습니다(특정 의견에 답할 방법 없음, 스레딩 없음). 토론이 "공식"이 되도록 하기 위해 기각된 제안입니다. 우리가 요청한 것이 있습니다.

시작 메시지

@ user1
답장 1

@ user2
답장 2

종료 메시지

이것이 의미하는 바였습니다.

@cstockton

if err != nil 입력을 방지하는 단일 이점을 보았습니다.

try 는 if err != nil 뿐만 아니라 if err != nil { return ..., err } (3줄 형식) 의 반복적인 타이핑 과 읽기를 방지합니다.

이것은 리소스를 누출하는 새로운 방법, 덜 간결한 코드를 작성할 수 있는 능력, 그리고 최악의 경우 try 중첩을 허용하는 기능을 도입하는 대가를 치르게 됩니다.

언급한 리소스 누출 위험은 vet 및 lint 로 방지할 수 있습니다.

"덜 간결한 코드"에 대해 try 요점은 더 간결한 코드를 작성하는 것이므로 귀하의 주장을 이해하지 못합니다.

과도한 함수 호출 중첩의 위험은 try 에만 국한되지 않습니다. 모든 함수 호출은 지나치게 중첩될 수 있습니다. 항상 그렇듯이 코드 리뷰와 린트가 도움이 될 것입니다.

나는 제안자들이 만든 사양과 주장이 오해의 소지가 있다고 생각합니다. 현재 최악의 사례는 보여주지 않고 최고의 사례만 제공하고 있습니다.

아마도 이 감정은 상호 작용할 것입니다. 우리는 모두 사랑스러운 고퍼입니다. 가치판단에 빠지지 말자 ;-)

지지자들의 답변에서 역류하는 것을 보았습니다. "더 이상 err != nil을 입력할 필요가 없습니다."

다시 말하지만 더 이상 l := len("foo"); len("foobar") >= l && s[0:l] == "foo" 를 입력할 필요가 없습니다.
대신 strings.HasPrefix("foobar", "foo") 를 사용할 수 있습니다.
try 와 어떻게 다른가요?
이전에 check 라는 "제한된" try 을 수락하고 중첩을 금지한다는 내용을 읽었습니다.

if err != nil - 가장 주목할만한 기술 발전(docker, k8s, ...) 중 일부가 동시에 큰 성공을 거둔 코드를 사용하여 작성된 코드가 10년에 이르렀습니다.

우리는 또한 C, C++, Java 등으로 작성된 훌륭한 코드를 많이 가지고 있습니다. 이러한 추론으로는 Go가 없을 것입니다.

Go에서 오류 처리에 대한 토론을 읽을 때 try 제안에 대해 모든 사람이 같은 페이지에 있다고 생각하지 않았기 때문에 try 가 어떻게 할 수 있는지 보여주는 블로그 게시물을 작성하기로 했습니다. 사용: https://faiface.github.io/post/how-to-use-try/

Reddit 관련 토론: https://www.reddit.com/r/golang/comments/c9eo3g/how_to_use_try_faiface_blog/

이 문제가 try 에 대한 문제라는 것을 알고 있지만 내 게시물이 새로운 관점을 제시할 수 있기를 바랍니다. :)

Go는 단순하다는 생각에 대해 마술적이 거나 논리적인 것 사이에서 막혀 고군분투하고 있습니다.

장점:

• 상용구 줄이기
• 단순한
• 다른 언어 중 기존 패턴
• 선택 과목

단점:

• 학습 곡선
• 기본 마법
• 새로운 종류의 버그
• Go는 if != nil 로 독단적이며 실용적 이지만 try 사용할 수 있습니다.

나는이 커뮤니티 esp처럼 느낍니다. 여기에서 Go Survey ^[1] 에서 투표한 사람들과 다릅니다.
유권자들은 이것을 주요 관심사로 선택하지 않고 향후 고려 사항을 위해 남겨둘 수 있습니다.
하지만 배치로 인해 영향을 미친 것으로 여겨졌다.

IMO, 언어 기능 추가는 오래되었고 현대 프로그래밍 방식은 Emmet 또는 언어 스니펫, 코드 접기 및 색상 지정, 리팩토링 및 형식 지정, 디버깅 및 테스트, 오류에 대한 솔루션 제안 및 godoc 또는 스택 오버플로 인용과 같은 편집기에 더 많은 기능을 추가하는 것입니다. , 소스 코드 위에 UI를 표시하고 소스 코드를 장황하게 둡니다.
^{_{코드 if err != nil 를 try 로 접습니다.}}

@ngrilly

try 는 if err != nil 뿐만 아니라 if err != nil { return ..., err }(3줄로 형식화됨)의 반복적인 타이핑과 읽기를 방지합니다.

"그것은 당신이 err != nil이라면 타이핑하는 것을 방지합니다"라는 말은 내가 우리가 입력하는 코드도 읽는다는 것을 완전히 잊었다는 것을 의미한다고 믿습니까?

당신이 언급한 자원 누출의 위험은 수의사와 보푸라기로 예방할 수 있습니다.

나는 왜 수의사와 보푸라기가 합리적인 선택이 아니라고 생각하는지 토론을 연결했습니다.

"덜 간결한 코드"에 대해 시도의 요점은 더 간결한 코드를 작성하는 것이므로 귀하의 주장을 이해하지 못합니다.

예, " 덜 간결한 코드 를

과도한 함수 호출 중첩의 위험은 시도에만 국한되지 않습니다. 모든 함수 호출은 지나치게 중첩될 수 있습니다. 항상 그렇듯이 코드 리뷰와 린트가 도움이 될 것입니다.

흥미롭게도 이것을 실제로 분해해 보겠습니다.

1) 과도한 함수 호출 중첩의 위험은 시도에만 국한되지 않습니다.

예, 여기 있는 모든 사람들은 기능이 어떻게 작동하는지 이해합니다.

2) 모든 함수 호출은 지나치게 중첩될 수 있습니다.

예, 여기 있는 모든 사람들은 기능이 어떻게 작동하는지 이해합니다.

3) 항상 그렇듯이 코드 리뷰와 린팅이 도움이 될 것입니다.

예, 당신은 이미 lint 인수를 만들었고 "코드 리뷰 인수"는 내가 당신에게 링크한 게시물에서 만들어진 또 다른 외부 언어 제어입니다.

아마도 이 감정은 상호 작용할 것입니다. 우리는 모두 사랑스러운 고퍼입니다. 가치판단에 빠지지 말자 ;-)

이해가 안 돼요? 제안서에는 구현이 제공하는 전체 기능의 예가 없으며 의도된 용도만 있습니다. 제안의 영향을 측정하는 데 사용되는 tryhard 도구는 가장 제한적이고 합리적인 형식으로 try 를 사용합니다. 이것은 단순한 사실입니다.

다시 말하지만 더 이상 l := len("foo"); len("foobar") >= l && s[0:l] == "foo".
대신 string.HasPrefix("foobar", "foo")를 사용할 수 있습니다.
시도와 어떻게 다른가요?

나는 각각의 반대 견해에서 입장을 추출하기 위해 최선을 다합니다. 그렇지 않으면 그것을 해체하기 위한 논거를 형성할 수 없습니다. 정말 여기에서 볼 수 없습니다, 죄송합니다. 나는 이것을 내가 이해할 수 있는 유일한 방법으로 해석할 것입니다. 문자 그대로.

try 와 ( strings.HasPrefix ) 어떻게 다른가요?

string.HasPrefix

함수 HasPrefix

func HasPrefix(s, 접두사 문자열) bool

HasPrefix는 문자열 s가 접두사로 시작하는지 테스트합니다.

노력하다

func try 는 try with signature(의사 코드)라는 새로운 기능과 유사한 내장입니다.

func try(expr) (T1, T2, … Tn)

여기서 expr은 T1, T2, ... Tn 유형의 n+1 결과 값과 마지막 값에 대한 오류를 생성하는 들어오는 인수 표현식(일반적으로 함수 호출)을 나타냅니다. expr이 단일 값으로 평가되면(n은 0) 해당 값은 오류 유형이어야 하며 try는 결과를 반환하지 않습니다. 오류 유형의 마지막 값을 생성하지 않는 표현식으로 try를 호출하면 컴파일 시간 오류가 발생합니다.

try 내장 기능은 마지막 결과가 오류 유형인 경우 하나 이상의 결과 매개변수가 있는 함수 내에서만 사용할 수 있습니다. 다른 컨텍스트에서 try를 호출하면 컴파일 시간 오류가 발생합니다.

(의사 코드)에서와 같이 f() 함수 호출로 try 호출

x1, x2, … xn = try(f())

turns into the following (in-lined) code:

t1, … tn, te := f()  // t1, … tn, te are local (invisible) temporaries
if te != nil {
        err = te     // assign te to the error result parameter
        return       // return from enclosing function
}
x1, … xn = t1, … tn  // assignment only if there was no error

즉, "expr"에 의해 생성된 오류 유형의 마지막 값이 nil인 경우 try는 마지막 nil 오류가 제거된 처음 n개의 값을 반환합니다. "expr"에 의해 생성된 마지막 값이 nil이 아닌 경우, 바깥쪽 함수의 오류 결과 변수(위의 의사 코드에서는 err라고 하지만 다른 이름을 가질 수 있거나 이름이 지정되지 않을 수 있음)는 nil이 아닌 오류 값으로 설정되고 둘러싸는 함수가 반환됩니다. 둘러싸는 함수가 다른 명명된 결과 매개변수를 선언하면 해당 결과 매개변수는 어떤 값이든 유지합니다. 함수가 다른 이름 없는 결과 매개변수를 선언하면 해당하는 0 값을 가정합니다(이미 가지고 있는 값을 유지하는 것과 동일).

이 그림과 같이 다중 할당에서 try가 사용되고 nil이 아닌 오류가 감지되면 할당(사용자 정의 변수에 대한)이 실행되지 않고 왼쪽에 있는 변수가 없습니다. 할당이 변경됩니다. 즉, try는 함수 호출처럼 작동합니다. 결과는 try가 실제 호출 사이트로 반환되는 경우에만 사용할 수 있습니다(둘러싸는 함수에서 반환하는 것과 반대). 결과적으로 왼쪽에 있는 변수의 이름이 결과 매개변수인 경우 try를 사용하면 오늘날 볼 수 있는 일반적인 코드와 다른 결과가 나타납니다. 예를 들어, a, b 및 err이 모두 둘러싸는 함수의 명명된 결과 매개변수인 경우 이 코드는

a, b, err = f()
if err != nil {
        return
}

f()가 오류를 반환했는지 여부에 관계없이 항상, b 및 err을 설정합니다. 대조적으로

a, b = try(f())

오류의 경우 및 b는 변경되지 않은 상태로 둡니다. 이것은 미묘한 차이지만, 우리는 이와 같은 경우가 드물다고 믿습니다. 현재 동작이 예상되는 경우 if 문을 유지합니다.

try 설명에 있는 전체 텍스트가 string.HasPrefix에 존재하지 않는다는 점에서 다릅니다. 더 나은 질문은 유사성이 어떻게 되는지입니다. 두 사람 모두 통화의 일부 측면을 공유하고 다른 것은 공유하지 않는다고 답하겠습니다.

나는 당신이 검사라는 이름이 붙고 중첩을 금지하는 "제한된" 시도를 수락할 것이라고 이전에 읽었습니다.

try에 대한 제 핵심 주장을 읽어주셔서 기쁩니다. 구현이 충분히 제한적이지 않습니다. 구현이 간결하고 읽기 쉬운 모든 제안 사용 예와 일치해야 한다고 생각합니다.

__또는_ 제안서에는 구현과 일치하는 예제가 포함되어야 하므로 이를 고려하는 모든 사람들이 Go 코드에 불가피하게 표시되는 내용에 노출될 수 있습니다. 모든 언어/환경에서 발생하는 이상적으로 작성되지 않은 소프트웨어 문제를 해결할 때 직면할 수 있는 모든 코너 케이스와 함께. 여러 중첩 수준에서 스택 추적이 어떻게 보일지와 같은 질문에 답해야 합니다. 오류 위치를 쉽게 인식할 수 있습니까? 메서드 값, 익명 함수 리터럴은 어떻습니까? fn() 호출이 포함된 줄이 실패하면 아래에서 생성하는 스택 추적 유형은 무엇입니까?

fn := func(n int) (int, error) { ... }
return try(func() (int, error) { 
    mu.Lock()
    defer mu.Unlock()
    return try(try(fn(111111)) + try(fn(101010)) + try(func() (int, error) {
       // yea...
    })(2))
}(try(fn(1)))

나는 합리적인 코드가 많이 작성될 것이라는 것을 잘 알고 있지만, 지금 우리는 이전에 존재하지 않았던 도구를 제공하고 있습니다. 바로 명확한 제어 흐름 없이 잠재적으로 코드를 작성할 수 있는 기능입니다. 그래서 저는 우리가 처음에 그것을 허용하는 이유를 정당화하고 싶습니다. 저는 이런 종류의 코드를 디버깅하는 데 시간을 낭비하고 싶지 않습니다. 내가 할 것이라는 것을 알기 때문에 경험을 통해 누군가가 허용하면 그렇게 할 것이라고 배웠습니다. 누군가는 종종 나에게 정보가 없습니다.

Go는 우리가 동일한 평범한 구성을 사용하도록 제한함으로써 다른 개발자와 내가 서로 시간을 낭비할 수 있는 최소한의 방법을 제공합니다. 압도적인 혜택 없이 그것을 잃고 싶지 않습니다. 나는 "try가 함수로 구현되기 때문에" 압도적인 이점이 있다고 생각하지 않습니다. 그 이유를 알려주실 수 있나요?

이 오류 처리 문제에 시간을 낭비하지 마십시오. 제네릭을 제공하면 Rust의 결과와 같은 것을 생성할 것입니다.

Go는 단순하다는 생각에 대해 마술적이 거나 논리적인 것 사이에서 막혀 고군분투하고 있습니다.

장점:

• 상용구 줄이기
• 단순한
• 다른 언어 중 기존 패턴
• 선택 과목

단점:

• 학습 곡선
• 기본 마법
• 새로운 종류의 버그
• Go는 if != nil 로 독단적이며 실용적 이지만 try 사용할 수 있습니다.

나는이 커뮤니티 esp처럼 느낍니다. 여기에서 Go Survey [1] 에서 투표한 사람들과 다릅니다.
유권자들은 이것을 주요 관심사로 선택하지 않고 향후 고려 사항을 위해 남겨둘 수 있습니다.
하지만 배치로 인해 영향을 미친 것으로 여겨졌다.

IMO, 언어 기능 추가는 오래되었고 현대 프로그래밍 방식은 Emmet 또는 언어 스니펫, 코드 접기 및 색상 지정, 리팩토링 및 형식 지정, 디버깅 및 테스트, 오류에 대한 솔루션 제안 및 godoc 또는 스택 오버플로 인용과 같은 편집기에 더 많은 기능을 추가하는 것입니다. , 소스 코드 위에 UI를 표시하고 소스 코드를 장황하게 둡니다.
코드 if err != nil 를 try 로 접습니다.

나는 오류 처리를 잊지 않고 더 엄격한 오류 처리에 투표한 사람이었습니다. 시도용이 아닙니다.

Rust의 Result 유형과 같은 것을 원격으로 리메이크하려면 제네릭보다 훨씬 더 많은 것이 필요할 것입니다. Result 유형이 제네릭으로만 만들어질 수 있는 경우에도 _if_ 초보자 프로그래머는 오류를 제대로 처리하거나 " Result 방식으로" 함수에서 오류를 반환하기 전에 제네릭을 알아야 합니다. "

@deanveloper , 제 요점은 "구문 변경"보다 제네릭의 이점이 훨씬 더 많으며 커뮤니티에서도 마찬가지라고 생각합니다.

@txgruppi 제네릭이 더 높은 우선 순위를 가져야 한다는 데 동의할 수 있습니다. 제네릭이 오류 처리를 대체할 수 있는 좋은 대안이 될 수 없다고 생각합니다.

@deanveloper , 제 생각에는 이 오류 처리 문제는 외관상 문제일 뿐입니다. 사람들은 몇 가지 추가 코드를 입력해야 하기 때문에 안정적이고 잘 작동하는지 논의하는 데 시간을 보내고 있습니다. 더 나은 코드를 작성하는 방법을 배우고 디자인 변경으로 이 문제를 해결하십시오.
누군가가 Generics가 더 나은 코드로 수정하기 쉽다고 말하기 전에: 컴파일 시간 오류...

스니펫이나 키보드 매크로로 해결할 수 있습니까? 그러면 문제가 되지 않습니다.

@txgruppi

더 나은 코드를 작성하는 방법을 배우고 디자인 변경으로 이 문제를 해결하십시오.

Robert Griesemer가 tryhard 도구를 사용하여 알게 된 것처럼 표준 라이브러리의 모든 오류 처리 코드 중 70%가 현재 try 적합합니다. (아직 존재하지 않는) fmt.HandleErrorf 기능을 사용하는 것과 같이 코드를 변경하면 더 많은 것이 적합합니다. 표준 라이브러리를 나쁜 코드라고 부르고 싶지 않기를 바랍니다.

스니펫이나 키보드 매크로로 해결할 수 있습니까? 그러면 문제가 되지 않습니다.

그것은 또한 코드를 읽는 것에 관한 것입니다. 그래서 우리는 thing.Thing thing = new thing.Thing(thing.THING); 좋아하지 않습니다.

@faiface , 'if err != nil'이 양질의 소프트웨어를 개발하는 데 방해가 되나요? 나는 그렇게 생각하지 않는다.
Generics의 부족이 양질의 소프트웨어를 개발하는 데 방해가 됩니까? 예, 그렇습니다.

내가 보기에는 제네릭을 구현할 지식이 충분하지 않아 구현할 사람이 필요하지만 이 오류 처리 작업은 제네릭을 현실로 만들 수 있는 사람들에게 시간 낭비일 뿐입니다. 나는 이 오류 처리가 나쁘기 때문에 반대하는 것이 아니라 해결해야 할 더 중요한 것이 있기 때문에 반대합니다.

@faiface 표준 라이브러리는 실제 Go 코드를 잘 표현하지 못합니다. 이는 표준 라이브러리가 컨텍스트를 추가하지 않고 단순히 오류를 전달할 가능성이 훨씬 더 높기 때문입니다. 예를 들어 io/ioutil 는 실제로 오류를 장식할 필요가 없으며 io 에서 발생한 오류를 단순히 전달할 수 있습니다.

@deanveloper @faiface Go Corpus 에 대해 실행할 때 :

--- stats ---
 401679 (100.0% of  401679) func declarations
  97496 ( 24.3% of  401679) func declarations returning an error
 991348 (100.0% of  991348) statements
 217490 ( 21.9% of  991348) if statements
  88891 ( 40.9% of  217490) if <err> != nil statements
    485 (  0.5% of   88891) <err> name is different from "err" (-l flag lists details)
  59500 ( 66.9% of   88891) return ..., <err> blocks in if <err> != nil statements
  29391 ( 33.1% of   88891) complex error handler in if <err> != nil statements; cannot use try (-l flag lists details)
    596 (  0.7% of   88891) non-empty else blocks in if <err> != nil statements; cannot use try (-l flag lists details)
  52810 ( 59.4% of   88891) try candidates (-l flag lists details)

따라서 실제 코드에서 if 문의 40%는 오류 검사를 위해 작성되고 try 는 상자에서 59%를 제거할 수 있습니다.

나는 동의한다. if err != nil이면 괜찮습니다. 단일 오류 값을 반환하는 함수의 경우 간단하고 깨끗합니다. 나는 또한 오류의 컨텍스트가 중요할 때 오류 패키지와 그 원인/랩 기능을 좋아합니다. (내가 아는 한) 코드 속성과 함께 사용자 정의 오류를 사용하려면 형식 어설션을 수행하거나 표준 오류 인터페이스 대신에 무언가를 사용해야 합니다. 어느 쪽이든, 나는 Go 코드를 읽거나 작성하고 현재 오류 처리가 어떻게 작동하는지에 대해 어떤 종류의 성가심을 느낀 적이 없습니다. 내가 겪었던 성가심은 항목 모음을 처리한 결과 여러 오류가 발생할 수 있는 경우입니다. 그러나 이것은 언어의 문제가 아니라 디자인의 문제입니다.

"오류 컨텍스트가 중요한 경우"라고 말할 때 네트워크 문제가 발생하여 다시 시도하고 싶거나 "찾기" 유형 호출의 결과가 결과를 반환하지 않은 상황을 말하는 것입니다. 실제로 없음, 또는 내 경련 손가락이 내 SQL 쿼리에 임의의 '''를 추가하여 폭발하게 만듭니다(이는 나에게 자주 발생합니다... 아마도 신경 손상을 확인해야 할 것입니다).

19년 7월 5일 Nicolas Grilly [email protected] 은 다음과 같이 썼습니다.

@kroppt 나는 수십 번 읽었습니다 ;-) 나는 시도한다는 생각에 동의하지 않습니다
코드 난독화. try는 일부를 인수분해하는 데 사용되는 내장 함수일 뿐입니다.
반복적인 코드. 우리는 프로그래머로서 항상 그렇게 합니다. 식별할 때
반복적인 패턴, 우리는 그것을 새로운 기능에서 제외합니다. 그렇지 않았다면 우리는
모든 코드가 인라인된 하나의 긴 main() 함수가 있습니다.

나는 당신을 정직하지 않다고 부르고 싶지만 Ian Lance Taylor의 말을 존경합니다.
토론을 정중하게 유지하려는 초인간적인 노력과 나는 정말로 할 수 없습니다.
누군가가 이 포럼에 의도적으로 거짓말을 함으로써 얻을 수 있는 것을 보십시오.

즉, "반복적인 패턴을 식별할 때
새로운 기능입니다." 물론이지만 충돌하는 구성을 제공하는 것은 아닙니다.
바둑 개발의 이 늦은 단계에서 두 가지
숨겨진 기능: 첫 번째는 "반환
인수 목록은 error 값으로 끝납니다."
의미 오류로) 두 번째는 숨겨진 제어 흐름을 제공합니다.
"귀환"과 유사하지만 완전히 동일하지 않은 우회
성명.

"지연"을 사용하여 거래를 유도하는 불타는 고리를 신경 쓰지 마십시오.
"시도 - 의사 함수"의 더 난해한 사용으로. 어떤 사람
다른 곳에서는 대략 "코드에서 try 를 만나고 싶지 않습니다.
읽었습니다." 같은 생각이 드는데 휩쓸려서는 안 됩니다.
양탄자.

나는 "오류 반환"의 "반환"측면이라고 말했습니다.
처리해야 하며 "오류 발생" 제안이
그 원칙은 또한 규칙을 다소 굽히기도 합니다. 내 자신도 마찬가지야
"실패" 제안(마지막 인수를 첫 번째 인수로 이동합니다.
나를 불행하게 만드는).

더 깊이, SNOBOL을 제외하고는 어떤 언어도 가능하지 않습니다.
내가 잘 알고 있는 것은 Rob Pike가 묘사한 도약을 했습니다.
"오류는 값입니다" Go가 가지고 있지만 무언가를 잃어 버렸습니다.
프로세스에서: 오류 "조건"은 값이 "아닙니다". 성공적인
함수의 완료는 특별한 경우이므로 각각 가능합니다.
실패.

각각(그리고 성공적인 완료에 적용되며,
둘 이상도) 그 장점에 따라 처리해야 하지만 우리는
호출된 함수가 다음과 관련된 의견을 알려야 한다고 주장합니다.
축약된 형태의 완성도,
그것은 영원히 이루어졌고 Rob은 오해를 하고 있는 것으로 나타났습니다.

요점을 설명하기 위해 Reader의 반환 값을 고려하십시오.
io.EOF는 때로는 성공하고 때로는
실패했지만 Go 표준에 따르면 자랑스럽게도 오류입니다("io.Err != nil").
우리도 그것을 축약하는 방법이 있습니까? 거의 확실하다
우리는 그 "잘못"을 "용서"하는 데 익숙하기 때문입니다.

비슷한 "상태" 또는
조건 코드(검색은 발견된 값 또는 실패로 끝날 수 있습니다.
다른 일을 하고 싶다면 무엇을 말합니까? 테스트를 추가하면
지식이 이미 있는 곳 - 동일한 문제, 다른
문맥).

이것은 전통적인 언어에 대한 실질적인 개선 사항입니다. 보일러 감소
그에 비해 접시는 터무니없다.

그리고 삼항 연산자와의 비교도 동일하게 유효합니다. if ?:
"남용되지 않도록" 허용되지 않으면 시도가 허용되지 않아야 합니다.
적어도 그 근거에서.

솔직히 시도는 종달새입니다. 그것은 Go를 잘못된 사람에게 더 매력적으로 만듭니다.
청중. 그렇게 하는 것의 위험성 옆에 - 누가 잘못된 사람을 원하는가
우리 커뮤니티에 가입하려면? - 판례와 쟁점이 있다.
의도하지 않은 결과. 나는 "스크랩"이라고 말하고 그것을 받아 들인다.
우리는 아직 이전 버전과의 호환성이 가능한 지점에 도달하지 않았습니다.
무시되므로 오류 처리는 장황하게 남아 있어야 합니다.

우리는 공황/회복이 있고 그것을 삼류에서 승격할 필요가 있습니다.
모든 설명과 함께 시민이 기꺼이 도와줄 수 있습니다.
그것은 초보자를 (그리고 나, 나는 그것을 두려워한다는 것을 인정합니다) 더 많이 만듭니다.
자신있게 사용합니다.

오류 처리 내의 "지연" 구성(내가 채택한 -
다른 곳에서 수입을 깨닫지 않고 - 일관되게 마무리
SQL 트랜잭션: tx.Rollback/tx.Commit)는 저에게 계시였습니다.
"범위 내에서" 배울 수 있는 더 많은 원칙이 있을 수 있습니다.
Go가 이미 제공하는 것: 지금은 그 상자 안에 머물자.

커프에서 벗어난 한 가지는 오류 보고에 전달하는 것입니다.
일반적인 조건에서 실행될 "error.Methods"의 기능 목록
결과를 보고하는 대신 조건(io.EOF, sql.ErrNoRows)
흑백으로. 하지만 나는 그런 문제에 있어 학교를 다니지 않았어, 내 제안
너무 순진해 남들이 (로저, 듣고 있니?)
아이디어를 실현합니다.

루시오.

"타자를 치는 것은 지루하지 않다. 우리가 같은 것을 가지고 있을 때 읽는 것은 지루하다.
곳곳에 3줄. 그것은 반복이고 우리는 일반적으로 프로그래머로서
이것들을 배제하는 경향이 있습니다. 시도에는 다른 단점이 있을 수 있지만 이것은 아닙니다.
내가 생각하는 하나."

다시 말하지만, 부정직하거나 최소한 합리화합니다. 나는 그
세 줄은 쓰여진 것보다 훨씬 더 많이 읽히지만,
Griesemer가 완화하려는 고통은 읽기가 아니라 쓰기에 있습니다.

• 의심할 여지 없이 그는 유익한 결과로 인식합니다.

그러나 "err != nil"은 매우 친숙한 표시이며 "읽을 때" - 다음과 같이
편집기를 사용하여 "검색"하는 것과는 대조적으로 해당 패턴은
스팟 및 취소하기 쉽습니다. 팩토링은 동일하지 않습니다.
전혀 리그. 그리고 가격이 틀립니다.

"프로그래머로서의 우리"는 더 복잡한 패턴을 먼저 고려하는 경향이 있습니다.
드물게 발생하더라도. 우리는 또한 "if err != nil { return
err }"는 매우 간단한 명령어 시퀀스로 컴파일됩니다.
누구든지 여기에서 손을 들게 내버려 두십시오. 하나가 평등 할 수 있습니까
"시도 - 기능"과 함께 일어날 것이라고 확신하십니까?

루시오.

@lootch 이봐, 사람들을

우리는 프로그래머로서 반복적인 패턴을 배제합니다. 그것은 절대적으로 사실입니다.

반복적인 코드가 많으면 읽기 속도가 느려지므로 그것이 얼마나 부정직한지 모르겠습니다.

이에 대한 귀하의 반론은 기본적으로 "이봐, 그렇게 큰 문제가 아니다"입니다. 글쎄, 많은 사람들에게 그렇습니다.

누가 잘못된 사람들이 우리 커뮤니티에 합류하기를 원합니까?

이것은 매우 오만한 게이트 키핑입니다. 또한 tryhard 도구는 try 가 오늘날의 Go 코드베이스의 많은 부분에 직접 적용할 수 있음을 보여주었습니다. 표준 라이브러리에 있는 오류 처리 코드의 70%에 직접 적용할 수 있습니다. 코드 변경( defer 등을 사용하여 오류 장식 사용)으로 모든 Go 코드에서 오류 처리의 80% 이상에 적용할 수 있다고 생각합니다.

동의합니다. 여기에서 목표를 초과하고 있습니다. 나는 사과.

이 토론으로 인해 우리 중 일부는 칼라 아래 뜨거워지고 있다고 생각합니다.
원을 그리며 돌아다닙니다.

19년 7월 7일에 Michal Štrba [email protected] 은 다음과 같이 썼습니다.

@lootch 이봐, 사람들을
그들은 당신이 그와 같이 표시한 진술과 같지 않다고 확신합니다.
합리적인.

우리는 프로그래머로서 반복적인 패턴을 배제합니다.
진실.

반복적인 코드가 많으면 읽기 속도가 느려지므로 어떻게 되는지 모르겠습니다.
불합리하거나.

이에 대한 귀하의 반론은 기본적으로 "이런 일이 아닙니다.
큰일입니다." 글쎄요, 많은 사람들에게 그렇습니다.

누가 잘못된 사람들이 우리 커뮤니티에 합류하기를 원합니까?

이것은 매우 오만한 게이트 키핑입니다. 또한 tryhard 도구는
try 는 오늘날 대부분의 Go 코드베이스에 직접 적용할 수 있습니다. 될 수 있다
표준 라이브러리에 있는 오류 처리 코드의 70%에 직접 적용됩니다. 와 함께
코드 변경( defer 등을 사용하여 오류 장식 사용)
모든 Go 코드에서 오류 처리의 80% 이상에 적용할 수 있습니다.

--
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/golang/go/issues/32825#issuecomment -508971768

--
루시오 데 레
2 Piet Retief St
케스텔(동부 자유주)
9860 남아프리카 공화국

전화: +27 58 653 1433
휴대전화: +27 83 251 5824
팩스: +27 58 653 1435

@loot 자의식이 강합니다 ! 토론이 원으로 진행되는 것을 보는 좌절감을 이해할 수 있습니다.

저도 비슷한 맥락으로 보고 있습니다.

아마도 양측은 서로를 이해하지 못하고 있을 뿐입니다. '시도'를 사용하는 방법 이라는 내 블로그 게시물을 읽었

19년 7월 7일에 Michal Štrba [email protected] 은 다음과 같이 썼습니다.

[ ... ]
어쩌면 양쪽 모두 상대방을 이해하지 못하고 있는 것일 수도 있습니다. 당신은
사용 방법 이라는 내 블로그 게시물 읽기 '노력하다'? 내가 시도하는 곳
'시도'를 사용하는 것이 실제로 어떻게 보이는지 보여주기 위해 최선을 다합니다.
편견 없는?

나는 그렇지 않았다고 고백합니다. 절대 그럴 필요가 없기를 간절히 바라고 있습니다 :-)

Stockton이 제기했다고 생각하는 측면을 고려했습니까?
시도의 장점이 표시되고 그는 부드러운 하복부가
너도 밝혀? 나는 그와 동의하고 - 모욕의 의도가 없습니다 -
귀하의 블로그가 동일한 단점으로 고통받을 수 있습니다.

그렇지 않다면 나를 자극하십시오. 좋은 독서는 특별한 장소가 있습니다.
내 인생에서 :-)

루시오.

@lootch 저는 짧은 양의 코드로 가능한 '시도'의 많은 측면(즉, 적용할 때와 적용하지 않을 때 모두)을 보여주고 최대한 편향되지 않고 현실적이게 만들기 위해 최선을 다했습니다. 하지만 물론, 내 말을 믿지 마세요 :)

이것은 관련 Reddit 토론 에서 가장 많이 투표된 댓글이었습니다.

이것은 편향되지 않은 유용한 가상의 예입니다. 대화에 "그저 짜증나는 일"이 아닌 건설적인 내용을 추가해 주셔서 감사합니다.

@lootch 저는 짧은 양의 코드로 가능한 '시도'의 많은 측면(즉, 적용할 때와 적용하지 않을 때 모두)을 보여주고 최대한 편향되지 않고 현실적이게 만들기 위해 최선을 다했습니다. 하지만 물론, 내 말을 믿지 마세요 :)

이것은 관련 Reddit 토론 에서 가장 많이 투표된 댓글이었습니다.

이것은 편향되지 않은 유용한 가상의 예입니다. 대화에 "그저 짜증나는 일"이 아닌 건설적인 내용을 추가해 주셔서 감사합니다.

파일 경로를 인수로 사용하는 함수? 이것만으로도 이 코드가 내 리뷰를 통과하지 못할 것입니다. 일부 필드가 누락된 경우 어떻게 합니까? 재정렬?

@sirkon 물론 너무 길지 않도록 예제를 단순화했습니다. 제기한 문제를 해결하는 데 필요한 변경 사항은 오류 처리 방식에 영향을 미치지 않으며, 이것이 문제의 전부입니다.

제기한 문제를 수정하는 데 필요한 변경 사항은 오류 처리 방식에 영향을 미치지 않습니다.

그렇게 말했기 때문에?

1. 블로그 제목부터 시작하십시오. "쓰지 않는 방법"이라고 불러야 합니다. 반복해서 말하지만 파일 경로를 매개변수로 사용하는 것은 정말 나쁜 습관이며 솔직히 아래의 전체 코드도 마찬가지입니다.
2. 당신은 이것을 깨닫고 있습니까
   go resp := Respondent{ Name: name, Gender: try(parseField(s, &line, "gender")), OS: try(parseField(s, &line, "os")), Lang: try(parseField(s, &line, "lang")), }
   불량한 오류 메시지를 생성합니까? 최소한 예기치 않은 필드 오류 메시지와 누락된 필드 오류 메시지가 있어야 합니다. 스크립트 진단이 표준 이하입니다.

추신 귀하의 repos를 살펴 보았습니다. Go가 작업에 좋지 않은 도구라는 것을 알고 계십니까? 실제 Go의 응용 사례에서 가장 먼저 로그를 보는 사람은 개발자가 아니라 운영 엔지니어라는 것을 이해해야 합니다. 적절한 오류 메시지는 문제를 스스로 해결하는 데 도움이 될 수 있습니다.

@sirkon 자,

이것이 잘못된 오류 메시지를 생성한다는 것을 알고 계십니까?

그것들은 모델에 완전히 적합합니다. 형식에는 모든 필드가 순서대로 포함되어야 합니다. 오류 메시지는 매우 명확하게 알려줍니다.

코드의 품질에 이의를 제기하려면 품질 표준에 맞게 코드를 다시 작성하지 않겠습니까? 그렇게 하면 try 를 사용하도록 코드를 다시 작성하기 위해 최선을 다할 것입니다.

추신 귀하의 repos를 살펴 보았습니다. Go가 작업에 좋지 않은 도구라는 것을 알고 계십니까?

내 작업에 다른 것을 제안하시겠습니까? 꽤 많이 사용했습니다. Btw, 이것은 주제에서 벗어났습니다.

@faiface

내 작업에 다른 것을 제안하시겠습니까? 꽤 많이 사용했습니다. Btw, 이것은 주제에서 벗어났습니다.

녹? C++?

@sirkon

녹? C++?

우리는 거기에 갈. Go로 정착하기 전에 둘 다 사용했습니다. 나는 결코 뒤돌아보지 않았다.

@sirkon try 의 큰 결함 중 하나는 오류 장식을 방해한다는 것입니다. 이 경우 프로그래머는 try 의 가능한 응용 프로그램을 보여 주므로 당연히 오류 장식이 많이 발생하지 않을 것입니다.

또한, 그들이 작업한 프로젝트를 근거로 사람들을 폄하하는 것은 완전히 주제와 관련이 없으며 불필요한 일입니다. 당신은 지난 몇 개의 댓글에 대해 상당히 무례한 행동을 했으며 적어도 그 점은 알아주셨으면 합니다.

@deanveloper 댓글 감사합니다!

Btw

이 경우 프로그래머는 try의 가능한 응용 프로그램을 보여 주므로 당연히 오류 장식이 많이 발생하지 않을 것입니다.

내 블로그를 참조하는 경우 실제로 @sirkon 이 수행하는 것과 똑같은 방식이 아닌 많은 오류 장식이 진행되고 있습니다. 다음은 try 를 사용하는 프로그램의 몇 가지 오류 메시지입니다.

parse respondnts.txt: open respondnts.txt: no such file or directory
parse respondents.txt: line 12: parse field gender: expected "gender:"
parse respondents.txt: line 9: expected empty line
parse respondents.txt: line 4: parse field lang: EOF

@faiface 내 실수, 더 구체적이어야했습니다. try 는 동일한 함수 내에서 여러 오류 메시지를 원할 때 오류 장식을 권장하지 않습니다. check/handle 초안과 "명명된 핸들러" 반대 제안으로 이를 수행할 수 있었습니다. 각 메시지 주위에 장식을 추가할 수 있다는 것이 지적된 특정 인스턴스(구조체를 초기화하는 동안 try 를 사용하는 경우)에서 매우 유용했을 것이지만 불행히도 시도 제안으로 인해 수행하기가 약간 어렵습니다. 자신의 기능을 작성하지 않고.

그러나 특정 경우에는 확인/처리가 도움이 되지 않았을 것입니다. 그러나의 제안 된 아이디어 catch 와 다른 counterproposals try 추가 추가 장식으로으로 오류를 처리 할 수 있었을 것이다.

@deanveloper 하위 함수가 고유한 컨텍스트를 제공해야 하기 때문에 대부분의 경우 함수 내의 모든 오류에 대해 동일한 장식을 사용해야 합니다. 그러나 단일 함수에서 다르게 장식해야 하는 경우 try를 사용하면 여전히 쉬운 솔루션이 있습니다.

..., err := functionThatCanFail(...)
try(errors.Wrapf(err, ...))

또는 단순히 큰 기능을 여러 개의 작은 기능으로 나눕니다.

그 시점에서 내 눈에는 @faiface if err != nil 사용해야하지만 선호도의 문제라고 생각합니다.

그러나 때때로 (구조체 초기화의 경우와 같이) 여러 함수로 분할하는 것은 좋은 생각이 아닙니다. 그래도 좀 까다로워지는 것 같아요.

저는 사실 try 에 대해 슈퍼는 아니지만, 그렇다고 해서 열렬한 지지자도 아닙니다. 다른 더 나은 솔루션이 있다고 생각합니다.

@deanveloper

그러나 때때로 (구조체 초기화의 경우와 같이) 여러 함수로 분할하는 것은 좋은 생각이 아닙니다.

사실이지만 필요한 모든 특정 장식이 parseField 에서 나오기 때문에 다르게 장식할 필요도 없습니다.

다른 더 나은 솔루션이 있다고 생각합니다.

충분히 가능합니다! 더 나은 솔루션이 보이면 try 분 안에

대부분의 경우 하위 함수는 고유한 컨텍스트를 제공해야 하므로 함수 내의 모든 오류에 대해 동일한 장식을 사용해야 합니다.

@faiface 나는 이 말에 강력하게 동의하지 않습니다. 모든 함수는 호출 스택에 있는 다른 함수의 하위 함수입니다. 이는 오류 처리 흐름에서 동일한 책임이 있음을 의미합니다(즉, 상위 범위에 오류 컨텍스트를 제공함).

두 개의 데이터 청크를 단일 파일에 추가하는 함수를 상상해 보십시오. '파일에 쓸 수 없음' 문을 간신히 반환하는 경우 해당 추가 중 어느 것이 실패했는지 어떻게 구별할 수 있습니까?

우리는 모두 게으른 존재입니다. 나도 할 수만 있다면 한 번 해보고 싶다. 그리고 예, Go로 모험을 시작할 때 오류 처리가 약간 번거롭다고 생각했습니다. 몇 년 후에 내 견해가 180도 바뀌었지만 연습합니다. Go의 현재 오류 처리는 책임감 있는 프로그래밍과 좋은 디자인을 촉진한다고 생각합니다. IMHO 이 접근 방식을 약화시키는 또 다른 메커니즘을 추가하는 것은 큰 실패입니다.

@mklimuk 내 의견의 핵심 부분은 "대부분의 시간"입니다. 당신이 제공한 예제는 아마도 if err != nil 의해 가장 잘 처리될 것입니다. 여러 번 언급했듯이 try 는 모든 상황을 처리하도록 설계된 것이 아니라 가장 일반적인 상황만 처리하도록 설계되었습니다.

그리고 증거에 따르면 표준 라이브러리에 있는 모든 오류 처리 코드의 70%가 기본적으로 try 사용할 수 있고 모든 오류 처리 코드의 59%도 마찬가지입니다. 야생의.

@faiface try 가 명시적 오류 처리를 대체할 수 있다는 사실이 반드시 그래야 한다는 의미는 아닙니다. 제 경우에는 컨텍스트를 추가하지 않고 오류를 반환하는 것은 '가장 일반적인 상황'이 아닙니다. 반대입니다 :)

이 스레드에 찬성하는 사람들은 이 새로운 진술이 Go 코드를 덜 장황하게 만들기 위해 원래 Go 디자인(단순성, 명확성 등) 뒤에 있는 모든 노력을 망칠 것이라고 우려하고 있습니다.

물론입니다. 하지만 try 는 컨텍스트 없이 오류를 반환하기 위한 것이 아님을 이해하시기 바랍니다. 실제로 컨텍스트를 추가하는 가장 일반적인 경우(함수당 하나의 컨텍스트)는 try 크게 단순화됩니다.

func doSomething() (err error) {
    defer fmt.HandleErrorf(&err, "doing something")

    x := try(oneThing())
    try(anotherThing(x))
    // ...
}

깨달아야 할 것은 대부분의 경우 oneThing() 및 anotherThing() 가 자체적으로 충분한 컨텍스트를 반환하므로 간단한 "doing something: ..." 로 래핑하는 것으로 충분하다는 것입니다.

참고로 _who_가 장식을 수행하는 데 몇 가지 규칙을 사용할 수 있다고 생각합니다. stdlib에서 일부 함수는 copy: x to y 또는 이와 유사한 것을 수행합니다. 인수가 있기 때문에 개인적으로 호출자에게 장식을 맡겼습니다.

예를 들어 Copy() 가 있는 경우 return errors.Wrap(err, "writing") 와 같은 작업을 수행하고 Copy() 사용하는 호출자는 errors.Wrapf(err, "copying from %v to %v", src, dst) 또는 이와 유사한 것으로 래핑합니다.

이 두 가지는 너무 잘 섞이지 않고 때로는 중복 문자열로 끝날 수 있습니다. stdlib 스타일이 관용적이라고 말하는 것이 가장 좋습니까? 하지만 모두가 이런 행동을 했는지는 기억나지 않는다. 나는 그것이 @faiface 의 예가

나는 개인적으로 장식을 호출자에게 맡겼습니다. 인수가 있기 때문입니다.

예. 예를 들어 HTTP 요청에서 JSON 본문을 구문 분석하고 헤더를 확인하는 등의 기능을 고려하십시오. 구문상 잘못된 JSON이 제공되면 해당 책임은 실제로 할 수 있는 일은 오류를 다시 보고하는 것입니다. _caller_는 API의 어떤 부분이 호출을 시도했는지 알고 있으며, 차례로 오류를 체인 위로 전달하거나 HTTP 오류를 발행하기 전에 그에 따라 오류를 장식해야 합니다.

함수가 여러 위치에서 사용될 수 있는 범용 코드를 실제로 제외하면 오류를 장식하는 데 필요한 정보가 없습니다. 반대로 모든 컨텍스트가 있는 경우에는 독립 실행형 함수로 의미가 있는 함수가 아닐 수 있습니다. 코드를 분할하여 실제보다 더 잘 정리된 것처럼 보이게 하는 함수를 만드는 것일 뿐입니다.

@lpar Mind가 이에 대한 구체적인 예를 제시합니까?

이미 구체적인 예를 들었습니까? parseJSON 함수가 실제로 컨텍스트를 알고 있고 본문을 구문 분석하는 API 엔드포인트 및 활동 흐름을 장식할 수 있는지 고려하십시오. 이는 해당 엔드포인트에만 해당되거나 오류를 래핑하는 데 사용할 수 있도록 정보를 전달했음을 암시합니다.

@lpar 좋습니다. if err != nil 가 계속 사용되는 또 다른 예입니다. 또는 논리를 여러 기능으로 분할합니다.

그러나 try 가 적절하지 않은 예를 제시하는 것은 try 에 대한 논쟁이 아님을 이해하십시오. try 는 모든 오류 처리를 대체하기 위한 것이 아니라 가장 일반적인 경우입니다.

@abejide001 try 제안은 다른 많은 언어의 전통적인 "try/catch"가 아니라 Rust의 try! 매크로와 훨씬 유사합니다. 좋은 밈 롤

죄송합니다. 잘못된 문제에 게시되었습니다. https://github.com/golang/go/issues/32437#issuecomment -509024693으로 이동했습니다.

나는 최근에 try 매크로가 가지고 있는 위험한 중첩 기능에 대한 내 의견 불일치에 기반한 #32968 제안을 게시했습니다. 심각한 결점이 없기를 바라지만, 나는 작가로서 어떤 것도 볼 수 있는 적임자가 아니다. 그래서 저는 제 _시도하지 마십시오_ 캠프(당신:)에게 그것을 보고, 평가하고, 의견을 말하도록 요청하고 싶습니다.

발췌:

• _ check 매크로는 한 줄짜리가 아닙니다 .
  동일한 표현을 사용하는 검사는 근접하여 수행해야 합니다._
• _암시적 버전은 이미 놀이터에서

설계 제약(충족)

내장되어 있으며 한 줄에 중첩되지 않으며 try 보다 더 많은 흐름을 허용하고 내부 코드의 모양에 대해 기대하지 않습니다. 벌거벗은 반환을 권장하지 않습니다.

사용 예

// built-in 'check' macro signature: 
func check(Condition bool) {}

check(err != nil) // explicit catch: label.
{
    ucred, err := getUserCredentials(user)
    remote, err := connectToApi(remoteUri)
    err, session, usertoken := remote.Auth(user, ucred)
    udata, err := session.getCalendar(usertoken)

  catch:               // sad path
    ucred.Clear()      // cleanup passwords
    remote.Close()     // do not leak sockets
    return nil, 0, err // dress before leaving
}
// happy path

// implicit catch: label is above last statement
check(x < 4) 
  {
    x, y = transformA(x, z)
    y, z = transformB(x, y)
    x, y = transformC(y, z)
    break // if x was < 4 after any of above
  }

도움이 되기를 바랍니다. 즐기세요!

그러나 try 가 적절하지 않은 예를 제시하는 것은 try 에 대한 논쟁이 아님을 이해하십시오. try 는 모든 오류 처리를 대체하기 위한 것이 아니라 가장 일반적인 경우입니다.

그리고 이전 에 try 는 내 오류 반환의 한 자리 백분율(*)에만 적합하므로 더 나은 것이 필요하다고 생각합니다.

(*) 그리고 사실, 나는 네이키드 err 반환 인스턴스가 수정되어야 할 오류일 가능성이 높다고 생각하는 경향이 있습니다.

전적으로 동의합니다. "if err != nil"은 그대로 두십시오.

@abejide001 try 제안은 다른 많은 언어의 전통적인 "try/catch"가 아니라 Rust의 try! 매크로와 훨씬 유사합니다. 좋은 밈 롤

이것만으로도 저에게는 걱정거리입니다. Go는 이미 초보자들에게 생소한 언어입니다. 이제 try 에 맞춤 로직이 있는 이유를 설명해야 합니다. FWIW, 나는 "Rust가 그것을 해냈다"라고 말하는 것이 언어에 어떤 것을 추가하는 것을 정당화하는 건전한 이유라고 생각하지 않습니다. 단지 잘 알려지지 않았을 뿐입니다.

@ 기능을 정당화하기 위해 말한 것이 아니라 기능이 무엇을했는지 명확히하기 위해 말한 것입니다. 저는 try 제안을 중간에 하고 있습니다.

이것이 큰 차이를 만드는 것은 아니지만 매크로 대신 키워드를 사용하더라도 Swift의 기능이기도 합니다.

시도가 정확히 무엇을 달성하려고 하는지에 대해 약간의 혼란이 있는 것 같습니다. IMHO, 문제는 오류를 확인하는 여러 if 블록을 작성하지 않는 것입니다. 한 번 작성하면 끝입니다. 문제는 이러한 블록이 여러 개 있는 코드를 읽는 것입니다. 우리는 쓰기보다 읽기를 더 많이 합니다. 그리고 이러한 블록은 실제 코드와 얽혀 있기 때문에 실제 코드를 난독화합니다. 설상가상으로 대부분의 경우 if 블록 내의 어딘가에 약간의 문자열 차이만 있을 뿐 거의 동일합니다.

나는 개인적으로 오래된 수표 처리 초안을 선호했지만 이것은 적어도 오류와 비즈니스 경로를 분리하는 데 좋은 역할을 합니다. 그리고 마침내 우리는 각 호출에 대해 반대되는 단일 함수 범위 컨텍스트를 가질 수 있을 것입니다. 이는 현재 상위 오류와 동일한 것을 반복할 가능성이 높습니다.

@icholy 는 다음

보다 간소화된 오류 처리를 요청하는 커뮤니티 피드백이 압도적으로 많았습니다(연간 설문조사에서). Go 팀은 현재 이 문제를 해결하고 있습니다.

방금 설문조사를 여기에서 찾았습니다: https://blog.golang.org/survey2018-results

분명히 질문은 "오늘 바둑을 사용하면서 개인적으로 직면한 가장 큰 도전은 무엇입니까?"였습니다. 가능한 답변 "오류 처리"와 함께.

질문 + 답변을 기반으로 더 간단한 구문이 필요하다고 추론했는지 진지하게 궁금합니다. '오류 처리'라고 대답했을 수도 있지만 다른 구문을 보고 싶지는 않았습니다. 설문조사에서 이 옵션을 선택했다면 오류를 래핑하고 스택 추적을 제공하는 등의 작업을 더 잘 수행할 수 있다고 생각했을 것입니다.

내 제안은 모든 오류 처리 제안에서 물러나 는 것입니다(효과적으로

저는 방금 try 제안을 살펴보았지만, 제가 놓치고 있는 것이 없다면 "상용문 if 문을 제거하기 위해 [...}"를 제외하고 제안되고 있는 _이유_를 말하는 것을 무시합니다. 그러나 왜 이러한 상용구를 제거해야 하는지에 대한 언급은 없습니다.

위의 내용에 확실히 동의합니다. 새로운 오류 값 변경이 사람들이 Go에 대해 가지고 있는 오류 처리 불만을 돕는 데 도움이 되는지 봅시다. 그러면 더 간단한 구문이 필요한지 확인할 수 있습니다.

여기 사람들은 반환된 모든 오류에 주석을 달아야 한다고 생각하기 때문에 try 에 대해 논쟁하고 있습니다. 현실은 현재 코드 모음(표준 라이브러리 포함)에서 높은 비율의 오류 검사가 ~bare~ 주석 처리되지 않은 오류를 반환하고 try 이점을 얻을 수 있다는 것입니다. 코드 가 어떠해야 하는지에 대한 당신의 믿음은 코드 IS 와 아무 관련이 없습니다. 당신의 도그마를 살려주세요.

@icholy 오류 무시는 개발자가 해당 오류에 관심이 없음을 나타냅니다. 오류가 중요하지 않거나 호출자가 불가능하다고 생각합니다. 그렇다면 "시도"는 무의미하고 호출자는 단순히 "시도"에 함수를 래핑하지 않을 것입니다.

내 제안은 모든 오류 처리 제안에서 물러나 는 것입니다(효과적으로

나는 이것에 강력하게 동의합니다. Go 오류 처리에 대한 개선 사항이 지원되어야 하는 기능에 대한 기본적인 불일치가 많이 있습니다. 사람들이 언급하는 기능의 모든 다른 부분은 이름과 구문에 대해 바이크쉐딩을 유발하므로 논의는 아무데도 진행되지 않습니다.

더 광범위한 Go 커뮤니티가 제안된 새로운 오류 처리 기능에서 실제로 원하는 것이 무엇인지 더 자세히 알고 싶습니다.

나는 사람들이 제안하는 것을 본 많은 다른 기능, 오류 처리 기능을 나열하는 설문 조사를 작성했습니다. 나는 신중하게 제안된 이름이나 구문을 _생략_했고, 물론 내 자신의 의견을 선호하기보다는 설문조사를 중립적으로 만들려고 노력했습니다.

사람들이 참여하고 싶다면 공유하기 위해 축약된 링크가 있습니다.

https://forms.gle/gaCBgxKRE4RMCz7c7

참여하는 모든 사람이 요약 결과를 볼 수 있어야 합니다. 그런 다음 사람들이 실제로 원하는 것이 무엇인지 더 잘 알게 되면 try 제안이 그러한 것을 제공하는지 여부에 대해 지능적인 토론을 할 수 있습니다. (그런 다음 구문 논의로 넘어갈 수도 있습니다.)

@lane-c-wagner 주석이 없는 오류를 반환하는 것은 전혀 반환하지 않는 것과 같다고 말하려는 건가요? 편집: 이전 댓글

@icholy 아 제가 잘못 이해했습니다. "bare"라고 말했을 때 "_"가 오류를 무시했다는 것을 의미한다고 생각했습니다.

이 제안은 어떤 조치도 유효한 조치가 되어서는 안 된다고 주장합니다. 이 변경은 코드를 읽기 때문에 언어의 모든 사용자에게 영향을 줍니다. 따라서 가장 큰 장애물을 식별하는 설문조사는 여전히 커뮤니티에 이 장애물을 고칠 가치가 있는지 물어봐야 합니다. 이 제안은 그러한 질문에 대한 가장 가까운 평가입니다.

"모두가 무시해도 좋다" try 라는 말은 이제 그만하세요. 우리는 다른 사람들이 작성한 코드를 읽습니다.

@tv42 여기 에서 저를 말씀 하시는지 모르겠지만 저도 그렇게 말했는데 요점이 있습니다. 청구된 대로 유죄. 그런 일반화에 좀 더 신중을 기하도록 노력하겠습니다. 감사 해요.

@griesemer 설문조사가 많이 부족했습니다. 나는 오류 처리에 투표했지만 내가 의미하는 문제는 장황한 것이 아니라 완전한 유형의 안전성이었습니다. 오류에 대해서만 다른 것을 만드는 것이 좋습니다.

그리고 나는 여전히 합계 유형을 원합니다.

이것은 현재 gofmt가 err != nil인 경우 형식을 지정하는 방식에 대한 제안입니다.

(이는 try() 제안에 대한 의견이 아닙니다.)

if 문이 다음과 같이 nil이 아닌 한 줄 오류 값을 반환하는 경우:

err := myFunc()
if err != nil {
    return err
}

gofmt는 자체 if 문 규칙을 완화하고 다음과 같이 한 줄에 형식을 지정할 수 있습니다.

err := myFunc()
if err != nil { return err }

세 줄의 오류 처리 코드가 한 줄로 됩니다. 덜 복잡합니다. 프로그램 흐름을 따라가기 쉽습니다.

이것으로 선(말장난 인정)을 그릴 위치에 대한 판단이 필요할 것입니다.
gofmt 규칙 변경. 다음과 같은 장식이 포함될 수 있습니다.

err := myFunc()
if err != nil { return fmt.Errorf("myFunc() blew up! %v", err }

그러나 정교한 다중 행 오류 처리는 그대로 유지되어야 합니다. 다중 행 및 명확하고 명시적입니다.

_try_ 제안이 철회되었습니다: https://github.com/golang/go/issues/32437#issuecomment -512035919

제네릭 누구?

이것은 현재 gofmt가 err != nil인 경우 형식을 지정하는 방식에 대한 제안입니다.

나는 그것을 시도했지만 코드는 여러 줄 형식을 사용하는 것보다 훨씬 더 읽을 수 없습니다. 시도는 그 솔루션보다 훨씬 낫습니다.

여기서 IMO 문제는 오류 처리가 수행되는 방식 이 아니라 무시 되는지 여부입니다. if err != nil 구문을 그대로 두는 것이 가능하지만 Error 반환에 대한 무지를 제한할 수 없습니까? 레거시 코드에 대한 심각도 옵션이 있는 컴파일러 경고/오류를 만드는 것과 같습니다.

여기서 IMO 문제는 오류 처리가 수행되는 방식 이 아니라 무시 되는지 여부입니다. if err != nil 구문을 그대로 두는 것이 가능하지만 Error 반환에 대한 무지를 제한할 수 없습니까? 레거시 코드에 대한 심각도 옵션이 있는 컴파일러 경고/오류를 만드는 것과 같습니다.

많은 사람들이 무시된 오류를 보여주는 린터를 원합니다.

나는 이것을 어려운 오류로 만드는 것을 선호하지만 이미 작성된 수많은 레거시를 보면 linter도 공정합니다.

https://github.com/kisielk/errcheck 처리되지 않은 오류 @plyhun @sorenvonsarvort 에 대해 알려주는 것이 중요합니다.

#32437에 대한 토론에서 볼 수 있듯이 이 제안은 현재로서는 사실상 수락되었습니다. 폐쇄. 문제가 다시 발생하면 새 제안을 열 수 있습니다.

나는 많은 제안이 옳지 않다고 느끼는 이유 중 하나가 실제로 동시에 두 가지 다른 문제를 해결하려고 하기 때문이라고 생각하기 시작했습니다. 한편으로는 거의 모든 함수 호출 후에 err != nil 블록을 사용하면 확실히 장점이 있기는 하지만 코드 흐름이 이상한 방식으로 중단될 수 있다는 것이 사실입니다. 문제. 다른 문제는 관련 오류 여부에 관계없이 여러 반품을 처리하는 것이 상당히 투박할 수 있다는 것입니다.

여러 반환 함수는 겉보기에 작은 차이에도 불구하고 단일 반환 함수와 매우 다르게 느껴집니다. 하나 이상의 인수를 취하는 함수 호출에 추가 제한이 있는 경우와 같습니다. 가끔 대하는 것이 매우 이상하게 느껴집니다. 여러 반환 값이 있는 함수를 호출할 때 거의 항상 자체 행에서 호출해야 하며 := 와 결합되어 다른 곳에서 논의된 다양한 변수 섀도잉 문제의 주요 원인이 되는 경우가 많습니다. . 메서드 호출을 연결하거나 같은 줄에 있는 구조체 필드와 새 변수에 직접 할당할 수 없습니다.

모르겠어요. 저만 그럴 수도 있어요. 하지만 저는 거의 10년 동안 Go를 사용해 왔으며 여러 반환이 있는 함수를 호출하는 것이 여전히 가끔 어색하게 느껴집니다.

감사합니다!

실제로 하나 개의 문제에 있습니다 if err != nil 의 범위 err 이상은해야보다 더 살 수 있습니다. if 인라인하면 문제가 해결되지만 모든 케이스를 인라인할 수 있는 것은 아닙니다.

if err := foo(); err != nil {

if _, err := bar(); err != nil {



md5-6a135eb952fe7b24b3389cb16d3244a1



a, err := bar()
if err != nil {



md5-d52f811d3e31bb368bd8045cfb2e93b4



var err error
baz.A, err = bar()
if err != nil {

err 변수는 if err != nil {} 블록이 완료된 후 함수 범위에 존재하지 않아야 합니다. 다음은 https://github.com/golang/go/issues/33161 문제를 해결하기 위한 try() 제안을 기반으로 하는 제 제안입니다 . 건설적인 피드백을 원합니다.

if err != nil {} 블록이 완료된 후에는 err 변수가 함수 범위에 없어야 합니다.

if 블록이 완료된 후에 왜 "존재하지 않아야"합니까? 컴파일러는 이를 위해 최적화할 수 있으며(필요하다고 생각되는 경우) err := stmt()\nif err != nil {} 블록이 완료될 때 거의 항상 함께 진행되기 때문에 정신적 부하가 없습니다.

나는 아직 당신의 제안을 깊이 있게 살펴보지는 않았습니다. 그러나 위의 의견에서도 설명했듯이 문제를 해결하기 위한 제안을 파헤치기 전에 인식된 문제에 대해 더 많은 연구가 필요하다고 생각합니다.

@Freeaqingme 오류는 if err != nil 블록이 완료된 후 존재하지 않아야 합니다. 대부분은 이미 존재하지 않는 것처럼 행동하기 때문입니다.

CopyFile 예제에는 r, err := os.Open(src) 다음에 w, err := os.Create(dst) 있습니다. 두 번째 err 는 첫 번째

다른 기이한 것들도 있습니다. err := foo() 이후에 bar.V, err = baz() 와 같은 코드가 있고 코드가 리팩터링되고 더 이상 foo() 가 필요하지 않은 경우 baz 앞에 var err error 를 추가해야 합니다. baz 라인. . 함수의 다른 위치를 리팩토링하는 것이 그런 다른 위치에 영향을 미쳐서는 안 된다고 생각합니다.

기술적으로

    r, err := os.Open(src)
    if err != nil {
        return ...
    }
    w, err := os.Create(dst)

err 의 두 번째 인스턴스는 첫 번째 인스턴스를 가리지 않습니다. 그들은 실제로 같은 변수입니다. https://golang.org/ref/spec#Short_variable_declarations 에서 변수 재선언에 대한 설명을 참조

함수 doSomeThing() {
r, err := os.Open(파일 이름)
패닉(fmt.Errorf(err, "파일 열기 실패: %s", 파일명)) //
여기가 패닉입니다.

}

2019년 10월 10일 목요일 오전 11시 24분에 clearcode [email protected]에서 다음과 같이 작성했습니다.

내장 기능을 추가할 수 있다고 생각합니다.

주장하다()

예시:

func doSomeThing() 오류 {

r, err := os.Open(filename)
assert(err, "failed to open file: %s", filename) // in this step, just return the error

resp,err := http.Get(someURL)
assert(오류, "요청 실패")

}

오류를 반환하지 않는 또 다른 함수:

함수 doSomeThing() {
r, err := os.Open(파일 이름)
assert(err, "파일 열기 실패: %s", filename) // 여기서 패닉입니다.

}

따라서 assert(error, args ...interface{})가 다음보다 낫습니다. if err != nil ; {
반환 오류 }

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/golang/go/issues/32825?email_source=notifications&email_token=AGUV7XQ5HO7GL3YP72R7BV3QN2N55A5CNFSM4H4DL33KYY3PNVWWK3TUL52HS4DFVEXG43VMVBW
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/AGUV7XS4JMK44QHIIR3RSGTQN2N55ANCNFSM4H4DL33A
.

요점은 현재 반환된 실제 오류를 보고 싶다는 것입니다.
현재 줄의 기능.

2019년 10월 11일 금요일 오전 9시 55분 Aaaa Einai [email protected] 작성:

함수 doSomeThing() {
r, err := os.Open(파일 이름)
패닉(fmt.Errorf(err, "파일 열기 실패: %s", filename)) // 여기서 패닉입니다.

}

2019년 10월 10일 목요일 오전 11:24 clearcode 알림 @github.com
썼다:

내장 기능을 추가할 수 있다고 생각합니다.

주장하다()

예시:

func doSomeThing() 오류 {

r, err := os.Open(filename)
assert(err, "failed to open file: %s", filename) // in this step, just return the error

resp,err := http.Get(someURL)
assert(오류, "요청 실패")

}

오류를 반환하지 않는 또 다른 함수:

함수 doSomeThing() {
r, err := os.Open(파일 이름)
assert(err, "파일 열기 실패: %s", filename) // 여기서 패닉입니다.

}

따라서 assert(error, args ...interface{})가 다음보다 낫습니다. if err != nil ; {
반환 오류 }

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/golang/go/issues/32825?email_source=notifications&email_token=AGUV7XQ5HO7GL3YP72R7BV3QN2N55A5CNFSM4H4DL33KYY3PNVWWK3TUL52HS4DFVEXG43VMVBW
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/AGUV7XS4JMK44QHIIR3RSGTQN2N55ANCNFSM4H4DL33A
.

솔직히 저는 try 제공하는 암시적 반환을 원하지 않습니다. 제네릭이 있다면 대신 모나드 방식의 동작을 사용하는 솔루션을 훨씬 더 선호할 것입니다.

type Result<T> interface {
  Expect(err error) T
  OrElse(defaultValue T) T
}

func From<T>(value T, err error) Result<T> { ... }

나에게 이것은 현재 제안된 내장보다 훨씬 깨끗하지만 (값, 오류) 및 Result

Rust의 Ok and Err과 매우 유사합니다.
if err != nil {} 조금 더 나은 것 같아요.

@Yanwenjiepy 의도적입니다. 저는 Rust의 Result 유형을 좋아합니다.

바둑을 배운 지 10분도 채 되지 않았습니다. 내가 보고 있던 코드에서 가장 먼저 알아차린 것은 이 사본을 계속해서 붙여넣었다는 것입니다.

someValue, err := someFunction();
if err != nil {
  panic(err)
}

나는 분명히 전문가가 아니지만 이 스레드에서 끝내기 위해 나를 처음 보았을 때만 가치가 있을 수 있습니다.

학습을 위해 코드 조각을 보고 있기 때문입니다. 실제 코드는 패닉과 충돌뿐만 아니라 오류를 처리해야 합니다.

사실이지만 오류는 그룹화될 수 있으며 종종 그룹화되어야 합니다. 이것이 try/catch 블록이 다른 언어에 존재하는 이유입니다. 예를 들어, 다음은 나에게 공룡과 같은 냄새가 훨씬 덜할 것입니다.

try {
  foo, throw err := someFunction();
  bar, throw err := foo.get();
  baz, throw err := bar.make();
  qux, throw err := baz.transform();
} catch(err) {
  // "Unable to foo bar baz qux."
  tryHarder();
}

다시 한 번, 완전한 평신도. 그러나 코드는 기호일 뿐이며 충분히 반복되면 기호도 만들 수 있습니다. 이것은 매우 자주 반복되는 기호로 보입니다.

Rob Pike의 Errors Are Values 게시물을 살펴보고 도우미를 사용하여 오류를 병합하고 한 번에 처리하는 방법을 확인할 수 있습니다. 실제로 단일 절로 모든 예외를 잡는 것은 실제로 발생한 일에 대한 정보를 숨기기 때문에 해당 예외가 있는 대부분의 언어에서 나쁜 스타일로 간주됩니다. (그리고 예를 확장하여 개별적으로 포착된 예외를 분리하고 해당 정보를 버리지 않으면 코드는 Go에 해당하는 한 끝납니다.)

링크 주셔서 감사합니다. errWriter 는 완전히 통과 가능한 솔루션입니다.

사실이지만 오류는 그룹화될 수 있으며 종종 그룹화되어야 합니다. 이것이 try/catch 블록이 다른 언어에 존재하는 이유입니다. 예를 들어, 다음은 나에게 공룡과 같은 냄새가 훨씬 덜할 것입니다.

try {
  foo, throw err := someFunction();
  bar, throw err := foo.get();
  baz, throw err := bar.make();
  qux, throw err := baz.transform();
} catch(err) {
  // "Unable to foo bar baz qux."
  tryHarder();
}

다시 한 번, 완전한 평신도. 그러나 코드는 기호일 뿐이며 충분히 반복되면 기호도 만들 수 있습니다. 이것은 매우 자주 반복되는 기호로 보입니다.

각 함수가 중복 오류 유형을 반환하고 모든 함수 결과를 정상적으로 처리해야 한다고 가정해 보겠습니다. tryHarder()는 어떻게 작성합니까?

try {
  foo, throw err := someFunction();  // err could be TypeA and TypeB
  bar, throw err := foo.get();       // err could be TypeB and TypeC
  baz, throw err := bar.make();      // err could be TypeA and TypeC
  qux, throw err := baz.transform(); // err could be TypeB and TypeD
} catch(err) {
  tryHarder(); // tell me how to handle each error?
}

다른 사람이 아래 코드를 이해하는 데 1분 밖에 걸리지 않습니다.

foo, err := someFunction();  // err could be TypeA and TypeB
if err != nil {
 // handle err
}

bar, err := foo.get();       // err could be TypeB and TypeC
if err != nil {
  // handle err
}

baz, err := bar.make();      // err could be TypeA and TypeC
if err != nil {
  // handle err
}

qux, err := baz.transform(); // err could be TypeB and TypeD
if err != nil {
  // handle err
}

각 함수가 중복 오류 유형을 반환하고 모든 함수 결과를 정상적으로 처리해야 한다고 가정해 보겠습니다.

그 예에서 당신은 완전히 맞습니다.