syscall.Chdir(dir) || &PathError{"chdir", dir, e}

e 어디에서 왔습니까? 오식?

또는 다음을 의미했나요?

func Chdir(dir string) (e error) {
    syscall.Chdir(dir) || &PathError{"chdir", dir, e}
    return nil
}

(즉, 암시적 err != nil 검사가 먼저 결과 매개변수에 오류를 할당하고 암시적 반환 전에 다시 수정하도록 이름을 지정할 수 있습니까?)

한숨, 내 자신의 예를 망쳤습니다. 이제 수정되었습니다: e 는 err 이어야 합니다. 제안은 err 를 대입문에 없을 때 함수 호출의 오류 값을 유지하기 위해 범위에 넣습니다.

아이디어나 구문에 동의하는지 확실하지 않지만 오류를 반환하기 전에 오류에 컨텍스트를 추가하는 데 주의를 기울인 점을 인정해야 합니다.

이것은 https://github.com/pkg/errors 를 작성한 @davecheney 에게 .

이 코드에서 일어나는 일:

if foo, err := thing.Nope() || &PathError{"chdir", dir, err}; err == nil || ignoreError {
}

( || &PathError{"chdir", dir, e} 부분이 없어도 이것이 가능하지 않다면 사과드립니다. 저는 이것이 기존 동작을 혼란스럽게 재정의하는 것처럼 느껴지고 암시적 반환이... 교활하다고 표현하려고 합니다.)

@object88 if 및 for 및 switch 문에서 사용되는 SimpleStmt에서 이 새로운 경우를 허용하지 않는 것이 좋습니다. 문법이 약간 복잡해지긴 하지만 그게 최선일 것입니다.

하지만 그렇게 하지 않으면 thing.Nope() 가 nil이 아닌 오류를 반환하면 호출 함수가 &PathError{"chdir", dir, err} 와 함께 반환됩니다(여기서 err 는 thing.Nope() 호출에 의해 설정된 변수). thing.Nope() 가 nil 오류를 반환하면 if 문의 조건에서 err == nil 가 참임을 확실히 알고 있으므로 본문 if 문이 실행됩니다. ignoreError 변수는 읽지 않습니다. 여기에는 기존 동작에 대한 모호성이나 재정의가 없습니다. 의 처리 || 후 표현하면 여기에서 소개에만 허용됩니다 || 이 현재 컴파일되지 것을 의미 부울 값이 아닙니다.

나는 암시적 반환이 교활하다는 데 동의합니다.

예, 제 예는 매우 좋지 않습니다. 그러나 if , for 또는 switch 내부의 작업을 허용하지 않으면 많은 잠재적인 혼란이 해결됩니다.

고려해야 할 바는 일반적으로 언어에서 그대로 하기 어려운 것이기 때문에 이 변형이 언어로 인코딩하는 것이 얼마나 어려운지 확인하기로 결정했습니다. 다른 것보다 어렵지 않습니다: https://play.golang.org/p/9B3Sr7kj39

나는 한 가지 유형의 값과 반환 인수의 한 위치를 특별하게 만들기 위한 이러한 모든 제안을 정말 싫어합니다. 이것은 이 특정 컨텍스트에서 err 를 특별한 이름으로 만들기 때문에 어떤 면에서는 실제로 더 나쁩니다.

나는 확실히 사람들(저를 포함하여!)이 추가 컨텍스트 없이 오류를 반환하는 데 지쳐야 한다는 데 동의합니다.

다음과 같은 다른 반환 값이 있는 경우

if err != nil {
  return 0, nil, "", Struct{}, wrap(err)
}

확실히 읽기 지루할 수 있습니다. https://github.com/golang/go/issues/19642#issuecomment -288559297에서 return ..., err 에 대한 @nigeltao 의 제안이 다소 마음에 들었습니다.

내가 올바르게 이해한다면 구문 트리를 구축하려면 파서는

boolean := BoolFunc() || BoolExpr

그리고

err := FuncReturningError() || Expr

좋지 않아 보인다.

적은 것이 더 ...

반환되는 ExpressionList에 두 개 이상의 요소가 포함되어 있으면 어떻게 작동합니까?

BTW, 나는 대신 panicIf를 원합니다.

err := doSomeThing()
panicIf(err)

err = doAnotherThing()
panicIf(err)

@ianlancetaylor 제안서의 예에서 err 는 여전히 명시적으로 선언되지 않고 '마법 같은'(언어 사전 정의)으로 당겨집니다. 맞습니까?

아니면 다음과 같을 것인가

func Chdir(dir string) error {
    return (err := syscall.Chdir(dir)) || &PathError{"chdir", dir, err}
}

?

반면에 (이미 "언어 변경"으로 표시되어 있기 때문에 ...)
오류 != nil(또는 nullable?)에 대한 바로 가기를 수행하는 새 연산자(!! 또는 ??)를 도입합니다.

func DirCh(dir string) (string, error) {
    return dir, (err := syscall.Chdir(dir)) !! &PathError{"chdir", dir, err}
}

너무 멀었다면 죄송합니다 :)

Go에서 오류 처리가 반복될 수 있다는 데 동의합니다. 나는 반복에 신경 쓰지 않지만 너무 많은 반복은 가독성에 영향을 미칩니다. "Cyclomatic Complexity"(믿든 말든)가 제어 흐름을 복잡성에 대한 척도로 사용하는 이유가 있습니다. "if" 문은 추가 노이즈를 추가합니다.

그러나 제안된 구문 "||" 특히 기호가 일반적으로 OR 연산자로 알려져 있기 때문에 읽기가 매우 직관적이지 않습니다. 또한 여러 값과 오류를 반환하는 함수를 어떻게 처리합니까?

나는 여기에 몇 가지 아이디어를 던지고 있습니다. 오류를 출력으로 사용하는 대신 오류를 입력으로 사용하는 것은 어떻습니까? 예: https://play.golang.org/p/rtfoCIMGAb

모든 의견에 감사드립니다.

@opennota 좋은 지적입니다. 여전히 작동할 수 있지만 그 측면이 어색하다는 데 동의합니다.

@mattn 반환 ExpressionList가 없다고 생각하므로 무엇을 묻는지 잘 모르겠습니다. 호출 함수에 여러 결과가 있는 경우 마지막을 제외한 모든 결과가 유형의 0 값으로 반환됩니다.

@mattn panicif 는 이 제안의 핵심 요소 중 하나를 다루지 않습니다. 이는 추가 컨텍스트와 함께 오류를 반환하는 쉬운 방법입니다. 그리고 물론 오늘날에도 충분히 쉽게 panicif 쓸 수 있습니다.

@tandr 예, err 는 마법처럼 정의되어 있습니다. 이것은 매우 끔찍합니다. 또 다른 가능성은 error-expression이 error 를 사용하여 오류를 참조하도록 허용하는 것입니다. 이는 다른 방식으로 끔찍합니다.

@tandr 다른 연산자를 사용할 수 있지만 큰 이점은 없습니다. 결과를 더 읽기 쉽게 만들지 않는 것 같습니다.

@henryas 제 생각에는 제안서가 여러 결과를 처리하는 방법을 설명한다고 생각합니다.

@henryas 예를 들어 주셔서 감사합니다. 그런 종류의 접근 방식에 대해 내가 싫어하는 것은 오류 처리를 코드의 가장 두드러진 측면으로 만든다는 것입니다. 오류 처리가 표시되고 표시되기를 원하지만 줄의 첫 번째 항목이 되는 것은 원하지 않습니다. 이것은 오늘날 if err != nil 관용구와 오류 처리 코드의 들여쓰기와 함께 사실이며 오류 처리를 위해 새로운 기능이 추가되는 경우에도 사실로 유지되어야 합니다.

다시 한번 감사합니다.

@ianlancetaylor 내 놀이터 링크를 확인했는지 모르겠지만 추가 컨텍스트를 추가할 수 있는 "panicIf"가 있습니다.

여기에서 다소 단순화된 버전을 재현하겠습니다.

func panicIf(err error, transforms ...func(error) error) {
  if err == nil {
    return
  }
  for _, transform := range transforms {
    err = transform(err)
  }
  panic(err)
}

공교롭게도 저는 방금 GopherCon 에서 오류 처리 코드를 시각화하는 데 도움이 되는 약간의 구문을 사용(심각하게 제안하지는 않았지만)했습니다. 아이디어는 코드를 단축하기 위한 마술에 의존하지 않고 해당 코드를 옆에 두어 주요 흐름을 방해하지 않도록 하는 것입니다. 결과는 다음과 같습니다.

func DirCh(dir string) (string, error) {
    dir := syscall.Chdir(dir)        =: err; if err != nil { return "", err }
}

여기서 =: 는 구문의 새로운 비트이며 다른 방향으로 할당하는 := 의 미러입니다. 분명히 우리는 = 에도 무언가가 필요합니다. 이것은 분명히 문제가 있습니다. 그러나 일반적인 아이디어는 정보를 잃지 않고 독자가 행복한 길을 더 쉽게 이해할 수 있도록 하는 것입니다.

반면에, 현재의 오류 처리 방식은 단일 기능에서 너무 많은 일을 하고 있을 수 있고 일부 리팩토링이 지연될 수 있음을 눈부신 알림 역할을 한다는 점에서 몇 가지 장점이 있습니다.

@billyh가 제안한 구문이 정말 마음에 .

func Chdir(dir string) error {
    e := syscall.Chdir(dir) catch: &PathError{"chdir", dir, e}
    return nil
}

또는 https://github.com/pkg/errors 를 사용하는 더 복잡한 예

func parse(input io.Reader) (*point, error) {
    var p point

    err := read(&p.Longitude) catch: nil, errors.Wrap(err, "Failed to read longitude")
    err = read(&p.Latitude) catch: nil, errors.Wrap(err, "Failed to read Latitude")
    err = read(&p.Distance) catch: nil, errors.Wrap(err, "Failed to read Distance")
    err = read(&p.ElevationGain) catch: nil, errors.Wrap(err, "Failed to read ElevationGain")
    err = read(&p.ElevationLoss) catch: nil, errors.Wrap(err, "Failed to read ElevationLoss")

    return &p, nil
}

오류 장식을 지원하지만 더 과감한 언어 변경(go1.10은 아님)이 필요한 단순한 아이디어는 새로운 check 키워드의 도입입니다.

check A 및 check A, B 두 가지 형식이 있습니다.

A 및 B 는 모두 error 여야 합니다. 두 번째 형식은 오류를 장식할 때만 사용됩니다. 자신의 오류를 장식할 필요가 없거나 꾸미고 싶지 않은 사람들은 더 간단한 형식을 사용합니다.

첫 번째 양식(A 체크)

check A 는 A 평가합니다. nil 이면 아무 작업도 수행하지 않습니다. nil 아니면 check 는 return {<zero>}*, A 처럼 작동합니다.

예

• 함수가 오류를 반환하면 check 인라인으로 사용할 수 있으므로

err := UpdateDB()    // signature: func UpdateDb() error
if err != nil {
    return err
}

된다

check UpdateDB()

• 여러 반환 값이 있는 함수의 경우 지금처럼 할당해야 합니다.

a, b, err := Foo()    // signature: func Foo() (string, string, error)
if err != nil {
    return "", "", err
}

// use a and b

된다

a, b, err := Foo()
check err

// use a and b

두 번째 형식(A, B 체크)

check A, B 는 A 평가합니다. nil 이면 아무 작업도 수행하지 않습니다. nil 아니면 check 는 return {<zero>}*, B 처럼 작동합니다.

이것은 오류 장식을 위한 것입니다. 우리는 여전히 확인 A , 그러나입니다 B 암시 적으로 사용되는 return .

예시

a, err := Bar()    // signature: func Bar() (string, error)
if err != nil {
    return "", &BarError{"Bar", err}
}

된다

a, err := Foo()
check err, &BarError{"Bar", err}

노트

컴파일 오류입니다

• error 평가되지 않는 항목에 check 문 사용
• { type }*, error 형식이 아닌 반환 값이 있는 함수에서 check { type }*, error

두 개의 expr 형식 check A, B 이 단락되었습니다. B A 가 nil 이면 B 는 평가되지 않습니다.

실용성에 대한 참고 사항

오류 꾸미기에 대한 지원이 있지만 실제로 오류를 장식해야 할 때만 더 복잡한 check A, B 구문에 대해 비용을 지불합니다.

if err != nil { return nil, nil, err } 상용구( 매우 일반적임)의 경우 check err 는 명확성을 희생하지 않고 가능한 한 간단합니다(아래 구문에 대한 참고 참조).

구문에 대한 참고 사항

이런 종류의 구문( check .. , 줄 시작 부분에 return 와 유사)이 제어 흐름 중단을 숨기지 않고 상용구 검사 오류를 제거하는 좋은 방법이라고 주장합니다. 암시적 반환이 도입되었습니다.

위의 <do-stuff> || <handle-err> 및 <do-stuff> catch <handle-err> 또는 다른 스레드에서 제안된 a, b = foo()? 와 같은 아이디어의 단점은 흐름을 어렵게 만드는 방식으로 제어 흐름 수정을 숨긴다는 것입니다. 따르다; 전자는 평범해 보이는 줄 끝에 || <handle-err> 기계가 추가 되고, 후자는 평범한 코드 줄의 중간 과 끝 을 포함하여 모든 곳에 나타날 수 있는 작은 기호가 있습니다. 아마도 여러 번.

check 문은 현재 블록에서 항상 최상위 수준이 되며 제어 흐름을 수정하는 다른 문(예: 초기 return )과 동일한 중요성을 갖습니다.

@ALTree , 귀하의 예를 이해하지 못했습니다.

a, b, err := Foo()
check err

원본에서 세 가지 가치 있는 수익을 달성합니다.

return "", "", err

최종 오류를 제외하고 선언된 모든 반환값에 대해 0 값만 반환합니까? 오류와 함께 유효한 값을 반환하려는 경우(예: Write()가 실패할 때 작성된 바이트 수)는 어떻습니까?

어떤 솔루션을 사용하든 오류 처리의 일반성을 최소한으로 제한해야 합니다.

줄의 시작 부분에 check 있는 값과 관련하여 내 개인적인 선호는 각 줄의 시작 부분에서 기본 제어 흐름을 보고 오류 처리가 기본 제어 흐름의 가독성을 최소한으로 방해하도록 하는 것입니다. 가능한 한. 또한 오류 처리가 check 또는 catch 와 같은 예약어로 구분되어 있으면 거의 모든 최신 편집기에서 예약어 구문을 어떤 식으로든 강조 표시하고 눈에 띄게 만들 것입니다. 오른쪽에 있다면.

@billyh 이것은 위에서 다음과 같은 줄에 설명되어 있습니다.

nil이 아닌 경우 check는 return {<zero>}*, A 처럼 작동합니다.

check 는 오류(마지막 위치)를 제외한 모든 반환 값의 0 값을 반환합니다.

오류와 함께 유효한 값을 반환하려는 경우는 어떻습니까?

그런 다음 if err != nil { 관용구를 사용합니다.

보다 정교한 오류 복구 절차가 필요한 경우가 많습니다. 예를 들어 오류를 포착한 후 무언가를 롤백하거나 로그 파일에 기록해야 할 수 있습니다. 이 모든 경우에 도구 상자에 여전히 일반적인 if err 관용구가 있으며 이를 사용하여 새 블록을 시작할 수 있습니다. 실시한다.

어떤 솔루션을 사용하든 오류 처리의 일반성을 최소한으로 제한해야 합니다.

위의 내 대답을 참조하십시오. 여전히 if 와 언어가 제공하는 다른 모든 것을 사용할 수 있습니다.

거의 모든 현대 편집기는 예약어를 강조 표시합니다.

아마도. 그러나 가독성을 위해 구문 강조 표시가 필요한 불투명한 구문을 도입하는 것은 이상적이지 않습니다.

이 특정 버그는 언어에 이중 반환 기능을 도입하여 수정할 수 있습니다.
이 경우 함수 a()는 123을 반환합니다.

함수 a() 정수 {
비()
반환 456
}
함수 b() {
반환 반환 int(123)
}

이 기능을 사용하여 다음과 같이 오류 처리를 단순화할 수 있습니다.

func 핸들(var *foo, err error )(var *foo, err error ) {
오류 != nil {
반환 반환 없음, 오류
}
반환 var, nil
}

func client_code() (*client_object, 오류) {
var obj, err =handle(something_that_can_fail())
// 실패하지 않은 경우에만 도달
// 그렇지 않으면 client_code 함수가 오류를 스택 위로 전파합니다.
주장(오류 == 없음)
}

이를 통해 사람들은 스택 위로 오류를 전파할 수 있는 오류 처리기 함수를 작성할 수 있습니다.
이러한 오류 처리 기능은 기본 코드와 분리될 수 있습니다.

제가 잘못 이해했다면 죄송합니다. 하지만 요점을 명확히 하고 싶습니다. 아래 함수는 오류, vet 경고를 생성하거나 허용됩니까?

func Chdir(dir string) (err error) {
    syscall.Chdir(dir) || err
    return nil
}

@rodcorsi 이 제안에 따라 귀하의 예는 수의사 경고 없이 받아들여질 것입니다. 그것은 동등 할 것입니다

if err := syscall.Chdir(dir); err != nil {
    return err
}

Context의 사용을 확장하여 오류를 처리하는 것은 어떻습니까? 예를 들어 다음과 같은 정의가 주어집니다.
type ErrorContext interface { HasError() bool SetError(msg string) Error() string }
이제 오류가 발생하기 쉬운 기능에서 ...
func MyFunction(number int, ctx ErrorContext) int { if ctx.HasError() { return 0 } return number + 1 }
중간 기능에서 ...
func MyIntermediateFunction(ctx ErrorContext) int { if ctx.HasError() { return 0 } number := 0 number = MyFunction(number, ctx) number = MyFunction(number, ctx) number = MyFunction(number, ctx) return number }
그리고 상위 레벨 기능에서
func main() { ctx := context.New() no := MyIntermediateFunction(ctx) if ctx.HasError() { log.Fatalf("Error: %s", ctx.Error()) return } fmt.Printf("%d\n", no) }
이 접근 방식을 사용하면 몇 가지 이점이 있습니다. 첫째, 주요 실행 경로에서 독자를 산만하게 하지 않습니다. 기본 실행 경로와의 편차를 나타내는 최소한의 "if" 문이 있습니다.

둘째, 오류를 숨기지 않습니다. 메서드 서명에서 ErrorContext를 수락하면 함수에 오류가 있을 수 있음이 분명합니다. 함수 내에서 일반적인 Go 코드를 사용하여 오류를 처리하는 방법을 보여주는 일반적인 분기 문(예: "if")을 사용합니다.

셋째, 오류는 이 경우 컨텍스트 소유자인 이해 당사자에게 자동으로 버블링됩니다. 추가 처리 오류가 있는 경우 명확하게 표시됩니다. 예를 들어 기존 오류를 래핑하기 위해 중간 함수를 약간 변경해 보겠습니다.
func MyIntermediateFunction(ctx ErrorContext) int { if ctx.HasError() { return 0 } number := 0 number = MyFunction(number, ctx) number = MyFunction(number, ctx) number = MyFunction(number, ctx) if ctx.HasError() { ctx.SetError(fmt.Sprintf("wrap msg: %s", ctx.Error()) return } number *= 20 number = MyFunction(number, ctx) return number }
기본적으로 필요에 따라 오류 처리 코드를 작성하면 됩니다. 수동으로 버블링할 필요가 없습니다.

마지막으로, 함수 작성자는 오류를 처리해야 하는지 여부를 결정할 수 있습니다. 현재 Go 접근 방식을 사용하면 이 작업을 쉽게 수행할 수 있습니다.
````
// 다음 정의가 주어졌을 때
func MyFunction(숫자 정수) 오류

//그러면 이렇게
MyFunction(8) //오류를 확인하지 않고
With the ErrorContext, you as the function owner can make the error checking optional with this:
func MyFunction(ctx ErrorContext) {
ctx != nil && ctx.HasError() {
반품
}
//...
}
Or make it compulsory with this:
func MyFunction(ctx ErrorContext) {
if ctx.HasError() { //ctx가 nil이면 패닉
반품
}
//...
}
If you make error handling compulsory and yet the user insists on ignoring error, they can still do that. However, they have to be very explicit about it (to prevent accidental ignore). For instance:
func UpperFunction(ctx ErrorContext) {
무시됨 := context.New()
MyFunction(ignored) // 이것은 무시됩니다.

 MyFunction(ctx) //this one is handled

}
````
이 접근 방식은 기존 언어를 변경하지 않습니다.

@ALTree Alberto, check 와 @ianlancetaylor가 제안한 것을 어떻 습니까?

그래서

func F() (int, string, error) {
   i, s, err := OhNo()
   if err != nil {
      return i, s, &BadStuffHappened(err, "oopsie-daisy")
   }
   // all is good
   return i+1, s+" ok", nil
}

된다

func F() (int, string, error) {
   i, s, err := OhNo()
   check i, s, err || &BadStuffHappened(err, "oopsie-daisy")
   // all is good
   return i+1, s+" ok", nil
}

또한 오류 유형만 처리하도록 check 를 제한할 수 있으므로 여러 반환 값이 필요한 경우 이름을 지정하고 할당해야 하므로 어떻게든 "in-place"를 할당하고 간단한 "return"처럼 작동합니다.

func F() (a int, s string, err error) {
   i, s, err = OhNo()
   check err |=  &BadStuffHappened(err, "oopsy-daisy")  // assigns in place and behaves like simple "return"
   // all is good
   return i+1, s+" ok", nil
}

return 가 언젠가 표현식에서 허용된다면 check 는 필요하지 않거나 표준 함수가 됩니다.

func check(e error) bool {
   return e != nil
}

func F() (a int, s string, err error) {
   i, s, err = OhNo()
   check(err) || return &BadStuffHappened(err, "oopsy-daisy")
   // all is good
   return i+1, s+" ok", nil
}

마지막 솔루션은 Perl처럼 느껴지지만 😄

누가 처음 제안했는지 기억나지 않지만 여기에 또 다른 구문 아이디어가 있습니다(모두가 가장 좋아하는 자전거 보관소 :-). 나는 그것이 좋은 것이라고 말하지는 않지만 우리가 아이디어를 냄비에 던지면 ...

x, y := try foo()

다음과 같습니다.

x, y, err := foo()
if err != nil {
    return (an appropriate number of zero values), err
}

그리고

x, y := try foo() catch &FooErr{E:$, S:"bad"}

다음과 같습니다.

x, y, err := foo()
if err != nil {
    return (an appropriate number of zero values), &FooErr{E:err, S:"bad"}
}

try 형식은 모듈로 피상적인 구문 차이로 이전에 여러 번 제안된 적이 있습니다. try ... catch 형식은 덜 자주 제안되지만 @ALTree 의 check A, B 구성 및 @tandr 의 후속 제안과 분명히 유사합니다. 한 가지 차이점은 이것이 문이 아니라 표현이라는 점이므로 다음과 같이 말할 수 있습니다.

z(try foo() catch &FooErr{E:$, S:"bad"})

단일 문에 여러 개의 try/catch가 있을 수 있습니다.

p = try q(0) + try q(1)
a = try b(c, d() + try e(), f, try g() catch &GErr{E:$}, h()) catch $BErr{E:$}

비록 우리가 그것을 장려하고 싶지 않다고 생각하지만. 여기에서 평가 순서에 대해서도 주의해야 합니다. 예를 들어 e() 가 nil이 아닌 오류를 반환하는 경우 h() 가 부작용에 대해 평가되는지 여부.

분명히 try 및 catch 와 같은 새 키워드는 Go 1.x 호환성을 깨뜨릴 것입니다.

나는 우리가 이 제안의 목표를 짜야 한다고 제안합니다. 이 제안으로 어떤 문제가 해결됩니까? 다음 세 줄을 두 줄 또는 한 줄로 줄이십시오. 이것은 반환/만약의 언어가 변경될 수 있습니다.

if err != nil {
    return err
}

아니면 오류를 확인하는 횟수를 줄입니까? 이를 위한 try/catch 솔루션일 수 있습니다.

오류 처리를 위한 합리적인 바로 가기 구문에는 세 가지 속성이 있다고 제안하고 싶습니다.

1. 오류가 아닌 경로가 눈에 띄도록 검사 중인 코드 앞에 나타나지 않아야 합니다.
2. 동일한 이름을 가진 명시적 변수가 있을 때 독자가 혼동하지 않도록 암시적 변수를 범위에 도입해서는 안 됩니다.
3. 하나의 복구 작업(예: return err )을 다른 작업보다 쉽게 ​​만들지 않아야 합니다. 때로는 완전히 다른 작업이 선호될 수 있습니다(예 t.Fatal 호출). 또한 사람들이 추가 컨텍스트를 추가하는 것을 막고 싶지 않습니다.

이러한 제약 조건을 감안할 때 거의 최소한의 구문은 다음과 같습니다.

STMT SEPARATOR_TOKEN VAR BLOCK

예를 들어,

syscall.Chdir(dir) :: err { return err }

에 해당하는

if err := syscall.Chdir(dir); err != nil {
    return err
}
````
Even though it's not much shorter, the new syntax moves the error path out of the way. Part of the change would be to modify `gofmt` so it doesn't line-break one-line error-handling blocks, and it indents multi-line error-handling blocks past the opening `}`.

We could make it a bit shorter by declaring the error variable in place with a special marker, like

syscall.Chdir(dir) :: { @err 반환 }
```

이것이 0이 아닌 값과 오류가 모두 반환된 경우 어떻게 작동하는지 궁금합니다. 예를 들어 bufio.Peek은 0이 아닌 값과 ErrBufferFull을 동시에 반환할 수 있습니다.

@mattn 여전히 이전 구문을 사용할 수 있습니다.

@nigeltao 네,

ret, err := doSomething() :: err { return err }
return ret, err

@jba 설명하고 있는 것은 전치된 함수 구성 연산자와 약간 비슷합니다.

syscall.Chdir(dir) ⫱ func (err error) { return &PathError{"chdir", dir, err} }

그러나 우리가 대부분 명령적인 코드를 작성하고 있다는 사실은 요점의 일부가 조기에 반환할 수 있다는 것이기 때문에 두 번째 위치에 함수를 사용 하지 않아야 한다는 것을 요구합니다.

이제 저는 모든 종류의 관련이 있는 세 가지 관찰에 대해 생각하고 있습니다.

1. 오류 처리는 함수 구성과 비슷하지만 Go에서 작업을 수행하는 방식은 Haskell의 Error 모나드 와 정반대입니다. 우리는 대부분 순차 코드 대신 명령형 코드를 작성하기 때문에

2. (x, y, error) 를 반환하는 Go 함수는 일반적으로 (x, y) | error 의 합집합(#19412)과 같은 것을 의미합니다.

3. unpack 또는 pattern-match 공용체 언어에서 경우는 별도의 범위이며 Go에서 오류가 발생하는 많은 문제는 해당 범위를 분리하여 개선될 수 있는 재선언된 변수의 예기치 않은 그림자 때문에 발생합니다(#21114).

그래서 아마도 우리가 정말로 원하는 것은 =: 연산자와 같지만 일종의 조합 일치 조건이 있는 것입니다.

syscall.Chdir(dir) =? err { return &PathError{"chdir", dir, err} }

```가다
n := io.WriteString(w, s) =? 오류 { 오류 반환 }

and perhaps a boolean version for `, ok` index expressions and type assertions:
```go
y := m[x] =! { return ErrNotFound }

범위 지정을 제외하고는 gofmt 를 단일 라이너에 더 적합하도록 변경하는 것과 크게 다르지 않습니다.

err := syscall.Chdir(dir); if err != nil { return &PathError{"chdir", dir, err} }

```가다
n, 오류 := io.WriteString(w, s); if err != nil { 오류를 반환 }

```go
y, ok := m[x]; if !ok { return ErrNotFound }

하지만 범위 지정은 중요합니다! 범위 지정 문제는 이러한 종류의 코드가 "다소 못생긴"에서 "미묘한 버그"로 선을 넘는 위치입니다.

@ianlancetaylor
나는 전반적인 아이디어의 팬이지만 그것에 대한 비밀스러운 펄과 같은 구문의 열렬한 지지자는 아닙니다. 아마도 다음과 같이 더 장황한 구문이 덜 혼란스러울 것입니다.

syscall.Chdir(dir) or dump(err): errors.Wrap(err, "chdir failed")

syscall.Chdir(dir) or dump

또한 할당의 경우 마지막 인수가 표시되는지 여부를 이해하지 못했습니다. 예:

resp := http.Get("https://example.com") or dump

오류는 특별한 유형이 아니라 go의 값이라는 것을 잊지 마십시오.
우리가 다른 구조체에 대해 할 수 있는 것은 오류에 대해 할 수 없고 그 반대입니다. 이것은 일반적으로 구조체를 이해한다면 오류와 처리 방법을 이해한다는 것을 의미합니다(장황하다고 생각하더라도)

이 구문은 신규 및 기존 개발자가 해당 정보를 사용하는 코드를 이해하기 시작하기 전에 새로운 정보를 배워야 합니다.

그것만으로도 이 제안은 IMHO의 가치가 없습니다.

개인적으로 이 구문을 선호합니다

err := syscall.Chdir(dir)
if err != nil {
    return err
}
return nil

~ 위에

if err := syscall.Chdir(dir); err != nil {
    return err
}
return nil

한 줄 더 있지만 의도한 작업과 오류 처리를 구분합니다. 이 양식이 가장 읽기 쉽습니다.

@bcmills :

범위 지정을 제외하고는 gofmt를 단일 라이너에 더 적합하도록 변경하는 것과 크게 다르지 않습니다.

범위 지정뿐만 아니라 왼쪽 가장자리도 있습니다. 나는 그것이 가독성에 정말 영향을 미친다고 생각합니다. 제 생각에는

syscall.Chdir(dir) =: err; if err != nil { return &PathError{"chdir", dir, err} } 

보다 훨씬 명확하다

err := syscall.Chdir(dir); if err != nil { return &PathError{"chdir", dir, err} } 

특히 연속된 여러 줄에서 발생하는 경우 눈이 왼쪽 가장자리를 스캔하여 오류 처리를 무시할 수 있기 때문입니다.

@bcmills 라는 아이디어를 혼합하여 조건부 파이프 전달 연산자를 도입할 수 있습니다.

F2 함수는 마지막 값이 nil 이

func F1() (foo, bar){}

first := F1() ?> last: F2(first, last)

return 문을 사용한 파이프 전달의 특별한 경우

func Chdir(dir string) error {
    syscall.Chdir(dir) ?> err: return &PathError{"chdir", dir, err}
    return nil
}

다른 호에서 @urandom 이 가져온 실제 예
기본 흐름에 중점을 두어 훨씬 더 읽기 쉽습니다.

func configureCloudinit(icfg *instancecfg.InstanceConfig, cloudcfg cloudinit.CloudConfig) (cloudconfig.UserdataConfig, error) {
    // When bootstrapping, we only want to apt-get update/upgrade
    // and setup the SSH keys. The rest we leave to cloudinit/sshinit.
    udata := cloudconfig.NewUserdataConfig(icfg, cloudcfg) ?> err: return nil, err
    if icfg.Bootstrap != nil {
        udata.ConfigureBasic() ?> err: return nil, err
        return udata, nil
    }
    udata.Configure() ?> err: return nil, err
    return udata, nil
}

func ComposeUserData(icfg *instancecfg.InstanceConfig, cloudcfg cloudinit.CloudConfig, renderer renderers.ProviderRenderer) ([]byte, error) {
    if cloudcfg == nil {
        cloudcfg = cloudinit.New(icfg.Series) ?> err: return nil, errors.Trace(err)
    }
    _ = configureCloudinit(icfg, cloudcfg) ?> err: return nil, errors.Trace(err)
    operatingSystem := series.GetOSFromSeries(icfg.Series) ?> err: return nil, errors.Trace(err)
    udata := renderer.Render(cloudcfg, operatingSystem) ?> err: return nil, errors.Trace(err)
    logger.Tracef("Generated cloud init:\n%s", string(udata))
    return udata, nil
}

오류 처리가 인체 공학적이지 않다는 데 동의합니다. 즉, 아래 코드를 읽을 때 if error not nil then 로 발음해야 합니다. 이는 if there is an error then 변환됩니다.

if err != nil {
    // handle error
}

위의 코드를 그런 식으로 표현할 수 있는 능력을 갖고 싶습니다. 제 생각에는 더 읽기 쉽습니다.

if err {
    // handle error
}

저의 소박한 제안입니다 :)

펄처럼 보이지만 매직 변수도 있습니다.
참고로 펄에서는

open (FILE, $file) or die("$file을 열 수 없습니다: $!");

IMHO, 그럴 가치가 없습니다. 내가 go에 대해 좋아하는 한 가지는 오류 처리입니다.
노골적이며 '당신의 얼굴에'

우리가 그것을 고수한다면 마법의 변수가 없기 를 바랍니다 .
오류 변수의 이름을 지정할 수 있습니다.

e := syscall.Chdir(dir) ?> e: &PathError{"chdir", dir, e}

그리고 ||와 다른 기호를 사용할 수도 있습니다. 이 작업에 특정한
나는 거꾸로 때문에 '또는'과 같은 텍스트 기호가 불가능하다고 생각합니다.
호환성

n, _, err, _ = somecall(...) ?> err: &PathError{"somecall", n, err}

2017년 8월 1일 화요일 오후 2시 47분에 Rodrigo [email protected] 은 다음과 같이 썼습니다.

아이디어 혼합 @bcmills https://github.com/bcmills 우리가 소개할 수 있습니다.
조건부 파이프 전달 연산자.

F2 함수는 마지막 값이 nil 이

func F1()(foo, bar){}
첫 번째 := F1() ?> 마지막: F2(처음, 마지막)

return 문을 사용한 파이프 전달의 특별한 경우

func Chdir(dir 문자열) 오류 {
syscall.Chdir(dir) ?> err: return &PathError{"chdir", dir, err}
반환 없음
}

실제 예
https://github.com/juju/juju/blob/01b24551ecdf20921cf620b844ef6c2948fcc9f8/cloudconfig/providerinit/providerinit.go
@urandom https://github.com/urandom 이 다른 문제에서 가져왔습니다.
기본 흐름에 중점을 두어 훨씬 더 읽기 쉽습니다.

func configureCloudinit(icfg *instancecfg.InstanceConfig, cloudcfg cloudinit.CloudConfig) (cloudconfig.UserdataConfig, 오류) {
// 부트스트랩할 때 apt-get 업데이트/업그레이드만 원합니다.
// SSH 키를 설정합니다. 나머지는 cloudinit/sshinit에 맡깁니다.
udata := cloudconfig.NewUserdataConfig(icfg, cloudcfg) ?> 오류: 반환 없음, 오류
if icfg.Bootstrap != nil {
udata.ConfigureBasic() ?> err: 반환 없음, 오류
udata를 반환, nil
}
udata.Configure() ?> err: 반환 없음, 오류
udata를 반환, nil
}
func ComposeUserData(icfg *instancecfg.InstanceConfig, cloudcfg cloudinit.CloudConfig, renderer renderers.ProviderRenderer) ([]byte, error) {
만약 cloudcfg == nil {
cloudcfg = cloudinit.New(icfg.Series) ?> err: 반환 없음, errors.Trace(err)
}
configureCloudinit(icfg, cloudcfg) ?> err: 반환 없음, 오류.Trace(err)
OperatingSystem := series.GetOSFromSeries(icfg.Series) ?> err: 반환 없음, 오류.Trace(err)
udata := renderer.Render(cloudcfg, operatingSystem) ?> err: 반환 없음, 오류.Trace(err)
logger.Tracef("생성된 클라우드 초기화:\n%s", 문자열(udata))
udata를 반환, nil
}

—
이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/golang/go/issues/21161#issuecomment-319359614 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AbwRO_J0h2dQHqfysf2roA866vFN4_1Jks5sTx5hgaJpZM4Oi1c-
.

이 제안된 모든 변경 사항이 현재 형식보다 더 복잡할 것이라고 생각하는 유일한 사람입니까?

단순함과 간결함은 동등하거나 상호 교환할 수 없다고 생각합니다. 예, 이러한 모든 변경 사항은 한 줄 이상 더 짧지만 언어 사용자가 배워야 하는 연산자나 키워드를 도입합니다.

@rodcorsi 사소한 것처럼 보이지만 두 번째 부분이 Block 이 되는 것이 중요하다고 생각합니다. 기존 if 및 for 문은 모두 블록을 사용하고 select 및 switch 둘 다 중괄호로 구분된 구문을 사용하므로 이 특정 제어 흐름 작업에 대해 중괄호를 생략하는 것이 어색해 보입니다.

또한 새 기호 다음에 오는 임의의 표현식에 대해 걱정할 필요가 없다면 구문 분석 트리가 모호하지 않은지 확인하는 것이 훨씬 쉽습니다.

스케치를 위해 염두에 두었던 구문과 의미는 다음과 같습니다.

NonZeroGuardStmt = ( Expression | IdentifierList ":=" Expression |
                     ExpressionList assign_op Expression ) "=?" [ identifier ] Block .
ZeroGuardStmt = ( Expression | IdentifierList ":=" Expression |
                  ExpressionList assign_op Expression ) "=!" Block .

NonZeroGuardStmt 가 실행 Block 의 마지막 값 경우 Expression 되지 않고, 그 종류의 제로 값과 동일. identifier 이 있으면 Block 내의 해당 값에 바인딩됩니다. ZeroGuardStmt 는 Expression 의 마지막 값이 해당 유형의 0 값과 같으면 Block ZeroGuardStmt 실행합니다.

들어 := 형태의 다른 (선도) 값 Expression 받는 바인딩 IdentifierList A의 같은 ShortVarDecl . 식별자는 포함 범위에서 선언되며 이는 Block 내에서도 볼 수 있음을 의미합니다.

assign_op 형식의 경우 각 왼쪽 피연산자는 주소 지정 가능, 지도 색인 표현식 또는 ( = 할당의 경우에만) 빈 식별자여야 합니다. 피연산자는 괄호로 묶을 수 있습니다. 오른쪽 Expression 의 다른 (선행) 값은 Assignment 에서와 같이 평가됩니다. 할당은 Block 실행 전에 발생하며 Block 실행 여부에 관계없이 발생합니다.

여기에 제안된 문법이 Go 1과 호환된다고 생각합니다. ? 는 유효한 식별자가 아니며 해당 문자를 사용하는 기존 Go 연산자가 없으며 ! 가 유효한 연산자이지만 없음 { 다음에 올 수 있는 기존 프로덕션.

@bcmills LGTM,

=? 및 =! 각각 자체 토큰으로 만들면 문법이 쉽게 호환될 것이라고 생각했을 것입니다.

나는 당신이 할 것이라고 생각했을 것입니다 =? 그리고 =! 각각의 토큰은 고유한 권한을 가지므로 문법이 거의 호환되지 않습니다.

문법에서는 그렇게 할 수 있지만 어휘분석기에서는 할 수 없습니다. 시퀀스 "=!" 유효한 Go 1 코드(https://play.golang.org/p/pMTtUWgBN9)에 나타날 수 있습니다.

중괄호는 내 제안에서 구문 분석을 명확하게 만드는 것입니다. =! 는 현재 부울 변수 선언 또는 할당에만 나타날 수 있으며 선언 및 할당은 현재 중괄호(https 암시적 세미콜론 (https://play.golang.org/p/lhcqBhr7Te)으로

@romainmenke 아니요. 당신은 유일한 사람이 아닙니다. 한 줄짜리 오류 처리의 가치를 보지 못했습니다. 한 줄은 절약할 수 있지만 훨씬 더 복잡해집니다. 문제는 이러한 제안 중 많은 부분에서 오류 처리 부분이 숨겨져 있다는 것입니다. 아이디어는 오류 처리가 중요하기 때문에 눈에 띄지 않게 만드는 것이 아니라 코드를 읽기 쉽게 만드는 것입니다. 간결함은 쉬운 가독성과 같지 않습니다. 기존 오류 처리 시스템을 변경해야 하는 경우 기존의 try-catch-finally가 많은 아이디어 목적보다 훨씬 더 매력적입니다.

check 제안이 마음에 듭니다. 처리하도록 확장할 수도 있기 때문입니다.

f, err := os.Open(myfile)
check err
defer check f.Close()

다른 제안도 defer 와 섞일 수 없는 것 같습니다. check 도 매우 읽기 쉽고 Google에서 모르는 경우 간단합니다. error 유형으로 제한할 필요는 없다고 생각합니다. 마지막 위치에 있는 반환 매개변수라면 무엇이든 사용할 수 있습니다. 그래서하는 반복자는있을 수 있습니다 check A에 대한 Next() bool .

나는 한 번 다음과 같은 스캐너를 작성했습니다.

func (s *Scanner) Next() bool {
    if s.Error != nil || s.pos >= s.RecordCount {
        return false
    }
    s.pos++

    var rt uint8
    if !s.read(&rt) {
        return false
    }
...

마지막 비트는 대신 check s.read(&rt) 수 있습니다.

@carlmjohnson

다른 제안도 defer 와 섞일 수 없는 것 같습니다.

새 구문을 사용하여 외부 함수에서 반환할 수 있도록 defer 를 확장한다고 가정하면 해당 가정을 다른 제안에도 똑같이 적용할 수 있습니다.

defer f.Close() =? err { return err }

@ALTree 의 check 제안은 별도의 명령문을 도입하기 때문에 단순히 오류를 반환하는 것 외에 다른 작업을 수행하는 defer 와 이를 어떻게 혼합할 수 있는지 모르겠습니다.

defer func() {
  err := f.Close()
  check err, fmt.Errorf(…, err) // But this func() doesn't return an error!
}()

차이:

defer f.Close() =? err { return fmt.Errorf(…, err) }

이러한 제안 중 많은 부분에 대한 정당성은 "인체 공학"이 더 낫다는 것이지만 입력할 내용이 약간 줄어들도록 만드는 것 외에 어떤 것이 더 나은지 잘 모르겠습니다. 이것들이 어떻게 코드의 유지보수성을 증가시키는가? 합성 가능성? 가독성? 제어 흐름을 이해하기 쉽습니까?

@jimmyfrasche

이것들이 어떻게 코드의 유지보수성을 증가시키는가? 합성 가능성? 가독성? 제어 흐름을 이해하기 쉽습니까?

앞서 언급했듯이 이러한 제안의 주요 이점은 할당 및 err 변수의 범위를 보다 명확하게 지정하는 것입니다. #19727, #20148, #5634, #21114 및 다양한 사람들이 오류 처리와 관련하여 범위 지정 문제에 직면하는 방식.

@bcmills 동기 부여를 제공

그러나 그 전제를 감안할 때 모든 변수에서 사용할 수 있는 "할당의 보다 명확한 범위 지정"을 위해 보다 일반적인 기능을 제공하는 것이 더 좋지 않을까요? 나는 의도치 않게 오류가 아닌 변수에 대해서도 그림자를 드리웠습니다.

:= 의 현재 동작이 도입되었을 때를 기억합니다. 많은 스레드가 '해당 변수가 정확히 현재 범위"가 내 경험상 보기 힘든 모든 미묘한 문제가 나타나는 곳입니다.

† 링크가 있는 스레드를 찾을 수 없습니까?

바둑에 대해 개선할 수 있는 부분이 많이 있지만 := 의 행동은 항상 한 가지 심각한 실수로 저를 놀라게 했습니다. := 의 동작을 다시 방문하는 것이 근본 문제를 해결하거나 최소한 다른 극단적인 변경의 필요성을 줄이는 방법일 수 있습니다.

@jimmyfrasche

그러나 그 전제를 감안할 때 모든 변수에서 사용할 수 있는 "할당의 보다 명확한 범위 지정"을 위해 보다 일반적인 기능을 제공하는 것이 더 좋지 않을까요?

예. 그것은 @jba 와 내가 제안한 =? 또는 :: 연산자에 대해 내가 좋아하는 것 중 하나입니다. 또한 오류가 아닌 (확실히 제한된 하위 집합)까지 멋지게 확장됩니다.

개인적으로, 나는 더 명시적인 태그 결합/변수/대수 데이터 유형 기능(#19412 참조)을 사용하면 장기적으로 더 행복할 것이라고 생각하지만 언어에 대한 훨씬 더 큰 변경 사항입니다. 우리가 어떻게 개조할지 보기가 어렵습니다. Go 1 / Go 2 혼합 환경의 기존 API에 추가합니다.

제어 흐름을 이해하기 쉽습니까?

my 와 @bcmills 의 제안에서 당신의 눈은 왼쪽을 훑어보고 오류가 없는 제어 흐름을 쉽게 받아들일 수 있습니다.

@bcmills 제 생각에 #19412 단어의 적어도 절반은 제가 책임지고 있다고 생각하므로 합계 유형에 대해 저를 팔 필요가 없습니다 ;)

오류가 있는 물건을 반환하는 경우에는 4가지 경우가 있습니다.

1. 그냥 오류 (아무것도 할 필요가 없습니다, 그냥 오류를 반환)
2. 물건 및 오류(지금처럼 정확하게 처리할 수 있음)
3. 한 가지 또는 오류(합계 유형을 사용할 수 있습니다! :tada: )
4. 둘 이상의 것 또는 오류

4를 치면 상황이 복잡해집니다. 튜플 유형(구조체의 레이블이 지정된 제품 유형과 함께 사용할 레이블이 없는 제품 유형)을 도입하지 않고 합계 유형을 사용하여 "이것 또는 오류"를 모델링하려는 경우 모든 것을 구조체에 번들링하여 문제를 사례 3으로 줄여야 합니다.

튜플 유형을 도입하면 모든 종류의 문제와 호환성 문제 및 이상한 겹침이 발생합니다( func() (int, string, error) 암시적으로 정의된 튜플 또는 다중 반환 값이 별도의 개념입니까? 암시적으로 정의된 튜플이면 func() (n int, msg string, err error) 을 의미합니까?

나는 여전히 합계 유형이 많은 이점을 제공한다고 생각하지만 범위 지정 문제를 해결하기 위해 아무 것도 하지 않습니다. 결과 케이스에 무언가가 있을 때 오류 케이스를 섀도잉하는 대신 전체 '결과 또는 오류' 합계를 섀도잉할 수 있기 때문에 문제가 더 악화될 수 있습니다.

@jba 그것이 바람직한 속성인지

튜플 유형을 도입하지 않고 […] 합계 유형을 사용하여 "이것 또는 오류"를 모델링하려면 모든 것을 구조체에 [묶음]해야 합니다.

저는 괜찮습니다. 그런 식으로 호출 사이트를 훨씬 더 읽기 쉽게 만들 수 있으며(더 이상 실수로 위치 바인딩이 바뀌지 않습니다!) #12854는 현재 구조체 반환과 관련된 많은 오버헤드를 완화할 것입니다.

가장 큰 문제는 마이그레이션입니다. 특히 실제로 "값을 반환하는 io.Writer 와 같은 API가 있는 경우 Go 1의 "값 및 오류" 모델에서 Go 2의 잠재적인 "값 그리고 오류"?

나는 여전히 합계 유형이 많은 이점을 제공한다고 생각하지만 범위 지정 문제를 해결하기 위해 아무 것도 하지 않습니다.

그것은 당신이 그것들을 어떻게 풀느냐에 달려 있으며, 그것이 우리를 오늘날의 위치로 되돌려놓을 것이라고 생각합니다. 공용체를 선호하는 경우 =? 버전을 "비대칭 패턴 일치" API로 구상할 수 있습니다.

i := match strconv.Atoi(str) | err error { return err }

여기서 match 는 전통적인 ML 스타일 패턴 일치 작업이지만 완전하지 않은 일치의 경우 값을 반환합니다(union에 일치하지 않는 대안이 두 개 이상 있는 경우 interface{} ). 불완전한 경기 실패로 당황하기보다는.

https://github.com/mpvl/errd 에서 여기에서 프로그래밍 방식으로 논의된 문제를 해결하는 패키지를 체크인했습니다(언어 변경 없음). 이 패키지의 가장 중요한 측면은 오류 처리를 단축할 뿐만 아니라 올바르게 수행하기가 더 쉽다는 것입니다. 나는 특히 defer와의 상호 작용에서 전통적인 관용적 오류 처리가 보이는 것보다 더 까다로운 방법에 대한 문서의 예를 제공합니다.

하지만 나는 이것을 "버너" 패키지라고 생각합니다. 목표는 언어를 가장 잘 확장하는 방법에 대한 좋은 경험과 통찰력을 얻는 것입니다. 이것이 일이 될 경우 제네릭과 매우 잘 상호 작용합니다.

아직 몇 가지 더 많은 예제를 작업하고 있지만 이 패키지는 실험할 준비가 되어 있습니다.

@bcmills a million :+1: #12854

언급했듯이 "반환 X 및 오류" 및 "반환 X 또는 오류"가 있으므로 요청 시 이전 방식을 새로운 방식으로 변환하는 일부 매크로 없이는 실제로 이 문제를 해결할 수 없습니다. 또는 "X 및 오류" 기능에 불가피하게 사용되었을 때 적어도 런타임 패닉).

나는 특별한 매크로를 언어에 도입하는 아이디어를 정말로 좋아하지 않습니다. 특히 이것이 단지 오류 처리를 위한 것이라면, 이는 이러한 제안의 많은 부분에서 저의 주요 문제입니다.

Go는 설탕이나 마법에 대해 큰 관심을 갖고 있지 않으며 그것이 장점입니다.

보다 기능적인 오류 처리 패러다임으로의 대규모 도약을 처리하기에는 현재 관행에 인코딩된 정보가 너무 많고 정보가 너무 적습니다.

Go 2가 합계 유형을 가져오면(솔직히 좋은 의미로!) 충격을 받을 것입니다. 어쨌든 "새로운 스타일"로 이동하려면 매우 느린 점진적 프로세스가 필요하며 그 동안에도 오류를 처리하는 방법에서 더 많은 조각화와 혼란이 발생하므로 순 긍정적으로 보지 않습니다. (그러나 즉시 세 개의 채널 대신 chan union { Msg1 T; Msg2 S; Err error } 와 같은 항목에 사용하기 시작합니다.)

이것이 Go1 이전이고 바둑 팀이 "앞으로 6개월 동안 모든 것을 옮기고 문제가 발생하면 계속 따라와야 한다"고 말할 수 있다면 그것은 한 가지가 될 것이지만, 지금 우리는 기본적으로 막혀 있습니다. 합계 유형을 얻더라도.

언급했듯이 "반환 X 및 오류" 및 "반환 X 또는 오류"가 있으므로 요청 시 이전 방식을 새로운 방식으로 변환하는 일부 매크로 없이는 이 문제를 해결할 수 없습니다.

위에서 말했듯이 "반환 X 및 오류"를 다루는 새로운 방법이 무엇이든간에 필요하지 않다고 생각합니다. 대다수의 경우가 "반환 X 또는 오류"이고 새로운 방법이 그 점만 개선한다면 훌륭하고 더 희귀한 "반환 X 및 오류"에 대해 이전 Go 1 호환 방법을 계속 사용할 수 있습니다.

@nigeltao 사실이지만 전체 표준 라이브러리를 기존 스타일로 유지하도록 제안하지 않는 한 전환하는 동안 구분할 방법이 여전히 필요합니다.

@jimmyfrasche 나는 그것에 대한 논쟁을 구성 할 수 있다고 생각하지 않습니다. 내 이야기를 보거나 repo README 에서 예제를 볼 수 있습니다. 그러나 시각적 증거가 당신에게 설득력이 없다면 내가 말할 수 있는 것이 없습니다.

@jba 는

목표가 더 나은 용어가 없기 때문에 불행한 경로를 옆으로 옮기는 것이라면 $EDITOR 플러그인은 언어 변경 없이 작동하고 코드 작성자의 기본 설정에 관계없이 모든 기존 코드에서 작동합니다.

언어를 변경하면 구문이 좀 더 간결해집니다. @bcmills 는 이것이 범위 지정을 개선 := 와 다른 범위 지정 규칙이 없으면 어떻게 할 수 있는지 실제로 알지 못하지만 더 많은 혼란을 일으킬 것 같습니다.

@bcmills 귀하의 의견을 이해할 수 없습니다. 분명히 구분할 수 있습니다. 이전 방법은 다음과 같습니다.

err := foo()
if err != nil {
  return n, err  // n can be non-zero
}

새로운 방법은 다음과 같습니다.

check foo()

또는

foo() || &FooError{err}

또는 자전거 보관소의 색상이 무엇이든 상관없습니다. 대부분의 표준 라이브러리가 전환될 수 있지만 모든 것이 전환되어야 하는 것은 아닙니다.

@ianlancetaylor 의 요구 사항에 추가하려면: 오류 메시지를 단순화하면 내용이 짧아질 뿐만 아니라 오류 처리가 더 쉬워져야 합니다. 기능을 연기하기 위해 패닉과 다운스트림 오류를 전달하는 것은 제대로 하기가 까다롭습니다.

예를 들어 오류가 발생하면 파일 쓰기를 중단하려는 Google Cloud Storage 파일에 쓰는 것을 고려하십시오.

func writeToGS(ctx context.Context, bucket, dst string, r io.Reader) (err error) {
    client, err := storage.NewClient(ctx)
    if err != nil {
        return err
    }
    defer client.Close()

    w := client.Bucket(bucket).Object(dst).NewWriter(ctx)
    defer func() {
        if r := recover(); r != nil {
            w.CloseWithError(fmt.Errorf("panic: %v", r))
            panic(r)
        }
        if err != nil {
            _ = w.CloseWithError(err)
        } else {
            err = w.Close()
        }
    }
    _, err = io.Copy(w, r)
    return err
}

이 코드의 미묘함은 다음과 같습니다.

• Copy의 오류는 명명된 반환 인수를 통해 defer 함수에 몰래 전달됩니다.
• 완전히 안전하기 위해 우리는 r에서 패닉을 포착하고 패닉을 재개하기 전에 쓰기를 중단했는지 확인합니다.
• 첫 번째 닫기의 오류를 무시하는 것은 의도적이지만 약간 게으른 프로그래머 인공물처럼 보입니다.

패키지 errd를 사용하면 이 코드는 다음과 같습니다.

func writeToGS(ctx context.Context, bucket, dst, src string, r io.Reader) error {
    return errd.Run(func(e *errd.E) {
        client, err := storage.NewClient(ctx)
        e.Must(err)
        e.Defer(client.Close, errd.Discard)

        w := client.Bucket(bucket).Object(dst).NewWriter(ctx)
        e.Defer(w.CloseWithError)

        _, err = io.Copy(w, r)
        e.Must(err)
    })
}

errd.Discard 는 오류 처리기입니다. 오류 처리기를 사용하여 모든 오류를 래핑, 기록할 수도 있습니다.

e.Must 는 foo() || wrapError

e.Defer 는 추가이며 지연에 오류를 전달하는 것을 처리합니다.

제네릭을 사용하면 이 코드는 다음과 같이 보일 수 있습니다.

func writeToGS(ctx context.Context, bucket, dst, src string, r io.Reader) error {
    return errd.Run(func(e *errd.E) {
        client := e.Must(storage.NewClient(ctx))
        e.Defer(client.Close, errd.Discard)

        w := client.Bucket(bucket).Object(dst).NewWriter(ctx)
        e.Defer(w.CloseWithError)

        _ = e.Must(io.Copy(w, r))
    })
}

Defer에 사용할 메서드를 표준화하면 다음과 같이 보일 수도 있습니다.

func writeToGS(ctx context.Context, bucket, dst, src string, r io.Reader) error {
    return errd.Run(func(e *errd.E) {
        client := e.DeferClose(e.Must(storage.NewClient(ctx)), errd.Discard)
       e.Must(io.Copy(e.DeferClose(client.Bucket(bucket).Object(dst).NewWriter(ctx)), r)
    })
}

DeferClose는 Close 또는 CloseWithError를 선택합니다. 이것이 더 낫다는 것이 아니라 가능성을 보여주는 것뿐입니다.

어쨌든, 나는 지난 주에 암스테르담 밋업에서 이 주제에 대해 프레젠테이션을 했고 오류 처리를 올바르게 하는 것을 더 쉽게 만드는 기능이 더 짧게 만드는 것보다 더 유용하다고 생각되는 것 같았습니다.

오류를 개선하는 솔루션은 적어도 일을 더 짧게 만드는 것보다 올바른 일을 더 쉽게 하는 데 중점을 두어야 합니다.

@ALTree errd는 "정교한 오류 복구"를 즉시 처리합니다.

@jimmyfrasche : errd는 플레이그라운드 예제가 하는 일을 대략적으로 수행하지만 지연을 위해 오류와 패닉을 전달하기도 합니다.

@jimmyfrasche : 대부분의 제안이 코드에서 이미 달성할 수 있는 것에 많은 것을 추가하지 않는다는 데 동의합니다.

@romainmenke : 간결함에 너무 많은 초점을 맞추고 있다는 데 동의합니다. 일을 더 쉽게 올바르게 하려면 더 큰 초점을 두어야 합니다.

@jba : errd 접근 방식을 사용하면 왼쪽을 보면 오류가 아닌 흐름 대 비 오류 흐름을 매우 쉽게 스캔할 수 있습니다(e.로 시작하는 모든 것은 오류 또는 처리 연기임). 또한 어떤 반환 값이 오류 또는 지연에 대해 처리되고 어느 것이 처리되지 않는지를 매우 쉽게 스캔할 수 있습니다.

@bcmills : errd는 자체적으로 범위 지정 문제를 해결하지 않지만 이전에 선언된 오류 변수 및 모든 것에 다운스트림 오류를 전달할 필요가 없으므로 오류 처리 AFAICT에 대한 문제를 상당히 완화합니다.

errd는 패닉과 회복에 전적으로 의존하는 것 같습니다. 상당한 성능 저하가 수반되는 것처럼 들립니다. 이것 때문에 전반적인 솔루션인지 확신할 수 없습니다.

@urandom : 내부적으로는 더 비용이 많이 들지만 단일 연기로 구현됩니다.
원래 코드인 경우:

• 지연을 사용하지 않음: errd를 사용하는 데 따른 패널티는 약 100ns*로 큽니다.
• 관용적 지연 사용: 실행 시간 또는 오류는 다소 느리지만 동일한 순서입니다.
• 지연에 대해 적절한 오류 처리를 사용합니다. 실행 시간은 거의 같습니다. 지연 수가 > 1이면 errd가 더 빠를 수 있습니다.

기타 간접비:

• Defer에 클로저(w.Close)를 전달하면 현재 DeferClose 또는 DeferFunc API를 사용하는 것과 비교하여 약 25ns* 오버헤드가 추가됩니다(릴리스 v0.1.0 참조). @rsc 와
• 인라인 오류 문자열을 핸들러( e.Must(err, msg("oh noes!") )로 래핑하는 데 Go 1.8에서 약 30ns가 소요됩니다. 그러나 팁(1.9)을 사용하면 여전히 할당되지만 2ns에서 비용을 기록했습니다. 물론 미리 선언된 오류 메시지의 경우 비용은 여전히 ​​무시할 수 있습니다.

(*) 내 2016 MacBook Pro에서 실행되는 모든 숫자.

대체로 원래 코드가 defer를 사용하는 경우 비용이 허용되는 것으로 보입니다. 그렇지 않은 경우 Austin은 연기 비용을 크게 줄이기 위해 노력하고 있으므로 시간이 지남에 따라 비용이 줄어들 수도 있습니다.

어쨌든,이 패키지의 요점은 우리가 포인트로 이동 2. 사례에서 최고의 언어 추가를 구축 할 수 있도록 느낌과 지금은 유용 할 것이다 다른 오류 처리를 사용하는 방법에 대한 경험을 얻을 수입니다 현재의 논의는, 그것은을 감소에 너무 많이 집중한다 간단한 경우에는 몇 줄의 줄이 필요하지만 얻을 수 있는 것이 훨씬 더 많으며 틀림없이 다른 점이 더 중요합니다.

@jimmyfrasche :

그러면 $EDITOR 플러그인은 언어 변경 없이 작동합니다.

예, 그것이 제가 대화에서 주장하는 바입니다. 여기에 우리가 언어 변경을 할 경우, 그것은 "(!) 참고"개념에 있던해야한다고 주장하고있다.

@nigeltao

분명히 구분할 수 있습니다. 이전 방법은 다음과 같습니다.

나는 사용 지점이 아니라 선언 지점에 대해 이야기하고 있습니다.

여기에서 논의된 제안 중 일부는 호출 사이트에서 둘을 구별하지 않지만 일부는 구별합니다. || , try … catch 또는 match 와 같이 "값 또는 오류"를 가정하는 옵션 중 하나를 선택하면 사용할 컴파일 타임 오류여야 합니다. "값 및 오류" 기능이 있는 해당 구문이 무엇인지 정의하는 것은 해당 기능의 구현자에게 달려 있습니다.

선언 시점에서 현재 "값과 오류"와 "값 또는 오류"를 구별할 수 있는 방법은 없습니다.

func Atoi(string) (int, error)

그리고

func WriteString(Writer, String) (int, error)

반환 유형은 같지만 오류 의미는 다릅니다.

@mpvl 나는

WithDefault()의 결과에 대한 작업을 위한 최상위 함수와 같은 일반적인 도우미를 무시하고 단순성을 위해 항상 컨텍스트를 사용하고 성능에 대한 결정을 무시한다고 가정하면 절대 최소 베어본 API가 다음으로 축소됩니다. 아래 작업?

type Handler = func(ctx context.Context, panicing bool, err error) error
Run(context.Context, func(*E), defaults ...Handler) //egregious style but most minimal
type struct E {...}
func (*E) Must(err error, handlers ...Handler)
func (*E) Defer(func() error, handlers ...Handler)

코드를 보면 위와 같이 정의되지 않은 몇 가지 좋은 이유를 알 수 있지만 개념을 더 잘 이해하기 위해 핵심 의미를 파악하려고 합니다. 예를 들어 IsSentinel 이 코어에 있는지 여부는 확실하지 않습니다.

@jimmyfrasche

@bcmills 는 이것이 범위 지정을 개선

주요 개선 사항은 err 변수를 범위 밖으로 유지하는 것입니다. 그러면 https://github.com/golang/go/issues/19727 에서 링크된 것과 같은 버그를 피할 수

    res, err := ctxhttp.Get(ctx, c.HTTPClient, dirURL)
    if err != nil {
        return Directory{}, err
    }
    defer res.Body.Close()
    c.addNonce(res.Header)
    if res.StatusCode != http.StatusOK {
        return Directory{}, responseError(res)
    }

    var v struct {
        …
    }
    if json.NewDecoder(res.Body).Decode(&v); err != nil {
        return Directory{}, err
    }

버그는 마지막 if 문에서 발생합니다. Decode 의 오류가 삭제되었지만 이전 검사의 err 가 여전히 범위 내에 있기 때문에 명확하지 않습니다. 대조적으로 :: 또는 =? 연산자를 사용하면 다음과 같이 작성됩니다.

    res := ctxhttp.Get(ctx, c.HTTPClient, dirURL) =? err { return Directory{}, err }
    defer res.Body.Close()
    c.addNonce(res.Header)
    (res.StatusCode == http.StatusOK) =! { return Directory{}, responseError(res) }

    var v struct {
        …
    }
    json.NewDecoder(res.Body).Decode(&v) =? err { return Directory{}, err }

여기에 도움이 되는 두 가지 범위 지정 개선 사항이 있습니다.

1. 첫 번째 err (이전 Get 호출에서)는 return 블록의 범위에만 있으므로 후속 검사에서 실수로 사용할 수 없습니다.
2. err from Decode 는 nilness가 검사되는 동일한 문에서 선언되기 때문에 선언과 검사 사이에 왜곡이 있을 수 없습니다.

(1)만으로도 컴파일 타임에 오류를 드러내기에 충분했지만 (2) 명백한 방식으로 가드 문을 사용할 때 쉽게 피할 수 있습니다.

@bcmills 설명 감사합니다

따라서 res := ctxhttp.Get(ctx, c.HTTPClient, dirURL) =? err { return Directory{}, err } 에서 =? 매크로는

var res *http.Reponse
{
  var err error
  res, err = ctxhttp.Get(ctx, c.HTTPClient, dirURL)
  if err != nil {
    return Directory{}, err 
  }
}

그것이 맞다면 := 와 다른 의미를 가져야 한다고 말했을 때 의미했던 것입니다.

다음과 같은 자체 혼란을 일으킬 것 같습니다.

func f() error {
  var err error
  g() =? err {
    if err != io.EOF {
      return err
    }
  }
  //one could expect that err could be io.EOF here but it will never be so
}

내가 뭔가를 잘못 이해하지 않는 한.

네, 정확한 확장입니다. := 와 다르다는 것이 옳습니다. 이는 의도된 것입니다.

나름대로 혼선을 빚을 것 같다.

그건 사실이야. 그것이 실제로 혼란스러울지 여부는 나에게 분명하지 않습니다. 그렇다면 선언을 위해 보호 문의 ":" 변형을 제공할 수 있습니다(및 "=" 변형만 할당).

(그리고 이제는 연산자를 =? 및 =! 대신 ? 및 ! 로 써야 한다고 생각합니다.)

res := ctxhttp.Get(ctx, c.HTTPClient, dirURL) ?: err { return Directory{}, err }

하지만

func f() error {
  var err error
  g() ?= err { (err == io.EOF) ! { return err } }
  // err may be io.EOF here.
}

@mpvl errd 에 대한 나의 주요 관심사는 Handler 인터페이스입니다. 콜백의 기능적 스타일 파이프라인을 권장하는 것처럼 보이지만 콜백/연속 스타일 코드에 대한 제 경험(Go 및 C++과 같은 명령형 언어 및 기능적 ML 및 Haskell과 같은 언어)는 Go 관용구의 나머지 부분과도 일치하는 동일한 순차/명령형 스타일보다 따르기가 훨씬 더 어렵다는 것입니다.

Handler -스타일 체인을 API의 일부로 구상하고 있습니까, 아니면 Handler 를 고려 중인 다른 구문(예: Block 에스?)

@bcmills 저는 여전히 한 줄에 수십 가지 개념을 언어에 도입하고 한 가지 작업으로만 작동하는 마법의 기능을 사용하지 않지만 마침내 x, err := f(); if err != nil { return err } 를 작성하는 약간 더 짧은 방법 이상인 이유를 알게 되었습니다.

@bcmills 항상 새로운 err 변수를 선언하지 않는 최신 =? 제안을 사용하여 약간의 오류 처리가 있는 @mpvl 의 동기 부여 예제를 다시 작성

func writeToGS(ctx context.Context, bucket, dst string, r io.Reader) (err error) {
        client := storage.NewClient(ctx) =? err { return err }
        defer client.Close()

        w := client.Bucket(bucket).Object(dst).NewWriter(ctx)

        defer func() {
                if r := recover(); r != nil { // r is interface{} not error so we can't use it here
                        _ = w.CloseWithError(fmt.Errorf("panic: %v", r))
                        panic(r)
                }

                if err != nil { // could use =! here but I don't see how that simplifies anything
                        _ = w.CloseWithError(err)
                } else {
                        err = w.Close()
                }
        }()

        io.Copy(w, r) =? err { return err } // what about n? does this need to be prefixed by a '_ ='?
        return nil
}

대부분의 오류 처리는 변경되지 않습니다. =? 는 두 곳에서만 사용할 수 있습니다. 처음에는 실제로 내가 볼 수 있는 어떤 이점도 제공하지 않았습니다. 두 번째에서는 코드를 더 길게 만들고 io.Copy 가 두 가지를 반환한다는 사실을 흐리게 하므로 거기에서 사용하지 않는 것이 더 나았을 것입니다.

@jimmyfrasche 그 코드는 규칙이 아니라 예외입니다. 우리는 더 쉽게 작성할 수 있도록 기능을 설계해서는 안 됩니다.

또한 recover 가 있어야 하는지도 의문입니다. w.Write 또는 r.Read (또는 io.Copy !)가 패닉 상태이면 종료하는 것이 가장 좋습니다.

recover 가 없으면 defer 가 실제로 필요하지 않으며 함수의 맨 아래가 다음과 같이 될 수 있습니다.

_ = io.Copy(w, r) =? err { _ = w.CloseWithError(err); return err }
return w.Close()

@jimmyfrasche

// r is interface{} not error so we can't use it here

내 특정 문구(https://github.com/golang/go/issues/21161#issuecomment-319434101)는 특별히 오류가 아니라 0 값에 관한 것입니다.

// what about n? does this need to be prefixed by a '_ ='?

내가 그것에 대해 더 명확하게 말할 수 있었지만 그렇지 않습니다.

나는 그 예에서 @mpvl 의 recover 사용을 특히 좋아하지 않습니다. 관용적 제어 흐름에 대한 패닉의 사용을 권장하는 반면, 제 생각에는 불필요한 recover 호출을 제거해야 한다고 생각합니다( Go 2의 표준 라이브러리에서 fmt 에 있는 것과 같은 것입니다.

그 접근 방식을 사용하면 해당 코드를 다음과 같이 작성합니다.

func writeToGS(ctx context.Context, bucket, dst string, r io.Reader) (err error) {
        client := storage.NewClient(ctx) =? err { return err }
        defer client.Close()

        w := client.Bucket(bucket).Object(dst).NewWriter(ctx)
        io.Copy(w, r) =? err {
                w.CloseWithError(err)
                return err
        }
        return w.Close()
}

반면에, 단관적 복구를 사용하면 관용적 오류 처리를 지원하기 위한 기능을 적용할 기회가 거의 없다는 것이 맞습니다. 그러나 Close 작업에서 복구를 분리하면 IMO에서 코드가 다소 깔끔해집니다.

func writeToGS(ctx context.Context, bucket, dst string, r io.Reader) (err error) {
        client := storage.NewClient(ctx) =? err { return err }
        defer client.Close()

        w := client.Bucket(bucket).Object(dst).NewWriter(ctx)
        defer func() {
                if err != nil {
                        _ = w.CloseWithError(err)
                } else {
                        err = w.Close()
                }
        }()
        defer func() {
                recover() =? r {
                        err = fmt.Errorf("panic: %v", r)
                        panic(r)
                }
        }()

        io.Copy(w, r) =? err { return err }
        return nil
}

@jba 지연 처리기는 다시 패닉: 다른 컴퓨터의 프로세스에 알리려고 시도하여 실수로 잘못된 트랜잭션을 커밋하지 않도록 합니다(잠재적인 오류 상태에서 여전히 가능하다고 가정). 그것이 꽤 일반적이지 않다면 아마도 그래야 할 것입니다. Read/Write/Copy가 당황하지 않아야 한다는 데 동의하지만 그 안에 합리적으로 당황할 수 있는 다른 코드가 있다면 어떤 이유에서든 처음 시작했던 곳으로 바로 돌아갈 수 있습니다.

@bcmills 그 마지막 개정판이 더 좋아 보입니다 ( =? 빼도 정말)

@jba :

_ = io.Copy(w, r) =? err { _ = w.CloseWithError(err); return err }
return w.Close()

그것은 여전히 ​​독자의 공황의 경우를 다루지 않습니다. 분명히 이것은 드문 경우이지만 매우 중요한 경우입니다. 패닉이 발생한 경우 여기에서 Close를 호출하는 것은 매우 나쁩니다.

그 코드는 규칙이 아니라 예외입니다. 우리는 더 쉽게 작성할 수 있도록 기능을 설계해서는 안 됩니다.

@jba : 저는 이 경우에 전적으로 동의하지 않습니다. 오류 처리를 올바르게 하는 것이 중요합니다. 간단한 경우를 더 쉽게 허용하면 사람들이 적절한 오류 처리에 대해 생각하지 않게 됩니다. errd 와 같이 보수적인 오류 처리를 사소하게 쉽게 만드는 접근 방식을 보고 싶습니다. 반면에 규칙을 완화하기 위해 약간의 노력이 필요합니다. 다른 방향으로 조금이라도 움직이지 않아야 합니다.

@jimmyfrasche : 귀하의 단순화와 관련하여 : 귀하가 대략 맞습니다.

• IsSentinel은 필수가 아니라 편리하고 일반적입니다. 나는 그것을 떨어뜨렸다, 적어도 지금은.
• Err in State는 err과 다르므로 API가 이를 삭제합니다. 그러나 이해에는 중요하지 않습니다.
• 핸들러는 함수일 수 있지만 대부분 성능상의 이유로 인터페이스입니다. 패키지가 최적화되지 않으면 많은 사람들이 패키지를 사용하지 않는다는 것을 알고 있습니다. (이 호의 errd에 대한 첫 번째 의견을 참조하십시오)
• 맥락이 아쉽습니다. AppEngine은 이를 필요로 하지만 그 외에는 그다지 많지 않다고 생각합니다. 사람들이 주저할 때까지 지지를 제거하는 것이 좋습니다.

@mpvl 작동 방식, 사용 방법, 내가 작성한 코드에 어떻게 맞을지 상상하기 쉽도록 몇 가지로

@jimmyfrasche : API가 그렇게 할 것을 요구하지 않는다면 좋지만 이해합니다. :)

@bcmills : 핸들러는 예를 들어 중요도에 따라 몇 가지 용도로 사용됩니다.

• 오류를 래핑
• 오류를 무시하도록 정의(명시하게 만들기 위해. 예 참조)
• 로그 오류
• 오류 메트릭

다시 중요도에 따라 다음과 같이 범위를 지정해야 합니다.

• 블록
• 라인
• 패키지

기본 오류는 오류가 어딘가에서 처리된다는 것을 쉽게 보장할 수 있도록 하기 위한 것입니다.
하지만 블록 수준으로만 살 수 있었습니다. 원래 핸들러 대신 옵션이 있는 API가 있었습니다. 그 결과 더 느리고 더 크고 서투른 API가 생성되었습니다.

나는 여기서 콜백 문제가 그렇게 나쁘다고 보지 않습니다. 사용자는 오류가 있는 경우 호출되는 핸들러를 전달하여 Runner를 정의합니다. 특정 러너는 오류가 처리되는 블록에 명시적으로 지정됩니다. 많은 경우 핸들러는 인라인으로 전달된 일부 래핑된 문자열 리터럴일 뿐입니다. 나는 유용한 것과 그렇지 않은 것을 보기 위해 약간의 플레이를 할 것입니다.

BTW, 처리기에서 로깅 오류를 권장하지 않아야 하는 경우 컨텍스트 지원이 중단될 수 있습니다.

@jba :

또한 회복이 거기에 있어야 하는지도 의문입니다. w.Write 또는 r.Read(또는 io.Copy!)가 패닉 상태인 경우 종료하는 것이 가장 좋습니다.

writeToGS는 패닉이 발생하면 종료되지만(!!!), nil이 아닌 오류와 함께 CloseWithError를 호출하는 것만 확인합니다. 패닉이 처리되지 않으면 defer가 계속 호출되지만 err == nil과 함께 결과적으로 잠재적으로 손상된 파일이 Cloud Storage에서 구체화됩니다. 여기서 해야 할 올바른 일은 일시적인 오류와 함께 CloseWithError를 호출한 다음 패닉을 계속하는 것입니다.

Go 코드에서 이와 같은 예제를 많이 찾았습니다. io.Pipes를 다루는 것은 종종 약간 너무 미묘한 코드를 초래합니다. 오류를 처리하는 것은 종종 여러분이 지금 본 것처럼 간단하지 않습니다.

@bcmills

나는 그 예에서 @mpvl 의 복구 사용을 특히 좋아하지 않습니다. 관용적 제어 흐름보다 패닉을 사용하도록 권장합니다.

공황의 사용을 조금도 장려하지 않습니다. CloseWithError 직후에 패닉이 다시 발생하므로 제어 흐름을 변경하지 않습니다. 패닉은 패닉으로 남아 있습니다.
하지만 여기에서 복구를 사용하지 않는 것은 잘못된 것입니다. 패닉이 발생하면 defer가 nil 오류와 함께 호출되어 지금까지 작성된 내용이 커밋될 수 있다는 신호가 발생하기 때문입니다.

여기에서 복구를 사용하지 않는 다소 유효한 주장은 임의의 리더(이 예에서 리더가 알 수 없는 유형인 이유가 있음 :))의 경우에도 패닉이 발생할 가능성이 매우 낮다는 것입니다.
그러나 프로덕션 코드의 경우 이는 용납할 수 없는 입장입니다. 특히 충분히 큰 규모로 프로그래밍할 때 이것은 언젠가 발생할 수밖에 없습니다(패닉은 코드의 버그 이외의 다른 것으로 인해 발생할 수 있음).

BTW, errd 패키지를 사용하면 사용자가 이에 대해 생각할 필요가 없습니다. 그러나 패닉이 발생한 경우 오류를 알리는 다른 메커니즘은 괜찮습니다. 공황 상태에서 연기를 호출하지 않는 것도 효과가 있지만 자체 문제가 있습니다.

선언 시점에서 현재 "값과 오류"와 "값 또는 오류"를 구별할 수 있는 방법은 없습니다.

@bcmills 아,

func Atoi(string) ?int

대신에

func Atoi(string) (int, error)

그러나 WriteString은 변경되지 않은 상태로 유지됩니다.

func WriteString(Writer, String) (int, error)

비슷한 제안보다 @bcmills / @jba 의 =? / =! / :=? / :=! 제안이 더 좋습니다. 몇 가지 좋은 속성이 있습니다.

• 작성 가능 (당신이 사용할 수있는 =? 내에서 =? 블록)
• 일반(오류 유형에 국한되지 않고 0 값에만 관심)
• 향상된 범위
• defer와 함께 작동할 수 있습니다(위의 한 변형에서).

그것은 또한 내가 멋지다고 생각하지 않는 몇 가지 속성을 가지고 있습니다.

컴포지션 둥지. 반복 사용은 계속해서 오른쪽으로 갈수록 들여쓰기가 됩니다. 그것이 반드시 그 자체로 나쁜 것은 아니지만, 오류를 일으키는 오류를 처리해야 하는 매우 복잡한 오류 처리가 있는 상황에서는 처리할 코드가 현재 상태보다 훨씬 덜 명확해질 것이라고 상상합니다. 이러한 상황 하나에서 사용할 수있는 =? 바깥 쪽 오류 및 if err != nil 내부 오류에를하지만 일반적으로하거나 일반적인 경우에 취급이 정말 향상 오류가? 일반적인 경우를 개선하는 것이 필요한 전부일 수도 있지만 개인적으로는 그다지 매력적이지 않습니다.

그것은 보편성을 얻기 위해 언어에 거짓을 도입합니다. 거짓을 "0 값이 아님"으로 정의하는 것은 완전히 합리적이지만 if err != nil { 가 명시적이기 때문에 if err { 보다 낫다고 생각합니다. 나는 =? /etc를 사용하려고 하는 비틀림을 야생에서 볼 것으로 예상합니다. 더 자연스러운 제어 흐름을 통해 거짓에 액세스하려고 시도합니다. 그것은 확실히 일방적이고 눈살을 찌푸리게 할 것이지만 그것은 일어날 것입니다. 기능의 잠재적 남용은 그 자체로 기능에 대한 논쟁이 아니지만 고려해야 할 사항입니다.

개선된 범위 지정(해당 매개변수를 선언하는 변형의 경우)은 경우에 따라 좋지만 범위 지정을 수정해야 하는 경우 일반적으로 범위 지정을 수정합니다.

"가장 오른쪽에 있는 유일한 결과" 의미 체계는 이해가 되지만 나에게는 조금 이상해 보입니다. 그것은 논쟁보다 감정입니다.

이 제안은 언어에 간결함을 더하지만 추가적인 힘은 없습니다. 매크로 확장을 수행하는 전처리기로 완전히 구현될 수 있습니다. 그것은 물론 바람직하지 않습니다. 빌드와 조각 개발을 복잡하게 만들고 그러한 전처리기는 유형을 인식하고 위생적이어야 하기 때문에 극도로 복잡할 것입니다. 나는 "그냥 전처리기를 만드십시오"라고 말함으로써 무시하려는 것이 아닙니다. 나는 이 제안이 전적으로 설탕이라는 점을 지적하기 위해 이것을 제기합니다. 지금 바둑에서 할 수 없었던 일을 할 수 없습니다. 더 간결하게 작성할 수 있습니다. 나는 설탕에 독단적으로 반대하지 않습니다. 신중하게 선택한 언어적 추상화에는 힘이 있지만 그것이 설탕이라는 사실은 말하자면 무죄가 입증될 때까지 👎 고려되어야 함을 의미합니다.

연산자의 lhs는 명령문이지만 명령문의 매우 제한된 하위 집합입니다. 해당 하위 집합에 포함할 요소는 상당히 자명하지만 다른 것이 없다면 변경 사항을 수용하기 위해 언어 사양의 문법을 리팩토링해야 합니다.

뭔가 좋아할까

func F() (S, T, error)

func MustF() (S, T) {
  return F() =? err { panic(err) }
}

허용되다?

만약에

defer f.Close() :=? err {
    return err
}

(어느 정도) 와 동등해야 하는 것이 허용됩니다.

func theOuterFunc() (err error) {
  //...
  defer func() {
    if err2 := f.Close(); err2 != nil {
      err = err2
    }
  }()
  //...
}

이는 매우 문제가 있고 매우 혼란스러운 상황을 유발할 가능성이 있으며, 매우 비정상적으로 클로저를 암시적으로 할당하는 성능 영향을 숨긴다는 사실을 무시합니다. 대안은 것입니다 return 암시 적 폐쇄에서 수익을 한 다음 유형의 값을 반환 할 수 없다는 오류 메시지가 error A로부터 func() 있는 약간입니다 무딘.

사실, 약간 개선된 범위 수정을 제외하고는 Go에서 오류를 처리하는 데 직면한 문제를 해결하지 못합니다. 기껏해야 if err != nil { return err } 를 입력하는 것은 성가신 일이며, #21182에서 표현한 약간의 가독성 문제를 모듈화합니다. 두 가지 가장 큰 문제는

1. 오류를 처리하는 방법에 대해 생각하고 있으며 이에 대해 언어가 할 수 있는 일은 없습니다.
2. 어떤 상황에서 무엇을 해야 할지 결정하기 위해 오류를 검사하는 것 - errors 패키지의 지원과 함께 일부 추가 규칙은 여기에서 먼 길을 갈 수 있지만 모든 문제를 해결할 수는 없습니다.

나는 그것이 유일한 문제가 아니며 많은 사람들이 다른 측면을 더 즉각적으로 우려한다는 것을 알고 있지만, 그것들은 내가 가장 많은 시간을 보내고 다른 어떤 것보다 더 성가시고 골칫거리인 것입니다.

내가 무언가를 망쳤을 때 감지하는 더 나은 정적 분석은 물론 (그리고 일반적으로 이 시나리오뿐만 아니라) 항상 감사할 것입니다. 소스를 더 쉽게 분석할 수 있도록 하는 언어 변경 및 규칙도 흥미로울 것입니다.

방금 이것에 대해 많은 글을 썼지만(정말 많이! 죄송합니다!) 그 제안을 기각하지는 않습니다. 나는 그것이 장점이 있다고 생각하지만 그것이 막대를 제거하거나 무게를 끌어당기는지 확신하지 못합니다.

@jimmyfrasche

:=의 현재 동작이 도입되었을 때를 기억합니다. 많은 스레드가 암시적인 "변수가 정확히 현재 범위에 있는 경우에만 재사용" 대신 재사용할 이름에 명시적으로 주석을 달기 위한 방법을 요구했습니다. " 내 경험상 보기 힘든 모든 미묘한 문제가 나타나는 곳입니다.

† 링크가 있는 스레드를 찾을 수 없습니까?

Go가 출시되었을 때 Go에 참여하지 않았다면 다른 스레드를 기억하고 계실 것입니다. 출시 직전인 2009/11/9의 사양은 다음과 같습니다.

일반 변수 선언과 달리 짧은 변수 선언은 변수가 원래 동일한 유형의 동일한 블록에서 선언되었고 공백이 아닌 변수 중 하나 이상이 새로운 경우 변수를 다시 선언할 수 있습니다.

나는 처음으로 사양을 읽었을 때 그것이 훌륭한 규칙이라고 생각했던 것을 기억합니다. 이전에 :=가 있는 언어를 사용했지만 그 재사용 규칙 없이 동일한 것에 대한 새 이름을 생각하는 것은 지루했습니다.

@mpvl
나는 당신의 원래 예의 까다로움이 더 많은 결과라고 생각합니다.
Go의 오류 처리 자체보다 거기에서 사용하는 API.

특히 흥미로운 예입니다.
패닉이 발생하면 파일을 정상적으로 닫고 싶지 않으므로
정상적인 "defer w.Close()" 관용구가 작동하지 않습니다.

다음이 있을 때 Close 호출을 피할 필요가 없다면
공황 상태에서 다음을 수행할 수 있습니다.

func writeToGS(ctx context.Context, bucket, dst string, r io.Reader) (err error) {
    client, err := storage.NewClient(ctx)
    if err != nil {
        return err
    }
    defer client.Close()

    w := client.Bucket(bucket).Object(dst).NewWriter(ctx)
    defer w.Close()
    _, err = io.Copy(w, r)
    if err != nil {
        w.CloseWithError(err)
    }
    return err
}

Close를 호출하도록 의미가 변경되었다고 가정합니다.
CloseWithError를 호출한 후에는 작동하지 않습니다.

더 이상 그렇게 나쁘게 보이지 않는 것 같아요.

패닉이 있을 때 파일이 오류 없이 작성되지 않는다는 요구 사항이 있더라도 수용하기에는 너무 어렵지 않아야 합니다. 예를 들어 Close 전에 명시적으로 호출해야 하는 Finalize 함수를 추가합니다.

    w := client.Bucket(bucket).Object(dst).NewWriter(ctx)
    defer w.Close()
    _, err = io.Copy(w, r)
    return w.Finalize(err)

하지만 패닉 오류 메시지를 첨부할 수는 없지만 적절한 로깅을 통해 이를 더 명확하게 만들 수 있습니다.
(Close 메서드는 내부에 복구 호출이 있을 수도 있지만 그게 맞는지는 확실하지 않습니다.
사실 정말 나쁜 생각입니다...)

그러나 오류 처리의 99% 이상의 경우가 패닉 복구를 수행하지 않기 때문에 이 예의 패닉 복구 측면은 이 컨텍스트에서 다소 적청이라고 생각합니다.

@rogpeppe :

하지만 패닉 오류 메시지를 첨부할 수는 없지만 적절한 로깅을 통해 이를 더 명확하게 만들 수 있습니다.

나는 그것이 문제라고 생각하지 않는다.

제안된 API 변경은 완화되지만 아직 문제를 완전히 해결하지는 못합니다. 필요한 의미 체계를 사용하려면 다른 코드도 제대로 작동해야 합니다. 아래 예를 고려하십시오.

r, w := io.Pipe()
go func() {
    var err error                // used to intercept downstream errors
    defer func() {
        w.CloseWithError(err)
    }()

    r, err := newReader()
    if err != nil {
        return
    }
    defer func() {
        if errC := r.Close(); errC != nil && err == nil {
            err = errC
        }
    }
    _, err = io.Copy(w, r)
}()
return r

그 자체로 이 코드는 오류 처리가 까다롭거나 적어도 지저분하다는 것을 보여줍니다(그리고 다른 제안으로 이것이 어떻게 개선될 수 있는지 궁금합니다): 이 코드는 다운스트림 오류를 변수를 통해 은밀하게 전달하며 약간의 오류가 있습니다. clunky if 문을 사용하여 올바른 오류가 전달되었는지 확인합니다. 둘 다 "비즈니스 논리"에서 너무 많은 주의를 산만하게 합니다. 오류 처리가 코드를 지배합니다. 그리고 이 예제는 아직 패닉을 처리하지도 않습니다.

완전성을 위해 errd 이것은 _공황을 올바르게 처리하고 다음과 같이 보일 것입니다.

r, w := io.Pipe()
go errd.Run(func(e *errd.E) {
    e.Defer(w.CloseWithError)

    r, err := newReader()
    e.Must(err)
    e.Defer(r.Close)

    _, err = io.Copy(w, r)
    e.Must(err)
})
return r

위의 판독기( errd 사용하지 않음)가 판독기로 writeToGS에 전달되고 newReader에서 반환된 io.Reader 패닉이 발생하면 제안된 API 수정과 함께 여전히 잘못된 의미 체계가 발생합니다(성공적으로 닫을 수 있습니다. nil 오류와 함께 패닉 시 파이프가 닫힌 후 GS 파일.)

이것은 또한 요점을 증명합니다. Go에서 적절한 오류 처리에 대해 추론하는 것은 간단하지 않습니다. errd 하여 코드를 다시 작성하는 방법을 살펴보니 버그가 많은 코드를 발견했습니다. 그러나 errd 패키지에 대한 단위 테스트를 작성할 때 적절한 관용적 Go 오류 처리를 작성하는 것이 얼마나 어렵고 미묘한 것인지 배웠습니다. :)

제안된 API 변경에 대한 대안은 패닉 시 지연을 전혀 처리하지 않는 것입니다. 이것은 고유한 문제가 있고 문제를 완전히 해결하지 못하고 아마도 실행 취소할 수 있지만 몇 가지 좋은 특성이 있습니다.

어느 쪽이든, 간결함에 초점을 맞추는 것보다 오류 처리의 미묘함을 완화하는 언어 변경이 가장 좋습니다.

@mpvl
나는 종종 Go의 오류 처리 코드에서 다른 함수를 생성하면 정리할 수 있다는 것을 알게 됩니다. 위의 코드를 다음과 같이 작성합니다.

func something() {
    r, w := io.Pipe()
    go func() {
        err := copyFromNewReader(w)
        w.CloseWithError(err)
    }()
    ...
}

func copyFromNewReader(w io.Writer) error {
    r, err := newReader()
    if err != nil {
        return err
    }
    defer r.Close()
    _, err = io.Copy(w, r)
    return err
}()

r.Close가 유용한 오류를 반환하지 않는다고 가정합니다. 독자를 끝까지 읽었고 io.EOF만 발견했다면 닫힐 때 오류를 반환하더라도 거의 확실하게 문제가 되지 않습니다.

나는 errd API에 관심이 없습니다. 시작되는 고루틴에 너무 민감합니다. 예: https://play.golang.org/p/iT441gO5us doSomething이 고루틴을 실행하여 실행하는지 여부
함수 입력은 프로그램의 정확성에 영향을 미치지 않아야 하지만 errd를 사용할 때는 영향을 미칩니다. 추상화 경계를 안전하게 가로지르는 패닉을 예상하고 있지만 Go에서는 그렇지 않습니다.

@mpvl

w.CloseWithError(err) 연기

BTW, 이 줄은 항상 nil 오류 값으로 CloseWithError를 호출합니다. 나는 당신이 의도 한 것 같아요
쓰다:

defer func() { 
   w.CloseWithError(err)
}()

@mpvl

io.Reader 에 대해 Close 메서드에서 반환된 오류는 거의 유용하지 않습니다(https://github.com/golang/go/issues/20803#issuecomment-312318808의 목록 참조). ).

그것은 우리가 오늘 당신의 예를 다음과 같이 작성해야 함을 시사합니다.

r, w := io.Pipe()
go func() (err error) {
    defer func() { w.CloseWithError(err) }()

    r, err := newReader()
    if err != nil {
        return err
    }
    defer r.Close()

    _, err = io.Copy(w, r)
    return err
}()
return r

...조금 장황한 것을 제외하고는 완벽하게 괜찮아 보입니다.

패닉의 경우 w.CloseWithError 에 nil 오류를 전달하는 것이 사실이지만 어쨌든 전체 프로그램은 그 지점에서 종료됩니다. nil 오류로 닫지 않는 것이 중요하다면 간단한 이름 바꾸기에 한 줄을 추가하면 됩니다.

-go func() (err error) {
-   defer func() { w.CloseWithError(err) }()
+go func() (rerr error) {
+   rerr = errors.New("goroutine exited by panic")
+   defer func() { w.CloseWithError(rerr) }()

@rogpeppe : 정말 감사합니다. :)

예, 고루틴 문제를 알고 있습니다. 그것은 불쾌하지만 아마도 수의사 검사로 잡기가 어렵지 않은 것입니다. 어쨌든 저는 errd를 최종 솔루션으로 보지 않고 오류 처리를 가장 잘 처리하는 방법에 대한 경험을 얻는 방법으로 봅니다. 이상적으로는 동일한 문제를 해결하지만 적절한 제한이 부과되는 언어 변경이 있을 것입니다.

추상화 경계를 안전하게 가로지르는 패닉을 예상하고 있지만 Go에서는 그렇지 않습니다.

그것은 내가 기대하는 것이 아닙니다. 이 경우 API가 성공을 보고하지 않았을 때 보고하지 않을 것으로 예상합니다. 마지막 코드 조각은 작성자에 대해 defer를 사용하지 않기 때문에 올바르게 처리합니다. 그러나 이것은 매우 미묘합니다. 많은 사용자는 관용적인 것으로 간주되기 때문에 이 경우 defer를 사용합니다.

일련의 수의사 검사로 문제가 있는 연기 사용을 포착할 수 있습니다. 그래도 원래의 "관용적" 코드와 마지막으로 리팩토링된 코드에는 매우 간단한 코드 조각에 대한 오류 처리의 미묘함을 해결하기 위해 많은 수정 작업이 있습니다. 해결 방법 코드는 특정 오류 사례를 처리하는 방법을 알아내기 위한 것이 아니라 생산적인 용도로 사용할 수 있는 순전히 두뇌 순환의 낭비입니다.

특히 errd 에서 배우려고 하는 것은 직접 사용할 때 오류 처리를 더 간단하게 만드는지 여부입니다. 내가 볼 수있는 것에서 많은 합병증과 미묘함이 사라집니다. 의미론의 측면을 새로운 언어 기능으로 체계화할 수 있는지 확인하는 것이 좋습니다.

@jimmyfrasche

그것은 보편성을 얻기 위해 언어에 거짓을 도입합니다.

아주 좋은 지적입니다. 거짓과 관련된 일반적인 문제는 부울 함수를 호출하는 것을 잊거나 nil에 대한 포인터를 역참조하는 것을 잊는 데서 발생합니다.

(낙하 아마 우리는 nillable로 유형 만 작업에 연산자를 정의하여 후자를 해결할 수 =! 가 대부분 쓸모가있을 것이기 때문에, 결과적으로).

함수 유형과 함께 작동하지 않거나 포인터 또는 인터페이스 유형에서만 작동하도록 전자를 추가로 제한하여 전자를 해결할 수 있습니다. 그러면 변수가 부울이 아니라는 것이 분명하고 부울 비교에 사용하려는 시도가 더 많을 것입니다. 분명히 잘못되었습니다.

[ MustF ] 같은 것이 허용됩니까?

예.

[ defer f.Close() :=? err { ]가 허용되면 (어느 정도) 다음과 같아야 합니다.
[ defer func() { … }() ].

반드시 그렇지는 않습니다. 고유한 의미를 가질 수 있습니다(익명 함수보다 call/cc 와 비슷함). 내가 사용하기위한 사양 변경을 제안하지 않은 =? 에서 defer 확실 정확히 같은 정의가 될 복잡한 방법이 아니에요, 그래서 (이것은 문법 적어도 변화를 요구한다) .

두 가지 가장 큰 문제는 […]

나는 그것이 실제로 더 큰 문제라는 데 동의하지만 이 문제와 다소 직교하는 것처럼 보입니다(이는 상용구 및 관련 오류 가능성을 줄이는 것에 관한 것입니다).

( @rogpeppe , @davecheney , @dsnet , @crawshaw , 저, 그리고 제가 분명히 잊고 있는 몇몇 다른 사람들은 GopherCon에서 오류 검사를 위한 API에 대해 좋은 토론을 했습니다. 그리고 우리도 그 측면에서 좋은 제안을 볼 수 있기를 바랍니다. , 그러나 나는 정말로 다른 문제에 대한 문제라고 생각합니다.)

@bcmills : 이 코드에는 1) @rogpeppe가 언급한 것과 같은 두 가지 문제가 있습니다. CloseWithError에 전달된 err은 항상 nil이고 2) 여전히 패닉을 처리하지 않으므로 패닉이 있을 때 API가 명시적으로 성공을 보고합니다. 반환된 r은 1이 고정된 경우에도 모든 바이트가 기록되지 않은 경우에도 io.EOF를 방출할 수 있습니다.

그렇지 않으면 Close에서 반환된 오류가 종종 무시될 수 있다는 데 동의합니다. 그러나 항상 그런 것은 아닙니다(첫 번째 예 참조).

제 다소 간단한 예(나 자신의 것 포함)에 4~5개의 잘못된 제안이 있었다는 것이 다소 놀랍고 여전히 Go의 오류 처리가 사소하지 않다고 주장해야 하는 것 같습니다. :)

@bcmills :

패닉의 경우 w.CloseWithError에 nil 오류를 전달하는 것이 사실이지만 전체 프로그램은 어쨌든 그 지점에서 종료됩니다.

합니까? 그 고루틴의 연기는 여전히 호출됩니다. 내가 이해하는 한 그들은 완료될 것입니다. 이 경우 Close는 io.EOF에 신호를 보냅니다.

예를 들어 https://play.golang.org/p/5CFbsAe8zF를 참조하십시오. 고루틴 패닉 후에 여전히 "foo"를 다른 고루틴에 행복하게 전달한 다음 여전히 Stdout에 쓰도록 합니다.

유사하게, 다른 코드는 패닉하는 고루틴(귀하의 예와 같은)에서 잘못된 io.EOF를 수신하고, 성공을 결론지으며, 패닉하는 고루틴이 패닉을 재개하기 전에 행복하게 GS에 파일을 커밋할 수 있습니다.

다음 주장은 다음과 같습니다. 버그가 있는 코드를 작성하지 마십시오. 하지만:

• 그런 다음 이러한 버그를 더 쉽게 방지하고
• 패닉은 OOM과 같은 외부 요인으로 인해 발생할 수 있습니다.

nil 오류로 닫지 않는 것이 중요하다면 간단한 이름 바꾸기에 한 줄을 추가하면 됩니다.

완료되면 io.EOF에 신호를 보내기 위해 여전히 nil로 닫아야 하므로 작동하지 않습니다.

nil 오류로 닫지 않는 것이 중요하다면 간단한 이름 바꾸기에 한 줄을 추가하면 됩니다.

완료되면 io.EOF에 신호를 보내기 위해 여전히 nil로 닫아야 하므로 작동하지 않습니다.

왜 안 돼? return err 끝에 rerr 가 nil 됩니다.

@bcmills : 아 무슨 말인지 이제 알겠어요. 예, 작동해야 합니다. 하지만 저는 줄 수가 아니라 코드의 미묘함에 대해 걱정하고 있습니다.

나는 이것이 변수 섀도잉과 같은 문제 범주에 속한다는 것을 알았습니다. 단지 덜 실행될 가능성이 더 낮았을 뿐이었습니다. 임의적인 공황은 테스트하기가 더 어렵습니다.

대규모로 운영할 때 이와 같은 버그가 나타나는 것이 거의 보장됩니다. 편집증이 있을 수 있지만 데이터 손실 및 손상으로 이어질 가능성이 훨씬 적은 시나리오를 보았습니다. 일반적으로 이것은 괜찮지만 트랜잭션 처리(예: gs 파일 작성)에는 적합하지 않습니다.

나는 당신이 당신의 제안을 대체 구문으로 가로채는 것에 신경쓰지 않기를 바랍니다. 사람들은 다음과 같은 것에 대해 어떻게 생각할까요?

return err if f, err := os.Open("..."); err != nil

@SirCmpwn 그것은 lede를 묻습니다. 함수에서 읽기 가장 쉬운 것은 오류 처리가 아니라 정상적인 제어 흐름이어야 합니다.

그건 공평하지만, 당신의 제안은 저를 불편하게 만들기도 합니다 - 그것은 사용자가 예상하도록 훈련된 방식과 다르게 동작하는 불투명한 구문(||)을 도입합니다 || 행동하는. 올바른 솔루션이 무엇인지 확실하지 않은 경우 더 고민할 것입니다.

@SirCmpwn 예, 원래 게시물에서 말했듯이 "이 제안은 주로 Go 오류 처리를 단순화하려는 사람들이 수정되지 않은 오류를 반환하는 것이 아니라 오류 주위에 컨텍스트를 쉽게 감쌀 수 있는 방법에 대해 생각하도록 권장하기 위해 작성합니다. ." 나는 내 제안을 가능한 한 잘 썼지만 그것이 채택될 것이라고 기대하지 않습니다.

이해했다.

이것은 좀 더 급진적이지만 매크로 기반 접근 방식이 더 잘 작동할 수 있습니다.

f = try!(os.Open("..."))

try! 는 튜플의 마지막 값을 먹고 nil이 아니면 반환하고, 그렇지 않으면 나머지 튜플을 반환합니다.

나는 우리의 문제 진술이,

Go의 오류 처리는 장황하고 반복적입니다. Go의 오류 처리의 관용적 형식은 오류가 아닌 제어 흐름을 보는 것을 더 어렵게 만들고 장황한 내용은 특히 신규 사용자에게 매력적이지 않습니다. 현재까지 이 문제에 대해 제안된 솔루션은 일반적으로 숙련된 일회성 오류 처리 기능을 필요로 하고 오류 처리의 지역성을 줄이고 복잡성을 증가시킵니다. Go의 목표 중 하나는 작성자가 오류 처리 및 복구를 고려하도록 하는 것이기 때문에 오류 처리에 대한 개선도 그 목표를 기반으로 해야 합니다.

이 문제를 해결하기 위해 Go 2.x의 오류 처리 개선을 위한 다음 목표를 제안합니다.

1. 반복적인 오류 처리 상용구를 줄이고 코드 경로의 주요 의도에 최대한 집중합니다.
2. 오류를 전파할 때 오류를 래핑하는 것을 포함하여 적절한 오류 처리를 권장합니다.
3. 명확성과 단순성의 Go 디자인 원칙을 준수합니다.
4. 가능한 가장 광범위한 오류 처리 상황에 적용할 수 있습니다.

이 제안 평가:

f.Close() =? err { return fmt.Errorf(…, err) }

그 목표들에 따르면, 나는 그것이 목표 #1에서 잘 성공했다고 결론지을 것입니다. 이것이 #2에 어떻게 도움이 되는지 잘 모르겠지만 컨텍스트를 추가할 가능성도 줄어들지 않습니다(내 제안은 #2에서 이 약점을 공유했습니다). 하지만 3번과 4번에서는 성공하지 못합니다.
1) 다른 사람들이 말했듯이 오류 값 확인 및 할당은 불투명하고 비정상적입니다. 그리고
2) =? 구문도 특이합니다. 비슷하지만 다른 =! 구문과 결합하면 특히 혼란스럽습니다. 사람들이 그 의미에 익숙해지는 데 시간이 걸릴 것입니다. 그리고
3) 오류와 함께 유효한 값을 반환하는 것은 모든 새 솔루션에서도 해당 경우를 처리해야 할 만큼 일반적입니다.

오류 처리를 블록으로 만드는 것은 좋은 생각일 수 있지만 다른 사람들이 제안한 대로 gofmt 에 대한 변경 사항과 결합된 경우입니다. 내 제안에 비해 일반성이 향상되어 목표 #4에 도움이 되고 친숙도가 향상되어 목표 #3에 도움이 되지만 컨텍스트가 추가되어 단순히 오류를 반환하는 일반적인 경우에 대해 간결함을 희생합니다.

초록에서 저에게 질문했다면 위의 오류 처리 개선 목표를 충족하는 한 오류 처리 특정 솔루션보다 더 일반적인 솔루션이 더 낫다는 데 동의했을 것입니다. 그러나 이제 이 토론을 읽고 더 많이 생각한 결과 오류 처리 특정 솔루션이 더 명확하고 단순하게 결과를 가져올 것이라고 믿는 경향이 있습니다. Go의 오류는 값일 뿐이지만 오류 처리는 오류 처리 코드를 명확하고 간결하게 만드는 특정 구문이 있는 프로그래밍의 중요한 부분을 구성합니다. 범위 지정 및 구성 가능성과 같은 다른 목표와 병합하면 이미 어려운 문제(오류 처리를 위한 깨끗한 솔루션을 제공하는 것)를 훨씬 더 어렵고 복잡하게 만들 것입니다.

그럼에도 불구하고 @rsc 가 자신의 기사 Toward Go 2 에서 지적했듯이 문제 설명, 목표 또는 구문 제안은 문제가 중요하다는 것을 보여주는 경험 보고서 없이는 진전되지 않을 것입니다. 다양한 구문 제안에 대해 토론하는 대신 지원 데이터를 찾기 시작해야 할까요?

그럼에도 불구하고 @rsc 가 자신의 기사 Toward Go 2에서 지적했듯이 문제 설명, 목표 또는 구문 제안은 문제가 중요함을 보여주는 경험 보고서 없이는 진전되지 않을 것입니다. 다양한 구문 제안에 대해 토론하는 대신 지원 데이터를 파헤쳐야 할까요?

인체 공학이 중요하다고 가정하면 이것은 자명하다고 생각합니다. Go 코드베이스를 열고 언어가 처리할 수 있는 작업을 건조하거나 인체 공학을 개선할 기회가 있는 곳을 찾으십시오. 현재 오류 처리는 명백한 이상값입니다. 나는 Toward Go 2 접근 방식이 해결 방법이 있는 문제를 무시하도록 잘못 옹호할 수 있다고 생각합니다. 이 경우 사람들은 그저 웃으면서 참습니다.

if $val, err := $operation($args); err != nil {
  return err
}

코드보다 상용구가 많을 때 문제는 자명합니다.

@billyh

f.Close() =? err { return fmt.Errorf(…, err) } 형식이 너무 장황하고 혼란스럽다고 생각합니다. 나는 개인적으로 오류 부분이 블록에 있어야 한다고 생각하지 않습니다. 필연적으로 1줄이 아닌 3줄로 나누어지게 됩니다. 또한 오류를 반환하기 전에 오류를 수정하는 것 이상을 수행해야 하는 오프 변경에서 현재 if err != nil { ... } 사용할 수 있습니다

=? 연산자도 약간 혼란스럽습니다. 그곳에서 무슨 일이 일어나고 있는지 즉시 알 수 없습니다.

다음과 같이:
file := os.Open("/some/file") or raise(err) errors.Wrap(err, "extra context")
또는 약어:
file := os.Open("/some/file") or raise
그리고 연기된:
defer f.Close() or raise(err2) errors.ReplaceIfNil(err, err2)
좀 더 장황하고 단어를 선택하면 초기 혼란을 줄일 수 있습니다(즉, 사람들은 raise 을 Python과 같은 다른 언어의 유사한 키워드와 즉시 연관시키거나, 단지 제기가 오류/마지막 비-비를 발생시키는 것으로 추론할 수 있습니다. 호출자에게 스택을 기본값으로 설정).

또한 태양 아래에서 가능한 모든 모호한 오류 처리를 해결하려고 시도하지 않는 좋은 명령형 솔루션입니다. 지금까지 야생에서 가장 큰 오류 처리 덩어리는 위에서 언급한 특성입니다. 나중을 위해 현재 구문도 도움이 됩니다.

편집하다:
"마법"을 조금 줄이려면 이전 예제도 다음과 같을 수 있습니다.
file, err := os.Open("/some/file") or raise errors.Wrap(err, "extra context")
file, err := os.Open("/some/file") or raise err
defer err2 := f.Close() or errors.ReplaceIfNil(err, err2)
저는 개인적으로 이전 예제가 여기에서처럼 분할하는 대신 전체 오류 처리를 오른쪽으로 이동하기 때문에 더 낫다고 생각합니다. 그러나 이것은 더 명확할 수 있습니다.

나는 우리의 문제 진술이, ...

문제 진술에 동의하지 않습니다. 대안을 제안하고 싶습니다.

언어적 관점에서 오류 처리는 존재하지 않습니다. Go가 제공하는 유일한 것은 미리 선언된 오류 유형이며 실제로 새로운 것을 가능하게 하지 않기 때문에 편의를 위한 것입니다. 오류는 값일 뿐입니다 . 오류 처리는 일반적인 사용자 코드입니다. 언어 POV에서 그것에 대해 특별한 것은 없으며 그것에 대해 특별한 것이 없어야합니다. 오류 처리의 유일한 문제는 일부 사람들이 이 가치 있고 아름다운 단순성을 어떤 희생을 치르더라도 제거해야 한다고 생각한다는 것입니다.

Cznic이 말한 대로 오류 처리 이상에 유용한 솔루션이 있으면 좋을 것입니다.

오류 처리를 보다 일반적으로 만드는 한 가지 방법은 통합 유형/합 유형 및 래핑 해제 측면에서 생각하는 것입니다. Swift와 Rust는 둘 다 ? ! 비록 Rust가 약간 불안정하다고 생각하지만.

합계 유형을 높은 수준의 개념으로 만들고 싶지 않다면 튜플이 실제로 Go의 일부가 아닌 방식으로 다중 반환의 일부로 만들 수 있지만 여전히 다중 반환을 수행할 수 있습니다.

Swift에서 영감을 받은 구문 분석:

func Failable() (*Thingie | error) {
    ...
}

guard thingie, err := Failable() else { 
    return wrap(err, "Could not make thingie)
}
// err is not in scope here

다음과 같은 다른 용도로도 사용할 수 있습니다.

guard val := myMap[key] else { val = "default" }

@bcmills 와 @jba 가 제안한 =? 솔루션은 오류를 위한 것이 아니라 0이 아닌 개념을 위한 것입니다. 이 예는 정상적으로 작동합니다.

func Foo()(Bar, Recover){}
bar := Foo() =? recover { log.Println("[Info] Recovered:", recover)}

이 제안의 주요 아이디어는 읽기 쉽도록 사이드 노트, 코드의 주요 목적을 분리하고 부차적인 경우는 따로 두는 것입니다.
나에게 Go 코드를 읽는 것은 어떤 경우에는 연속적이지 않습니다. 여러 번 if err!= nil {return err} 하여 중지 아이디어를 @jba 토크 )
매우 드문 상황에서 오류는 기능의 주요 목적이며 아마도 복구에 있을 수 있습니다. 일반적으로 오류가 발생하면 컨텍스트, 로그 및 반환을 추가합니다. 이러한 경우 보조 메모를 통해 코드를 더 읽기 쉽게 만들 수 있습니다.
가장 좋은 구문인지는 모르겠지만 특히 두 번째 부분의 블록이 마음에 들지 않습니다. 보조 메모는 작아야 하고 한 줄이면 충분해야 합니다.

bar := Foo() =? recover: log.Println("[Info] Recovered:", recover)

@billyh

1. 다른 사람들이 말했듯이 오류 값 확인 및 할당은 불투명하고 이례적입니다. 그리고

좀 더 구체적으로 말씀해 주십시오. "불투명하고 특이한" 것은 지극히 주관적입니다. 제안이 혼동될 수 있다고 생각되는 코드의 몇 가지 예를 제시할 수 있습니까?

1. =? 구문도 비정상적입니다. […]

IMO 그 기능입니다. 누군가 비정상적인 연산자를 본다면 정확할 수도 있고 정확하지 않을 수도 있는 무언가를 가정하는 대신 그 연산자가 수행하는 작업을 찾는 경향이 더 크다고 생각합니다.

1. 오류와 함께 유효한 값을 반환하는 것은 모든 새 솔루션에서도 해당 사례를 처리해야 할 만큼 일반적입니다.

그렇습니다?

제안을 주의 깊게 읽으십시오. =? 는 Block 를 평가하기 전에 할당을 수행하므로 이 경우에도 사용할 수 있습니다.

n := r.Read(buf) =? err {
  if err == io.EOF {
    […]
  }
  return err
}

그리고 @nigeltao가 언급했듯이 항상 기존 'n, err := r.Read(buf)' 패턴을 사용할 수 있습니다. 일반적인 경우에 대한 범위 지정 및 상용구에 도움이 되는 기능을 추가한다고 해서 일반적이지 않은 경우에도 이 기능을 사용해야 한다는 의미는 아닙니다.

다양한 구문 제안에 대해 토론하는 대신 지원 데이터를 파헤쳐야 할까요?

Ian이 원본 게시물에 링크한 수많은 문제(및 해당 예)를 참조하세요.
https://github.com/golang/go/wiki/ExperienceReports#error -handling도

해당 보고서에서 구체적인 통찰력을 얻었다면 공유해 주십시오.

@urandom

나는 개인적으로 오류 부분이 블록에 있어야 한다고 생각하지 않습니다. 부득이하게 1줄이 아닌 3줄로 늘어납니다.

블록의 목적은 두 가지입니다.

1. 오류를 생성하는 표현과 해당 처리기 사이에 명확한 시각적 및 문법적 구분을 제공하고,
2. 더 넓은 범위의 오류 처리를 허용합니다(원래 게시물에서 @ianlancetaylor 의 명시된 목표에 따라).

3줄 대 1은 언어 변경도 아닙니다. 줄 수가 가장 큰 문제인 경우 gofmt 로 간단히 변경하여 해결할 수 있습니다.

file, err := os.Open("/some/file") or raise errors.Wrap(err, "extra context")
file, err := os.Open("/some/file") or raise err

우리는 이미 return 및 panic ; 그 위에 raise 를 추가하면 너무 적은 이득을 위해 함수를 종료하는 방법이 너무 많은 것처럼 보입니다.

defer err2 := f.Close() or errors.ReplaceIfNil(err, err2)

errors.ReplaceIfNil(err, err2) 에는 매우 특이한 참조 통과 의미 체계가 필요합니다.
대신 포인터로 err 를 전달할 수 있습니다.

defer err2 := f.Close() or errors.ReplaceIfNil(&err, err2)

그러나 그것은 여전히 ​​나에게 매우 이상하게 보입니다. or 토큰이 표현식, 명령문 또는 다른 것을 구성합니까? (보다 구체적인 제안이 도움이 될 것입니다.)

@carlmjohnson

guard … else 문의 구체적인 구문과 의미는 무엇입니까? 제 생각에는 토큰과 변수 위치가 교환된 =? 또는 :: 처럼 보입니다. (다시 말하지만, 보다 구체적인 제안이 도움이 될 것입니다. 염두에 두고 있는 실제 구문과 의미는 무엇입니까?)

@bcmills
가상의 ReplaceIfNil은 다음과 같이 간단합니다.

func ReplaceIfNil(original, replacement error) error {
   if original == nil {
       return replacement
   }
   return original
}

그것에 대해 이상한 것은 없습니다. 아마도 이름은 ...

or 는 이진 연산자이고 왼쪽 피연산자는 IdentifierList 또는 PrimaryExpr입니다. 전자의 경우 가장 오른쪽 식별자로 축소됩니다. 그런 다음 왼쪽 피연산자가 기본값이 아닌 경우 오른쪽 피연산자가 실행되도록 허용합니다.

이것이 나중에 표현식의 값을 취하는 Result 함수의 마지막 매개변수를 제외한 모든 것에 대해 기본값을 반환하는 마법을 수행하기 위해 나중에 다른 토큰이 필요한 이유입니다.
IIRC, 너무 오래 전에 언어에 지루한 기본값 초기화를 대신할 '...' 또는 무언가를 추가하는 또 다른 제안이 있었습니다. 그 원인에서 전체가 다음과 같이 보일 수 있습니다.

f, err := os.Open("/some/file") or return ..., errors.Wrap(err, "more context")

블록에 관해서는 더 넓은 처리가 가능하다는 것을 이해합니다. 나는 개인적으로 이 제안의 범위가 가상의 80%를 커버하는 것과는 대조적으로 가능한 모든 시나리오를 시도하고 수용해야 하는지 확신하지 못합니다. 그리고 저는 개인적으로 결과가 얼마나 많은 줄을 사용하는지가 중요하다고 믿습니다(나는 그것이 가장 큰 관심사라고 말한 적이 없지만 =?와 같은 모호한 토큰을 사용할 때 사실 가독성 또는 가독성 부족입니다). 이 새로운 제안이 일반적인 경우 여러 줄에 걸쳐 있는 경우 개인적으로 다음과 같은 이점이 없습니다.

if f, err := os.Open("/some/file"); err != nil {
     return errors.Wrap(err, "more context")
}

• 위에 정의된 변수가 if 범위 외부에서 사용 가능하게 된 경우.
  그리고 여전히 이러한 오류 처리 블록의 시각적 노이즈로 인해 이러한 명령문이 몇 개 있는 함수를 읽기가 더 어렵게 만듭니다. 그리고 그것은 사람들이 이동 중에 오류 처리를 논의할 때 가지고 있는 불만 중 하나입니다.

@urandom

or 는 이진 연산자이고 왼쪽 피연산자는 IdentifierList 또는 PrimaryExpr입니다. [...] 그런 다음 왼쪽 피연산자가 기본값이 아닌 경우 오른쪽 피연산자가 실행되도록 합니다.

Go의 이진 연산자는 문이 아니라 표현식이므로 or 를 이진 연산자로 만드는 것은 많은 질문을 제기합니다. (더 큰 표현의 일부인 or 의 의미는 무엇이며 := 와 함께 게시한 예제와 어떻게 연관됩니까?)

실제로 문장이라고 가정하면 오른쪽 피연산자는 무엇입니까? 표현식이라면 그 유형은 무엇이며 raise 를 다른 컨텍스트에서 표현식으로 사용할 수 있습니까? 명령문인 경우 raise 이외의 다른 의미는 무엇입니까? 아니면 or raise 가 본질적으로 단일 명령문(예: :: 또는 =? 대한 구문 대안으로 :: or raise 되도록 제안하시겠습니까?

내가 쓸 수 있을까

defer f.Close() or raise(err2) errors.ReplaceIfNil(err, err2) or raise(err3) Transform(err3)

?

내가 쓸 수 있을까

f(r.Read(buf) or raise err)

?

defer f.Close() or raise(err2) errors.ReplaceIfNil(err, err2) or raise(err3) Transform(err3)

아니요, 두 번째 raise 때문에 유효하지 않습니다. 그렇지 않은 경우 전체 변환 체인을 거쳐야 하고 최종 결과가 호출자에게 반환되어야 합니다. 전체로서의 의미론은 필요하지 않을 수 있지만 다음과 같이 작성할 수 있습니다.

defer f.Close() or raise(err2) Transform(errors.ReplaceIfNil(err, err2)

f(r.Read(buf) or raise err)

내 원래 의견을 가정하면 - 여기서 또는 왼쪽의 마지막 값을 취하여 기본값인 경우 최종 표현식은 나머지 결과 목록으로 평가됩니다. 네, 이것은 유효해야 합니다. 이 경우 r.Read 가 오류를 반환하면 해당 오류가 호출자에게 반환됩니다. 그렇지 않으면 n 가 f 로 전달됩니다.

편집하다:

용어가 혼동되지 않는 한 or 를 이항 연산자로 생각합니다. 이 연산자의 피연산자는 동일한 유형이어야 합니다(그러나 왼쪽 피연산자가 사물의 목록이고 이 경우 해당 목록의 마지막 요소를 사용합니다). raise 는 피연산자를 사용하고 해당 피연산자의 값을 마지막 반환 인수의 값으로 사용하여 함수에서 반환하는 단항 연산자이며 이전 값은 기본값을 갖습니다. 그런 다음 return ..., err 라고도 하는 함수에서 반환할 목적으로 독립 실행형 문에서 기술적으로 raise 를 사용할 수 있습니다.

이것은 이상적인 경우이지만 블록 대신 간단한 명령문을 허용하는 한 or raise 가 =? 대한 구문 대안일 뿐이므로 괜찮습니다. 덜 장황한 방식으로 대부분의 사용 사례를 다룹니다. 또는 표현식을 허용하는 지연과 같은 문법도 사용할 수 있습니다. 이것은 다음과 같은 대부분의 경우를 다룰 것입니다:

f := os.Open("/some/file") or raise(err) errors.Wrap(err, "with context")

복잡한 경우:

f := os.Open or raise(err) func() {
     if err == io.EOF {
         […]
     }
  return err
}()

내 제안에 대해 조금 더 생각하면서, 나는 union/sum-types에 대해 조금 떨어뜨립니다. 내가 제안하는 구문은

guard [ ASSIGNMENT || EXPRESSION ] else { [ BLOCK ] }

표현식의 경우 표현식을 평가하고 결과가 boolean 표현식의 경우 true 또는 다른 표현식의 경우 공백 값과 같지 않으면 BLOCK이 실행됩니다. 할당에서 마지막으로 할당된 값은 != true / != nil 됩니다. 가드 문 다음에는 모든 할당이 범위 내에 있게 됩니다(마지막 변수를 제외하고는 새 블록 범위를 생성하지 않습니다).

Swift에서 BLOCK for guard 문은 return , break , continue 또는 throw 중 하나를 포함해야 합니다. 나는 그것을 좋아하는지 아닌지 결정하지 않았습니다. 독자가 guard 단어에서 다음에 무엇을 할지 알기 때문에 약간의 가치를 더하는 것 같습니다.

guard 이 커뮤니티에서 좋은 평가를 받고 있다고 말할 만큼 Swift를 잘 따르는 사람이 있습니까?

예:

guard f, err := os.Open("/some/file") else { return errors.Wrap(err, "could not open:") }

guard data, err := ioutil.ReadAll(f) else { return errors.Wrap(err, "could not read:") }

var obj interface{}

guard err = json.Unmarshal(data, &obj) else { return errors.Wrap(err, "could not unmarshal:") }

guard m, _ := obj.(map[string]interface{}) else { return errors.New("unexpected data format") }

guard val, _ := m["key"] else { return errors.New("missing key") }

임호 여기저기서 한꺼번에 너무 광범위한 문제를 논하는데 현실에서 가장 흔한 패턴은 '오류를 있는 그대로 돌려보내는 것'이다. 따라서 다음과 같은 smth의 가장 큰 문제에 접근하지 않는 이유는 무엇입니까?

code, err ?= fn()

이는 함수가 err != nil에서 반환되어야 함을 의미합니까?

:= 연산자를 위해 ?:=를 도입할 수 있습니다.

code, err ?:= fn()

컴파일러가 "err" 변수를 동일한 이름의 err 반환 값에 전달해야 하기 때문에 ?:= 의 상황은 섀도잉으로 인해 더 나쁜 것 같습니다.

일부 사람들이 단순히 잘못된 코드를 줄이는 대신 올바른 코드를 더 쉽게 작성할 수 있도록 하는 데 집중하고 있다는 사실에 매우 기쁩니다.

몇 가지 참고 사항:

오류 모델에 대한 Microsoft의 Midori 디자이너 중 한 명이 작성한 흥미로운

이 문서와 Swift의 몇 가지 아이디어가 Go2에 아름답게 적용될 수 있다고 생각합니다.

새로 수정된 throws 키워드를 도입하면 다음과 같이 함수를 정의할 수 있습니다.

func Get() []byte throws {
  if (...) {
    raise errors.New("oops")
  }

  return []byte{...}
}

던지지 않는 다른 함수에서 이 함수를 호출하려고 하면 처리되지 않은 throw 가능한 오류로 인해 컴파일 오류가 발생합니다.
대신 우리는 모두가 동의하는 오류를 전파하거나 처리할 수 있어야 합니다.

func ScrapeDate() time.Time throws {
  body := Get() // compilation error, unhandled throwable
  body := try Get() // we've been explicit about potential throwable

  // ...
}

메소드가 실패하지 않는다는 것을 알고 있는 경우 또는 테스트에서 swift와 유사한 try! 도입할 수 있습니다.

func GetWillNotFail() time.Time {
  body := Get() // compilation error, throwable not handled
  body := try Get() // compilation error, throwable can not be propagated, because `GetWillNotFail` is not annotated with throws
  body := try! Get() // works, but will panic on throws != nil

  // ...
}

확실하지 않지만(swift와 유사):

func main() {
  // 1:
  do {
    fmt.Printf("%v", try ScrapeDate())
  } catch err { // err contains caught throwable
    // ...
  }

  // 2:
  do {
    fmt.Printf("%v", try ScrapeDate())
  } catch err.(type) { // similar to a switch statement
    case error:
      // ...
    case io.EOF
      // ...
  }
}

PS1. 여러 반환 값 func ReadRune() (ch Rune, size int) throws { ... }
PS2. return try Get() 또는 return try! Get() 반환할 수 있습니다.
PS3. 이제 buffer.NewBuffer(try Get()) 또는 buffer.NewBuffer(try! Get()) 와 같은 호출을 연결할 수 있습니다.
PS4. 주석이 확실하지 않음( errors.Wrap(err, "context") 작성하기 쉬운 방법)
PS5. 이것은 실제로 예외입니다
PS6. 가장 큰 승리는 무시된 예외에 대한 컴파일 시간 오류입니다.

당신이 쓰는 제안은 모든 나쁜 것들과 함께 미도리 링크에 정확히 설명되어 있습니다
그것의 측면... 그리고 "던짐"의 명백한 결과 중 하나는 "사람
싫어". 왜 대부분의 경우 매번 "throws"를 써야 합니까?
기능?

BTW, 오류를 확인하고 무시하지 않으려는 의도는
오류가 아닌 유형에도 적용되며 더 많이 사용하는 것이 좋습니다.
일반화된 형식(예: gcc __attribute__((warn_unused_result))).

연산자의 형식에 관해서는 짧은 형식이나
다음과 같은 키워드 형식:

?= fn() OR check fn() -- 호출자에게 오류 전파
!= fn() 또는 nofail fn() -- 오류 발생 시 패닉

2017년 8월 26일 토요일 오후 12:15, nvartolomei [email protected]
썼다:

몇 가지 참고 사항:

흥미로운 경험 보고서
http://joeduffyblog.com/2016/02/07/the-error-model/ 중 하나에서
오류 모델에 대한 Microsoft의 Midori 디자이너.

이 문서와 Swift에서 몇 가지 아이디어가 있다고 생각합니다.
https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/ErrorHandling.html
Go2에 아름답게 적용할 수 있습니다.

새로운 reseved throws 키워드를 도입하면 다음과 같이 함수를 정의할 수 있습니다.

func Get() []byte는 {
만약 (...) {
오류 발생.New("oops")
}

반환 []바이트{...}
}

던지지 않는 다른 함수에서 이 함수를 호출하려고 하면
처리되지 않은 throw 가능한 오류로 인해 컴파일 오류가 발생합니다.
대신 우리는 모두가 동의하는 오류를 전파할 수 있어야 합니다.
일반적인 경우 또는 처리하십시오.

func ScrapeDate() time.Time은 {
body := Get() // 컴파일 오류, 처리되지 않은 throw 가능
body := try Get() // 우리는 잠재적인 throwable에 대해 명시했습니다.

// ...
}

방법이 실패하지 않을 것이라는 것을 알고 있는 경우 또는 테스트에서 다음을 수행할 수 있습니다.
시도를 소개합니다! 스위프트와 비슷하다.

func GetWillNotFail() time.Time {
body := Get() // 컴파일 오류, throwable이 처리되지 않음
body := try Get() // 컴파일 오류, throwable을 전파할 수 없습니다. GetWillNotFail 에 throw 주석이 없기 때문입니다.
몸 := 시도! Get() // 작동하지만 throw 시 패닉이 발생합니다 != nil

// ...
}

확실하지 않지만(swift와 유사):

함수 메인() {
// 1:
하다 {
fmt.Printf("%v", ScrapEDate()를 시도하십시오)
} catch err { // err에는 catch된 throwable이 포함되어 있습니다.
// ...
}

// 2:
하다 {
fmt.Printf("%v", ScrapEDate()를 시도하십시오)
} catch err.(type) { // switch 문과 유사
케이스 오류:
// ...
케이스 io.EOF
// ...
}
}

PS1. 여러 반환 값 func ReadRune() (ch Rune, 크기 int) throw {
... }
PS2. return try Get() 또는 return try로 돌아갈 수 있습니다! 얻다()
PS3. 이제 buffer.NewBuffer(try Get()) 또는 buffer.NewBuffer(try!
얻다())
PS4. 주석이 확실하지 않음

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/golang/go/issues/21161#issuecomment-325106225 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AICzv9CLN77RmPceCqvjXVE_UZ6o7JGvks5sb-IYgaJpZM4Oi1c-
.

@jba 와 @bcmills 가 제안한 연산자는 "??"로 더 잘

이 예를 보면:

func doStuff() (int,error) {
    x, err := f() 
    if err != nil {
        return 0, wrapError("f failed", err)
    }

    y, err := g(x)
    if err != nil {
        return 0, wrapError("g failed", err)
    }

    return y, nil
}

func doStuff2() (int,error) {
    x := f()  ?? (err error) { return 0, wrapError("f failed", err) }
    y := g(x) ?? (err error) { return 0, wrapError("g failed", err) }
    return y, nil
}

doStuff2는 다음과 같은 이유로 읽기가 훨씬 쉽고 빠릅니다.

1. 수직 공간을 덜 낭비
2. 왼쪽의 행복한 길을 빨리 읽기 쉽습니다.
3. 오른쪽의 오류 조건을 빠르게 읽기 쉽습니다.
4. 함수의 로컬 네임스페이스를 오염시키는 오류 변수가 없습니다.

나에게 이 제안은 불완전해 보이고 너무 많은 마법을 가지고 있습니다. ?? 연산자는 어떻게 정의됩니까? "nil이 아닌 경우 마지막 반환 값을 캡처합니다"? "메소드 유형과 일치하는 경우 마지막 오류 값을 캡처합니까?"

위치와 유형에 따라 반환 값을 처리하기 위해 새 연산자를 추가하는 것은 해킹처럼 보입니다.

2017년 8월 29일 13:03 +0300, Mikael Gustavsson [email protected] 은 다음과 같이 썼습니다.

@jba 와 @bcmills 가 제안한 연산자는 "??"로 더 잘
이 예를 보면:
func doStuff() (int, error) {
x, 오류 := f()
오류 != nil {
반환 0, wrapError("f 실패", 오류)
}

   y, err := g(x)
   if err != nil {
           return 0, wrapError("g failed", err)
   }

   return y, nil

}

func doStuff2() (int, error) {
x := f() ?? (오류 오류) { 0 반환, wrapError("f 실패", 오류) }
y := g(x) ?? (오류 오류) { 0 반환, wrapError("g 실패", 오류) }
리턴 y, nil
}
doStuff2는 다음과 같은 이유로 읽기가 훨씬 쉽고 빠릅니다.

1. 수직 공간을 덜 낭비
2. 왼쪽의 행복한 길을 빨리 읽기 쉽습니다.
3. 오른쪽의 오류 조건을 빠르게 읽기 쉽습니다.
4. 함수의 로컬 네임스페이스를 오염시키는 오류 변수가 없습니다.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 보거나 스레드를 음소거하세요.

@nvartolomei

?? 연산자는 어떻게 정의됩니까?

https://github.com/golang/go/issues/21161#issuecomment -319434101 및 https://github.com/golang/go/issues/21161#issuecomment -320758279를 참조 하세요 .

@bcmills 는 정지된 스레드를 부활 @slvmnd 의 예를

func doStuff() (int, err) {
        x, err := f()
        return 0, wrapError("f failed", err)     if err != nil

    y, err := g(x)
        return 0, wrapError("g failed", err)     if err != nil

        return y, nil
}

한 줄에 명령문과 오류 검사를 포함하는 것만큼 간결하지는 않지만 합리적으로 잘 읽힙니다. (if 표현식에서 := 형식의 할당을 허용하지 않는 것이 좋습니다. 그렇지 않으면 문법이 명확하더라도 범위 지정 문제가 사람들을 혼란스럽게 할 수 있습니다.) "if"의 부정 버전으로 "unless"를 허용하는 것은 약간의 구문상의 설탕이지만 읽기에 잘 작동하며 고려할 가치가 있습니다.

하지만 여기에서는 Perl에서 크리빙(cribbing)하는 것을 권장하지 않습니다. (Basic Plus 2는 괜찮습니다.) 그런 식으로 반복문 수정자가 있는데, 이는 때때로 유용하지만 또 다른 상당히 복잡한 문제 세트를 가져옵니다.

더 짧은 버전:
오류 != nil이면 반환
그때도 지원해야 합니다.

이러한 구문을 사용하면 질문이 발생합니다.
다음과 같은 "if" 문으로 지원됩니다.
func(args) if 조건

애프터 액션을 발명하는 대신 싱글을 도입할 가치가 있다면
라인이라면?

err!=nil 반환이면
err!=nil이 0을 반환하면 wrapError("실패", err)
만약 err!=nil do_smth()

특별한 형태의 구문보다 훨씬 더 자연스러워 보이지 않습니까? 내가 추측하지만
그것은 구문 분석에 많은 고통을 초래합니다 :/

하지만... 모두 작은 조정일 뿐이며 오류에 대한 특별한 언어 지원이 아닙니다.
취급/전파.

2017년 9월 18일 월요일 오후 4시 14분에 dsugalski [email protected]에서 다음과 같이 썼습니다.

@bcmills https://github.com/bcmills 가
조용한 스레드, 다른 언어에서 크리빙을 고려하려는 경우
문 수정자가 모든 사람에게 합리적인 솔루션을 제공하는 것처럼 보입니다.
이것. @slvmnd https://github.com/slvmnd 의 예를
명령문 수정자:

func doStuff() (int, err) {
x, 오류 := f()
0 반환, wrapError("f 실패", err) err != nil인 경우

  y, err := g(x)
    return 0, wrapError("g failed", err)     if err != nil

    return y, nil

}

명령문과 오류를 한 번에 확인하는 것만큼 간결하지는 않습니다.
줄이지만 꽤 잘 읽힙니다. (:= 형식을 허용하지 않는 것이 좋습니다.
if 표현식에 할당하지 않으면 범위 지정 문제가 발생할 수 있습니다.
문법이 명확하더라도 사람들을 혼란스럽게 합니다.
"if"의 부정 버전은 약간의 구문 설탕이지만 다음과 같이 잘 작동합니다.
읽고 고려할 가치가 있습니다.

하지만 여기에서는 Perl에서 크리빙(cribbing)하는 것을 권장하지 않습니다. (베이직 플러스 2는
fine) 그런 식으로 반복되는 문 수정자가 있지만 때로는
유용하고 상당히 복잡한 문제의 또 다른 집합을 가져옵니다.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/golang/go/issues/21161#issuecomment-330215402 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AICzv1rfnXeGVRRwaigCyyVK_STj-i83ks5sjmylgaJpZM4Oi1c-
.

@dsugalski 의 제안에 대해 좀 더 생각해보면 @jba 및 다른 사람들이 요청한 속성, 즉 오류가 아닌 코드가 오류 코드와 시각적으로 구별되는 속성이 없습니다. 오류가 없는 코드 경로에도 상당한 이점이 있다면 여전히 흥미로운 아이디어일 수 있지만, 제안된 대안에 비해 그것에 대해 생각하면 할수록 덜 매력적으로 보입니다.

순수한 텍스트에서 기대하는 것이 얼마나 시각적인 차이가 있는지 잘 모르겠습니다. 어떤 시점에서는 이를 IDE 또는 텍스트 편집기의 코드 색칠 레이어에 펀트하는 것이 더 적절해 보입니다.

그러나 텍스트 기반의 가시적 구분을 위해 창피할 정도로 오래 전에 이것을 처음 사용하기 시작했을 때 우리가 가지고 있던 서식 표준은 IF/UNLESS 문 수정자를 오른쪽으로 정렬해야 했기 때문에 충분히 눈에 띄게 만들었습니다. (단, 보다 유연한 창 크기를 가진 편집기보다 VT-220 터미널에서 적용하기 쉽고 시각적으로 더 구별되는 표준이 부여되었지만)

적어도 나에게는 명령문 수정자 case가 쉽게 구별되고 현재 if-block 체계보다 더 잘 읽힌다는 것을 알았습니다. 물론 다른 사람들에게는 그렇지 않을 수도 있습니다. 저는 영어 텍스트를 읽는 것과 같은 방식으로 소스 코드를 읽고 기존의 편안한 패턴에 매핑되지만 모든 사람이 이렇게 하는 것은 아닙니다.

return 0, wrapError("f failed", err) if err != nil 는 if err != nil { return 0, wrapError("f failed", err) } 로 쓸 수 있습니다.

if err != nil return 0, wrapError("f failed", err) 동일하게 쓸 수 있습니다.

여기서 필요한 것은 gofmt가 if 를 세 줄로 확장하는 대신 한 줄에 한 줄로 작성하는 것뿐일까요?

나를 공격하는 또 다른 가능성이 있습니다. 일회용 Go 코드를 빠르게 작성하려고 할 때 경험하는 많은 마찰은 모든 단일 호출에서 오류 검사를 수행해야 하므로 호출을 멋지게 중첩할 수 없기 때문입니다.

예를 들어, 먼저 http.NewRequest 결과를 임시 변수에 할당한 다음 Do를 호출하지 않고는 새 요청 객체에 대해 http.Client.Do를 호출할 수 없습니다.

다음을 허용할 수 있는지 궁금합니다.

f(y())

y 가 (T, error) 튜플을 반환하더라도 작동합니다. y가 오류를 반환하면 컴파일러는 식 평가를 중단하고 해당 오류가 f에서 반환되도록 할 수 있습니다. f가 오류를 반환하지 않으면 오류가 발생할 수 있습니다.

그러면 나는 할 수 있다:

n, err := http.DefaultClient.Do(http.NewRequest("DELETE", "/foo", nil))

NewRequest 또는 Do가 실패하면 오류 결과는 nil이 아닙니다.

그러나 여기에는 한 가지 중요한 문제가 있습니다. f가 두 개의 인수 또는 가변 인수를 허용하는 경우 위의 식은 이미 유효합니다. 또한 이를 수행하기 위한 정확한 규칙이 상당히 복잡할 수 있습니다.

그래서 일반적으로 나는 그것을 좋아하지 않는다고 생각하지만(나도 이 스레드의 다른 제안에 관심이 없습니다), 어쨌든 고려를 위해 아이디어를 버릴 것이라고 생각했습니다.

@rogpeppe 아니면 그냥 사용할 수 있습니다 json.NewEncoder을

@gbbr 하 예, 나쁜 예입니다.

더 나은 예는 http.Request일 수 있습니다. 그것을 사용하기 위해 주석을 변경했습니다.

와. 많은 아이디어가 코드 가독성을 더욱 악화시키고 있습니다.
나는 접근이 좋다

if val, err := DoMethod(); err != nil {
   // val is accessible only here
   // some code
}

한 가지 정말 짜증나는 것은 반환된 변수의 범위를 지정하는 것입니다.
이 경우 val 를 사용해야 하지만 if 범위에 있습니다.
따라서 else 를 사용해야 하지만 linter는 이에 반대할 것이며(저도 마찬가지입니다) 유일한 방법은

val, err := DoMethod()
if err != nil {
   // some code
}
// some code with val

if 블록 외부의 변수에 액세스할 수 있으면 좋을 것입니다.

if val, err := DoMethod(); err != nil {
   // some code
}
// some code with val

@dmbreaker 이것이 본질적으로 Swift의 가드 절의 목적입니다. 어떤 조건을 통과하면 현재 범위 내에서 변수를 할당합니다. 내 이전 의견을 참조하십시오.

저는 Go에서 오류 처리를 단순화하기 위해 최선을 다하고 있지만(개인적으로 그다지 신경 쓰지는 않지만) 이것이 간단하고 매우 읽기 쉬운 언어에 약간의 마법을 추가한다고 생각합니다.

@gbbr
여기서 말하는 '이것'은 무엇입니까? 일을 처리하는 방법에 대한 몇 가지 다른 제안이 있습니다.

아마도 두 부분으로 구성된 솔루션입니까?

try 를 "반환 튜플에서 가장 오른쪽 값을 벗겨내십시오. 해당 유형에 대한 0 값이 아닌 경우 다른 값이 0으로 설정된 이 함수의 가장 오른쪽 값으로 반환"으로 정의합니다. 이것은 일반적인 경우를 만듭니다

 a := try ErrorableFunction(b)

연결을 가능하게 합니다.

 a := try ErrorableFunction(try SomeOther(b, c))

(선택적으로 효율성을 위해 0이 아닌 nil이 아닌 것으로 만듭니다.) 오류 함수가 nil/0이 아닌 값을 반환하면 함수는 "값과 함께 중단"됩니다. try 'ed 함수의 가장 오른쪽 값은 호출 함수의 가장 오른쪽 값에 할당할 수 있어야 합니다. 그렇지 않으면 컴파일 타임 유형 검사 오류입니다. (따라서 이것은 error 만 처리하도록 하드 코딩되지 않았지만 커뮤니티에서는 다른 "영리한" 코드에 대한 사용을 권장하지 않을 수 있습니다.)

그런 다음, 다음 중 하나와 같은 지연 키워드로 try 반환을 포착하도록 허용합니다.

catch func(e error) {
    // whatever this function returns will be returned instead
}

또는 더 장황하지만 Go가 이미 작동하는 방식과 더 관련이 있습니다.

defer func() {
    if err := catch(); err != nil {
        set_catch(ErrorWrapper{a, "while posting request to server"})
    }
}()

catch 경우 함수의 매개변수는 반환되는 값과 정확히 일치해야 합니다. 여러 기능이 제공되는 경우 값은 모든 기능을 역순으로 전달합니다. 물론 올바른 유형의 함수로 해석되는 값을 넣을 수 있습니다. defer 기반 예제의 경우 하나의 defer func가 set_catch 호출하면 다음 defer func는 catch() 값을 가져옵니다. (만약 당신이 프로세스에서 그것을 다시 nil로 설정할 만큼 어리석다면, 혼란스러운 반환 값을 얻을 것입니다. 그렇게 하지 마십시오.) set_catch에 전달된 값은 반환된 유형에 할당할 수 있어야 합니다. 두 경우 모두 선언이 아니라 명령문이라는 점에서 이것이 defer 처럼 작동할 것으로 예상하고 명령문이 실행된 후에만 코드에 적용됩니다.

나는 단순성 관점에서 연기 기반 솔루션을 선호하는 경향이 있지만(기본적으로 거기에 새로운 개념이 도입되지 않고 새로운 것이 아니라 recover() 의 두 번째 유형임) 성능 문제가 있을 수 있음을 인정합니다. 별도의 catch 키워드를 사용하면 정상적인 반환이 발생할 때 완전히 건너뛰기가 더 쉬워져 효율성을 높일 수 있습니다. 최대 효율성을 원할 경우 범위 또는 기능당 하나만 활성화되도록 범위에 묶을 수 있습니다. , 제 생각에는 거의 제로 비용이 될 것입니다. (아마도 소스 코드 파일 이름과 줄 번호는 catch 함수에서 반환되어야 합니까? 그렇게 하는 것은 컴파일 시간에 저렴하고 사람들이 지금 전체 스택 추적을 요구하는 몇 가지 이유를 피할 수 있습니다.)

어느 쪽이든 반복적인 오류 처리가 함수 내의 한 곳에서 효과적으로 처리되도록 허용하고 위의 rsc의 설명에 따라 현재 사례의 최악의 측면 중 하나인 IMHO인 오류 처리를 라이브러리 기능으로 쉽게 제공할 수 있습니다. 오류 처리의 번거로움은 올바른 처리보다 "오류 반환"을 조장하는 경향이 있습니다. 나 자신도 그 문제로 많이 고생한다는 것을 알고 있습니다.

@thejerf 이 제안에 대한 Ian의 요점 중 일부는 함수가 컨텍스트를 추가하거나 반환하는 오류를 조작하는 것을 방해하지 않고 오류 상용구를 해결하는 방법을 탐색하는 것입니다.

오류 처리를 try 및 catch 것은 그 목표에 반하는 것처럼 보이지만 일반적으로 추가하려는 세부 정보 종류에 따라 다릅니다.

최소한, 좀 더 현실적인 예시로 어떻게 작동하는지 보고 싶습니다.

내 제안의 요점은 컨텍스트를 추가하거나 오류를 조작할 수 있도록 하는 것입니다. 여기서 컨텍스트를 계속해서 반복하는 것과 관련된 대부분의 제안보다 프로그래밍 방식으로 더 정확하다고 생각하는 방식으로 추가 컨텍스트를 추가하려는 욕구를 억제합니다. .

원래 예제를 다시 작성하려면

func Chdir(dir string) error {
    if e := syscall.Chdir(dir); e != nil {
        return &PathError{"chdir", dir, e}
    }
    return nil
}

로 나온다

func Chdir(dir string) error {
    catch func(e error) {
        return &PathError{"chdir", dir, e}
    }

    try syscall.Chdir(dir)
    return nil
}

이 예제가 실제로 이러한 제안 중 하나에 대해 너무 사소하다는 점을 제외하고는 이 경우 원래 기능을 그대로 둡니다.

개인적으로 나는 원래의 Chdir 기능이 애초에 문제라고 생각하지 않습니다. 나는 하나의 오류 기능이 아닌 장기간 반복되는 오류 처리로 인해 기능에 잡음이 있는 경우를 해결하기 위해 특별히 조정하고 있습니다. 또한 가능한 모든 사용 사례에 대해 문자 그대로 다른 작업을 수행하는 기능이 있는 경우 이미 얻은 것을 계속 작성하는 것이 정답일 수 있습니다. 그러나 나는 그것이 일반적인 경우라면 애초에 불만이 제기되지 않았을 것이라는 근거에서 이것이 대부분의 사람들에게 단연코 드문 경우라고 생각합니다. 오류를 확인하는 소음은 사람들이 함수에서 "대부분 동일한 작업"을 계속해서 수행하기를 원하기 때문에 정확히 중요합니다.

나는 또한 사람들이 원하는 대부분이 충족될 것이라고 생각합니다.

func SomethingBigger(dir string) (interface{}, error) {
     catch func (e error, filename string, lineno int) {
         return PackageSpecificError{e, filename, lineno, dir}
     }

     x := try Something()

     if x == true {
         try SomethingElse()
     } else {
         a, b = try AThirdThing()
     }

     return whatever, nil
}

하나의 if 문을 신경쓰기에는 너무 작아서 보기 좋게 만들려고 하는 문제를 없애고 A가 : 그것은 실제로 매우 드문 경우이고 B: 이 경우에 상용구 오버헤드는 고유 처리 코드의 복잡성에 비해 실제로 그렇게 중요하지 않습니다. 아마도 문제는 해결책이 있는 것으로 축소될 수 있습니다.

나도 진짜 보고싶다

func packageSpecificHandler(f string) func (err error, filename string, lineno int) {
    return func (err error, filename string, lineno int) {
        return &PackageSpecificError{"In function " + f, err, filename, lineno}
    }
}

 func SomethingBigger(dir string) (interface{}, error) {
     catch packageSpecificHandler("SomethingBigger")

     ...
 }

또는 그와 동등한 것이 가능합니다.

그리고, 페이지에 있는 모든 제안 중... 이것은 여전히 ​​Go처럼 보이지 않습니까? 현재의 바둑보다 바둑과 더 비슷해 보입니다.

솔직히 말해서, 내 전문적인 엔지니어링 경험의 대부분은 PHP에 대한 것이지만(나는 알고 있습니다) Go의 주요 매력은 항상 가독성이었습니다. 나는 PHP의 일부 측면을 즐기지만 가장 경멸하는 부분은 "최종" "추상" "정적" 넌센스이며 한 가지 작업을 수행하는 코드 조각에 지나치게 복잡한 개념을 적용하는 것입니다.

이 제안을 보고 나는 한 조각을 보고 그 코드 조각이 말하고/하고 있는 것에 대해 두 번 이해하고 정말로 "생각"해야 하는 느낌에 대한 즉각적인 플래시백을 주었습니다. 나는 이 코드를 읽을 수 있고 언어에 실제로 추가되지 않는다고 생각합니다. 내 첫 번째 본능은 왼쪽을 보는 것이며 이것은 항상 nil 반환한다고 생각합니다. 그러나 이 변경으로 인해 코드의 동작을 결정하기 위해 왼쪽과 오른쪽을 살펴봐야 합니다. 이는 더 많은 시간을 읽고 더 많은 정신적 모델을 의미합니다.

그러나 이것이 Go에서 오류 처리를 개선할 여지가 없다는 것을 의미하지는 않습니다.

이 전체 스레드를 (아직) 읽지 않아서 죄송합니다(매우 깁니다). 하지만 사람들이 대체 구문을 버리는 것을 보았으므로 제 아이디어를 공유하고 싶습니다.

a, err := helloWorld(); err? {
  return fmt.Errorf("helloWorld failed with %s", err)
}

이것을 무효화하는 위의 것을 놓치지 않기를 바랍니다. 언젠가는 모든 댓글을 다 처리할 것을 약속합니다. :)

연산자는 error 유형에서만 허용되어야 유형 변환 시맨틱 혼란을 피할 수 있습니다.

흥미 롭습니다 , 주나요 ?

if a, err := helloWorld(); err != nil {
  return fmt.Errorf("helloWorld failed with %s", err)
}

a 가 이스케이프되도록 허용하는 반면 현재 상태에서는 then 및 else 블록으로 범위가 지정됩니다.

@object88 맞습니다 . 변화는 미묘하고 미학적이며 주관적입니다. 개인적으로 이 주제에 대해 Go 2에서 원하는 것은 미묘한 가독성 변화입니다.

개인적으로 라인이 if 로 시작하지 않고 !=nil 필요하지 않기 때문에 더 읽기 쉽습니다. 변수는 (대부분?) 다른 줄에 있는 왼쪽 가장자리에 있습니다.

a 의 범위에 대한 좋은 점, 나는 그것을 고려하지 않았습니다.

이 문법의 다른 가능성을 고려하면 이것이 가능한 것 같습니다.

err := helloWorld(); err? {
  return fmt.Errorf("error: %s", err)
}

그리고 아마도

helloWorld()? {
  return fmt.Errorf("hello world failed")
}

그것은 아마도 그것이 무너지는 곳일 것입니다.

오류를 반환하는 것은 Go의 모든 함수 호출의 일부여야 하므로 다음과 같이 상상할 수 있습니다.
```
a := helloWorld(); 잘못? {
return fmt.Errorf("helloWorld 실패: %s", 오류)
}

실제 예외 처리는 어떻습니까? 제 말은 시도하고, 잡다, 마침내 많은 현대 언어처럼 하시겠습니까?

아니요, 코드를 암시적이고 불분명하게 만듭니다(실제로는 조금 더 짧음).

2017년 11월 23일 목요일 07:27 Kamyar Miremadi [email protected]
썼다:

실제 예외 처리는 어떻습니까? 내 말은, 시도하고, 잡고, 마침내
대신 많은 현대 언어처럼?

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/golang/go/issues/21161#issuecomment-346529787 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AICzvyy_kGAlcs6RmL8AKKS5deNRU4_5ks5s5PQVgaJpZM4Oi1c-
.

@mpvl 의 WriteToGCS 예제 up-thread 로 돌아가서 커밋/롤백 패턴이 Go의 오류 처리에서 주요 변경 사항을 보증할 만큼 충분히 일반적이지 않다는 것을 (다시) 제안하고 싶습니다. 함수에서 패턴을 캡처하는 것은 어렵지 않습니다( 놀이터 링크 ):

func runWithCommit(f, commit func() error, rollback func(error)) (err error) {
    defer func() {
        if r := recover(); r != nil {
            rollback(fmt.Errorf("panic: %v", r))
            panic(r)
        }
    }()
    if err := f(); err != nil {
        rollback(err)
        return err
    }
    return commit()
}

그런 다음 예제를 다음과 같이 작성할 수 있습니다.

func writeToGCS(ctx context.Context, bucket, dst string, r io.Reader) error {
    client, err := storage.NewClient(ctx)
    if err != nil {
        return err
    }
    defer client.Close()

    w := client.Bucket(bucket).Object(dst).NewWriter(ctx)
    return runWithCommit(
        func() error { _, err := io.Copy(w, r); return err },
        func() error { return w.Close() },
        func(err error) { _ = w.CloseWithError(err) })
}

더 간단한 솔루션을 제안합니다.

func someFunc() error {
    ^err := someAction()
    ....
}

다중 다중 함수 반환의 경우:

func someFunc() error {
    result, ^err := someAction()
    ....
}

그리고 여러 반환 인수의 경우:

func someFunc() (result Result, err error) {
    var result Result
    params, ^err := someAction()
    ....
}

^ 기호는 매개변수가 nil이 아닌 경우 반환을 의미합니다.
기본적으로 "오류가 발생하면 스택 위로 이동"

이 방법의 단점이 있습니까?

@gladkikhartem
오류가 반환되기 전에 어떻게 수정합니까?

@urandom
오류를 래핑하는 것은 내 생각에 명시적으로 수행되어야 하는 중요한 작업입니다.
Go 코드는 마법이 아니라 가독성에 관한 것입니다.
오류 래핑을 더 명확하게 유지하고 싶습니다.

하지만 동시에 많은 정보를 담고 있지 않고 공간만 차지하는 코드를 없애고 싶습니다.

if err != nil {
    return err
}

바둑의 진부한 표현과 같습니다. 읽고 싶지 않고 그냥 건너뛰고 싶을 뿐입니다.

지금까지 이 토론에서 본 것은 다음과 같은 조합입니다.

1. 구문 장황함 줄이기
2. 컨텍스트를 추가하여 오류 개선

이것은 두 가지 측면을 모두 언급한 @ianlancetaylor 의 원래 문제 설명과

1. 구문의 장황함 감소

편집/확장된 이후로 여기에 보고하는 원래 형식에서도 @gladkikhartem 의 아이디어가 듭니다 .

 result, ^ := someAction()

func의 맥락에서:

func getOddResult() (int, error) {
    result, ^ := someResult()
    if result % 2 == 0 {
          return result + 1, nil
    }
    return result, nil
}

이 짧은 구문 또는 @gladkikhartem 이 err^ 로 제안한 형식은 문제(1)의 구문 상세도 부분을 처리합니다.

2. 오류 컨텍스트

두 번째 부분의 경우 컨텍스트를 더 추가하면 지금은 완전히 잊어버릴 수도 있고 나중에 특별한 contextError 유형이 사용되는 경우 각 오류에 스택 추적을 자동으로 추가하도록 제안할 수도 있습니다. 이러한 새로운 기본 오류 유형은 전체 또는 짧은 스택 추적( GO_CONTEXT_ERROR=full 상상)을 제공할 수 있으며 error 인터페이스와 호환되는 동시에 최상위 호출 스택에서 최소한 함수 및 파일 이름을 추출할 수 있는 가능성을 제공합니다. 기입.

contextError 사용할 때 Go는 어떻게든 오류가 생성된 정확한 지점에 호출 스택 추적을 첨부해야 합니다.

다시 func 예를 들면 다음과 같습니다.

func getOddResult() (int, contextError) {
    result, ^ := someResult() // here a 'contextError' is created; if the error received from 'someResult()' is also a `contextError`, the two are nested
    if result % 2 == 0 {
          return result + 1, nil
    }
    return result, nil
}

유형만 error 에서 contextError 로 변경되었으며 다음과 같이 정의할 수 있습니다.

type contextError interface {
    error
    Stack() []StackEntry
    Cause() contextError
}

(이 Stack() 가 https://golang.org/pkg/runtime/debug/#Stack과 어떻게 다른지 주목하세요. 여기에서 고루틴 호출 스택의 바이트가 아닌 버전을 원하기 때문입니다.)

Cause() 메서드는 중첩의 결과로 nil 또는 이전 contextError 를 반환합니다.

나는 이와 같은 스택을 운반하는 것의 잠재적인 메모리 의미를 매우 잘 알고 있으므로 1개 또는 몇 개의 추가 항목만 포함하는 기본 짧은 스택을 가질 가능성을 암시했습니다. 개발자는 일반적으로 개발/디버그 버전에서 전체 추적을 활성화하고 그렇지 않으면 기본값(짧은 스택 추적)을 그대로 둡니다.

선행 기술:

• https://godoc.org/github.com/pkg/errors (이 패키지를 광범위하게 알지 못하거나 모델링해야 한다고 제안하지만 가장 많이 사용/알려진 패키지 중 하나입니다)

그냥 생각을위한 음식.

@gladkikhartem @ gdm85

나는 당신이 이 제안의 요점을 놓치고 있다고 생각합니다. Ian의 원래 게시물에 따르면:

오류를 무시하는 것은 이미 쉽습니다(아마도 너무 쉽습니다)(#20803 참조). 오류 처리에 대한 많은 기존 제안은 수정되지 않은 오류를 반환하는 것을 더 쉽게 만듭니다(예: #16225, #18721, #21146, #21155). 추가 정보와 함께 오류를 더 쉽게 반환할 수 있는 사람은 거의 없습니다.

수정되지 않은 오류를 반환하는 것은 종종 잘못된 것이며 일반적으로 최소한 도움이 되지 않습니다. 우리는 신중한 오류 처리를 권장합니다. "수정되지 않은 반품" 사용 사례만 처리하면 인센티브가 잘못된 방향으로 편향될 수 있습니다.

@bcmills 컨텍스트(스택 추적 형식)가 추가되는 경우 추가 정보와 함께 오류가 반환됩니다. 사람이 읽을 수 있는 메시지(예: "레코드 삽입 중 오류")를 첨부하면 "주의 깊은 오류 처리"로 간주됩니까? 호출 스택의 어느 지점에서 이러한 메시지를 추가해야 하는지 결정하는 방법은 무엇입니까(각 함수, 상단/하단 등)? 오류 처리 개선 사항을 코딩하는 동안 이러한 질문은 모두 일반적인 질문입니다.

"return unmodified"는 기본적으로 "return unmodified with stacktrace"로 위에서 설명한 대로 대응할 수 있으며 (반응 스타일에서) 필요에 따라 사람이 읽을 수 있는 메시지를 추가할 수 있습니다. 사람이 읽을 수 있는 메시지를 추가하는 방법을 지정하지는 않았지만 몇 가지 아이디어에 대해 pkg/errors 에서 래핑이 어떻게 작동하는지 볼 수 있습니다.

"수정되지 않은 오류를 반환하는 것은 종종 잘못된 것입니다.": 따라서 나는 현재 해로운 것으로 지적되는 동일한 사용 사례인 게으른 사용 사례에 대한 업그레이드 경로를 제안합니다.

@bcmills
나는 오류가 항상 처리되거나 명시적으로 무시되어야 한다는 #20803에 100% 동의합니다(그리고 이것이 이전에 수행되지 않은 이유를 모르겠습니다...)
예, 저는 제안의 요점을 다루지 않았으며 그럴 필요도 없습니다. 의도가 결과와 일치하지 않기 때문에 이면의 의도가 아니라 제안된 실제 솔루션에 관심이 있습니다. 그리고 내가 볼 때 || 그런 || 제안되는 것들 - 그것은 나를 정말로 슬프게 만듭니다.

오류 코드 및 오류 메시지와 같은 정보를 오류에 포함하는 것이 쉽고 투명하다면 - 신중한 오류 처리를 권장할 필요가 없습니다 - 사람들이 스스로 할 것입니다.
예를 들어 error를 별칭으로 만듭니다. 우리는 어떤 종류의 물건도 반환할 수 있고 캐스팅 없이 함수 외부에서 사용할 수 있습니다. 삶을 훨씬 더 쉽게 만들 것입니다.

나는 Go가 나에게 오류를 처리하도록 상기시켜주는 것을 좋아하지만 디자인이 나에게 의심스러운 것을 권장하는 것은 싫어합니다.

@gdm85
스택 추적을 오류에 자동으로 추가하는 것은 끔찍한 생각입니다. Java 스택 추적만 보면 됩니다.
오류를 스스로 감쌀 때 - 탐색하고 무엇이 잘못되었는지 이해하는 것이 훨씬 더 쉽습니다. 감싸는 것이 포인트입니다.

@gladkikhartem 나는 "자동 래핑"의 형태가 탐색하기에 훨씬 더 나쁠 것이고 무엇이 잘못되고 있는지 이해하는 데 도움이 될 것이라는 데 동의하지 않습니다. 나는 또한 당신이 자바 스택 트레이스에서 언급하는 것을 정확히 이해하지 못합니다(예외라고 생각합니까? 미학적으로 추악합니까? 특정 문제는 무엇입니까?). 그러나 건설적인 방향으로 논의하기 위해: "신중하게 처리된 오류"의 좋은 정의는 무엇입니까?

Go 모범 사례(어느 정도 정식적일 수 있음)에 대한 이해를 높이고 현재 상황에서 개선을 위한 제안을 하는 데 그러한 정의가 핵심일 수 있다고 느끼기 때문에 둘 다에게 요청합니다.

@gladkikhartem 이 제안이 이미 if err != nil { return err } 단순화에 대한 여러 제안이 이미 있으며 특정 사례만 개선하는 구문을 논의하는 곳입니다. 감사 해요.

@ianlancetaylor
토론을 방해했다면 죄송합니다.

오류에 컨텍스트 정보를 추가하려면 다음 구문을 사용하는 것이 좋습니다.
(그리고 쉬운 컨텍스트 추출을 위해 하나의 기능에 대해 하나의 오류 유형만 사용하도록 강제)

type MyError struct {
    Type int
    Message string
    Context string
    Err error
}

func VeryLongFunc() error {
    var err MyError
    err.Context = "general function context"


   result, ^err.Err := someAction() {
       err.Type = PermissionError
       err.Message = fmt.SPrintf("some action has no right to access file %v: ", file)
   }

    // in case we need to make a cleanup after error

   result, ^err.Err := someAction() {
       err.Type = PermissionError
       err.Message = fmt.SPrintf("some action has no right to access file %v: ", file)
       file.Close()
   }

   // another variant with different symbol and return statement

   result, ?err.Err := someAction() {
       err.Type = PermissionError
       err.Message = fmt.SPrintf("some action has no right to access file %v: ", file)
       return err
   }

   // using original approach

   result, err.Err := someAction()
   if err != nil {
       err.Type = PermissionError
       err.Message = fmt.SPrintf("some action has no right to access file %v: ", file)
       return err
   }
}

func main() {
    err := VeryLongFunc()
    if err != nil {
        e := err.(MyError)
        log.Print(e.Error(), " in ", e.Dir)
    }
}

^ 기호는 오류 매개변수를 표시하고 "someAction() { }"에 대한 오류 처리와 함수 정의를 구별하는 데 사용됩니다.
오류가 수정되지 않은 상태로 반환되면 { }를 생략할 수 있습니다.

"주의 깊은 오류 처리"를 더 잘 정의하기 위해 내 자신의 초대에 응답할 리소스를 더 추가합니다.

• https://groups.google.com/forum/#!topic/golang -nuts/dkcNS4ieIpQ
• https://blog.golang.org/errors-are-values
• https://dave.cheney.net/2016/04/27/dont-just-check-errors-handle-them-gracefully

현재 접근 방식이 지루하지만 한 줄의 if 문이 작동할 수 있지만 대안보다 덜 혼란스럽다고 생각합니다. 아마도?

blah, err := doSomething()
if err != nil: return err

...또는...

blah, err := doSomething()
if err != nil: return &BlahError{"Something",err}

누군가가 이미 이 문제를 제기했을 수도 있지만, 많은 게시물이 있으며 저는 그 중 많은 부분을 읽었지만 전부는 아닙니다. 즉, 개인적으로 암시적인 것보다 명시적인 것이 더 낫다고 생각합니다.

저는 철도 지향 프로그래밍의 팬이었습니다. 아이디어는 Elixir의 with 문에서 나왔습니다.
else 블록은 e == nil 단락되면 실행됩니다.

다음은 의사 코드에 대한 제 제안입니다.

func Chdir(dir string) (e error) {
    with e == nil {
            e = syscall.Chdir(dir)
            e, val := foo()
            val = val + 1
            // something else
       } else {
           printf("e is not nil")
           return
       }
       return nil
}

@ardhitama "With"가 "Try" 문과 같고 "Else"가 "Catch"와 같다는 점을 제외하고 이것은 Try catch와 같지 않습니까?
Java 또는 C#과 같은 예외 처리를 구현하지 않는 이유는 무엇입니까?
프로그래머가 해당 함수에서 예외를 처리하지 않으려는 경우 바로 지금 진행 중이며 해당 함수의 결과로 이를 반환합니다. 여전히 프로그래머가 원하지 않고 실제로 필요하지 않은 경우 예외를 처리하도록 강제할 방법은 없지만 여기서 얻은 것은 코드를 보기 흉하게 만드는 if err!=nil 문이 많이 있습니다. 읽을 수 없습니다(많은 소음). Try Catch finally 문은 다른 프로그래밍 언어에서 처음 발명된 이유가 아닐까요?

그래서 Go Authors는 고집을 부리지 않으려고 "노력"하면 좋을 것 같아요!! 다음 버전에서 "Try Catch finally" 문을 소개하면 됩니다. 감사합니다.

@KamyarM
Go에는 예외가 없기 때문에 go에서 예외 처리를 도입할 수 없습니다.
Go에서 try{} catch{}를 도입하는 것은 C에서 try{} catch{}를 도입하는 것과 같습니다. 완전히 잘못된 것 입니다.

@ianlancetaylor
Go 오류 처리를 전혀 변경하지 않고 한 줄 오류 처리를 위해 이와 같이 gofmt 도구를 변경하는

err := syscall.Chdir(dir)
    if err != nil {return &PathError{"chdir", dir, err}}
err = syscall.Chdir(dir2)
    if err != nil {return err}

이전 버전과 호환되며 현재 프로젝트에 적용할 수 있습니다.

예외는 데코레이팅된 goto 문으로, 호출 스택을 호출 그래프로 전환하며 대부분의 심각한 비학문 프로젝트에서 사용을 제한하거나 제한하는 데는 그럴만한 이유가 있습니다. 상태 저장 개체는 스택 위로 임의로 제어를 전송한 다음 명령 실행을 재개하는 메서드를 호출합니다.

@KamyarM 본질적으로

왜요?

1. with 문 내부의 표현식은 새 var를 선언할 수 없으므로 의도가 블록 외부 변수를 평가하는 것임을 명시적으로 나타냅니다.
2. with 내부의 명령문은 try 및 catch 블록 내부처럼 작동합니다. 실제로 최악의 시나리오에서 with 의 조건을 평가해야 하는 각 다음 명령에서 속도가 느려질 것입니다.
3. 의도적으로 의도는 과도한 if 를 제거하고 핸들러가 항상 로컬이기 때문에 예외 핸들러를 생성하지 않는 것입니다( with 의 표현식 및 else 블록).
4. throw 때문에 스택을 풀 필요가 없습니다.

추신. 내가 틀렸다면 저를 수정하십시오.

@ardhitama
with 문은 try catch 만큼 보기 흉하고 일반적인 코드 흐름에 들여쓰기 수준을 도입한다는 점에서 KamyarM이 옳습니다.
각 오류를 개별적으로 수정하려는 원래 제안의 아이디어는 언급조차 하지 않았습니다. try catch , with 또는 문을 함께 그룹화하는 다른 방법으로는 우아하게 작동하지 않습니다.

@gladkikhartem
예, 따라서 대신 "철도 지향 프로그래밍"을 채택하고 명시성을 제거하지 않으려고 제안합니다. 문제를 공격하는 또 다른 각도일 뿐입니다. 다른 솔루션은 컴파일러가 자동으로 if err != nil 를 쓰지 못하도록 하여 문제를 해결하려고 합니다.

with 또한 오류 처리뿐만 아니라 다른 제어 흐름에도 유용할 수 있습니다.

@gladkikhartem
Try Catch Finally 블록이 아름답다고 생각합니다. If err!=nil ... 는 실제로 못생긴 코드입니다.

Go는 프로그래밍 언어일 뿐입니다. 다른 많은 언어가 있습니다. 나는 바둑 커뮤니티의 많은 사람들이 그것을 자신들의 종교처럼 보고 실수를 변경하거나 인정하지 않는다는 것을 알게 되었습니다. 이것은 잘못된 것입니다.

@gladkikhartem

Go Authors에서 Go++, Go# 또는 GoJava라고 부르고 거기에 Try Catch Finally 소개하면 괜찮습니다. ;)

@KamyarM

불필요한 변경을 피하는 것은 모든 엔지니어링 노력에 필수적입니다. 사람들이 이러한 맥락에서 변화라고 말할 때, 실제로는 _더 나은 방향으로의 변화_를 의미하며, 전제를 의도한 결론으로 ​​안내하는 _인수_를 통해 효과적으로 전달합니다.

_그냥 마음을 여세요!_ 호소력이 설득력이 없습니다. 아이러니하게도 대부분의 프로그래머가 고대의 투박한 것으로 보는 것을 _새롭고 개선된_ 것이라고 말하려고 합니다.

Go 커뮤니티에서 이전 실수에 대해 토론하는 제안과 토론도 많이 있습니다. 그러나 Go는 프로그래밍 언어일 뿐이라는 말씀에 동의합니다. Go 웹사이트와 다른 곳에서 그렇게 말하고 있으며, 나는 그것을 확인시켜준 몇몇 사람들과도 이야기를 나눴습니다.

나는 바둑 커뮤니티의 많은 사람들이 그것을 자신들의 종교처럼 보고 실수를 변경하거나 인정하지 않는다는 것을 알게 되었습니다.

바둑은 학문적 연구를 기반으로 합니다. 개인적인 의견은 중요하지 않습니다.

Microsoft C# 컴파일러의 수석 개발자조차도 _예외_가 오류를 관리하는 나쁜 방법이라는 것을 공개적으로 인정하면서 Go/Rust 모델을 더 나은 대안으로 높이 평가했습니다. http://joeduffyblog.com/2016/02/07/the-error-model/

확실히 Go의 오류 모델을 개선할 여지가 있지만 몇 가지 의심스러운 이점에 대한 대가로 엄청난 복잡성을 추가하기 때문에 예외와 같은 솔루션을 채택하는 것은 아닙니다.

@Dr-Terrible 기사 주셔서 감사합니다.

그러나 GoLang을 학문적 언어로 언급한 곳을 찾지 못했습니다.

Btw, 이 예에서 내 요점을 명확히 하기 위해

func Execute() error {
    err := Operation1()
    if err!=nil{
        return err
    }

    err = Operation2()
    if err!=nil{
        return err
    }

    err = Operation3()
    if err!=nil{
        return err
    }

    err = Operation4()
    return err
}

다음과 같이 C#에서 예외 처리를 구현하는 것과 유사합니다.

         public void Execute()
        {

            try
            {
                Operation1();
            }
            catch (Exception)
            {
                throw;
            }
            try
            {
                Operation2();
            }
            catch (Exception)
            {
                throw;
            }
            try
            {
                Operation3();
            }
            catch (Exception)
            {
                throw;
            }
            try
            {
                Operation4();
            }
            catch (Exception)
            {
                throw;
            }
        }

그것은 C#에서 예외 처리의 끔찍한 방법이 아닙니까? 내 대답은 예입니다. 나는 당신에 대해 모릅니다! Go에서는 다른 선택이 없습니다. 그것은 그 끔찍한 선택 또는 고속도로입니다. 이것이 GO의 방식이며 선택의 여지가 없습니다.

그건 그렇고 당신이 공유한 기사에서도 언급했듯이 모든 언어는 추가 구문 없이 Go와 같은 오류 처리를 구현할 수 있으므로 Go는 실제로 혁신적인 오류 처리 방법을 구현하지 않았습니다. 오류 처리 방법이 없으므로 오류 처리를 위해 If 문을 사용하는 것으로 제한됩니다.

Btw, GO에는 Try Catch Finally 와 유사한 권장되지 않는 Panic, Recover , Defer 있다는 것을 알고 있지만 제 개인적인 의견으로는 Try Catch Finally 구문이 훨씬 깨끗하고 조직화된 예외 처리 방법입니다.

@닥터 끔찍

또한 다음을 확인하십시오.
https://github.com/manucorporat/try

@KamyarM , 그는 Go가 학문적 언어라고 말한 것이 아니라 학문적 연구를 기반으로 한다고 말했습니다. Go에 대한 기사도 아니지만 Go에서 사용하는 오류 처리 패러다임을 조사합니다.

manucorporat/try 작동하는 것을 발견하면 코드에서 사용하십시오. 그러나 언어 자체에 try/catch 를 추가하는 비용(성능, 언어 복잡성 등)은 절충할 가치가 없습니다.

@KamyarM
당신의 예는 정확하지 않습니다. 에 대한 대안

    err := Operation1()
    if err!=nil {
        return err
    }
    err = Operation2()
    if err!=nil{
        return err
    }
    err = Operation3()
    if err!=nil{
        return err
    }
    return Operation4()

될거야

            Operation1();
            Operation2();
            Operation3();
            Operation4();

이 예에서는 예외 처리가 훨씬 더 나은 옵션으로 보입니다. 이론상으로는 좋아야 하지만 실제로는
엔드포인트에서 발생한 각 오류에 대해 정확한 오류 메시지로 응답해야 합니다.
Go의 전체 애플리케이션은 일반적으로 50% 오류 처리입니다.

         err := Operation1()
    if err!=nil {
        log.Print("input error", err)
                fmt.Fprintf(w,"invalid input")
        w.WriteHeader(http.StatusBadRequest)
        return
    }
    err = Operation2()
    if err!=nil{
        log.Print("controller error", err)
                fmt.Fprintf(w,"operation has no meaning in this context")
        w.WriteHeader(http.StatusBadRequest)
        return
    }
    err = Operation3()
    if err!=nil{
        log.Print("database error", err)
                fmt.Fprintf(w,"unable to access database, try again later")
        w.WriteHeader(http.StatusServiceUnavailable)
        return
    }

그리고 사람들이 try catch와 같은 강력한 도구를 갖게 된다면 조심스러운 오류 처리를 위해 도구를 남용할 것이라고 100% 확신합니다.

학계를 거론하는 것도 흥미롭지만 바둑은 실무 경험을 통해 얻은 교훈의 집합체다. 목표가 잘못된 오류 메시지를 반환하는 잘못된 API를 작성하는 것이라면 예외 처리가 올바른 방법입니다.

그러나 내 요청에 잘못된 형식의 JSON request body 가 포함된 경우 invalid HTTP header 오류를 원하지 않습니다. 예외 처리는 그들을.

대규모 API 적용 범위의 경우 의미 있는 오류 처리를 달성하기에 충분한 오류 컨텍스트를 제공하는 것은 불가능합니다. 좋은 응용 프로그램은 Go에서 50% 오류 처리이고 오류 처리를 위해 로컬이 아닌 제어 전송이 필요한 언어에서는 90%여야 하기 때문입니다.

@gladkikhartem

언급한 대체 방법은 C#으로 코드를 작성하는 올바른 방법입니다. 4줄의 코드로 행복한 실행 경로를 보여줍니다. if err!=nil 소음이 없습니다. 예외가 발생하면 해당 예외를 처리하는 함수는 Try Catch Finally 사용하여 처리할 수 있습니다(같은 함수 자체 또는 호출자 또는 호출자의 호출자 또는 호출자의 호출자의 호출자의 호출자일 수 있습니다. ... 또는 응용 프로그램에서 처리되지 않은 모든 오류를 처리하는 이벤트 처리기 프로그래머는 다른 선택을 할 수 있습니다.)

err := Operation1()
    if err!=nil {
        log.Print("input error", err)
                fmt.Fprintf(w,"invalid input")
        w.WriteHeader(http.StatusBadRequest)
        return
    }
    err = Operation2()
    if err!=nil{
        log.Print("controller error", err)
                fmt.Fprintf(w,"operation has no meaning in this context")
        w.WriteHeader(http.StatusBadRequest)
        return
    }
    err = Operation3()
    if err!=nil{
        log.Print("database error", err)
                fmt.Fprintf(w,"unable to access database, try again later")
        w.WriteHeader(http.StatusServiceUnavailable)
        return
    }

간단해 보이지만 어려운 일입니다. 내 생각에 시스템 오류, 사용자 오류(최선의 의도가 없을 수도 있는 사용자에게 내부 상태 누출 없이) 및 HTTP 코드를 전달하는 사용자 지정 오류 유형을 함께 던질 수 있습니다.

func Chdir(dir string) error {
    if e := syscall.Chdir(dir); e != nil {
        return &PathError{"chdir", dir, e}
    }
    return nil
}

하지만 시도해봐

func Chdir(dir string) error {
    return  syscall.Chdir(dir) ? &PathError{"chdir", dir, err}:nil;
}

func Chdir(dir string) error {
    return  syscall.Chdir(dir) ? &PathError{"chdir", dir, err};
}



md5-9bcd2745464e8d9597cba6d80c3dcf40



```go
func Chdir(dir string) error {
    n , _ := syscall.Chdir(dir):
               // something to do
               fmt.Println(n)
}

그것들 모두는 독자를 위해 일을 단순화하지 않는 일종의 불분명한 마법을 포함하고 있습니다. 앞의 두 예에서 err 는 일종의 유사 키워드 또는 자발적으로 발생하는 변수가 됩니다. 후자의 두 가지 예에서는 : 연산자가 무엇을 하는지 전혀 명확하지 않습니다. 오류가 자동으로 반환됩니까? 연산자의 RHS는 단일 명령문입니까, 아니면 블록입니까?

FWIW, return newPathErr("chdir", dir, syscall.Chdir(dir)) 수행할 수 있도록 래퍼 함수를 ​​작성하고 세 번째 매개변수가 nil이면 자동으로 nil 오류를 반환합니다. :-)

IMO, "Go에서 오류 처리 단순화" 및 "추가 컨텍스트 정보와 함께 오류 반환"이라는 목표를 달성하기 위해 내가 본 최고의 제안은 #21732의 @mrkaspa 에서 가져온 것입니다.

a, b, err? := f1()

다음과 같이 확장됩니다.

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

그리고 나는 이것을 공황 상태로 만들 수 있습니다.

a, b, err! := f1()

다음과 같이 확장됩니다.

if err != nil {
   panic(errors.Wrap(err, "failed"))
}

이것은 이전 버전과의 호환성을 유지하고 go에서 오류 처리의 모든 문제점을 수정합니다.

이것은 0이 아닌 값과 오류를 반환하는 bufio 함수와 같은 경우를 처리하지 않지만 다른 반환 값에 관심이 있는 경우 명시적 오류 처리를 수행하는 것이 괜찮다고 생각합니다. 물론 오류가 아닌 반환 값은 해당 유형에 적절한 nil 값이어야 합니다.

? 수정자는 함수와 ! modifier는 일부 주요 기능과 같은 다른 언어에서 assert가 사용되는 장소에 대해 동일한 작업을 수행합니다.

이 솔루션은 매우 간단하고 많은 작업을 수행하지 않는다는 장점이 있지만 이 제안서에 명시된 요구 사항을 충족한다고 생각합니다.

가지고 있는 경우...

func foo() (int, int, error) {
    a, b, err? := f1()
    return a, b, nil
}
func bar() (int, error) {
    a, b, err? := foo()
    return a+b, nil
}

foo 에서 문제가 발생하면 bar 의 호출 사이트에서 의미를 추가하지 않고 오류를 동일한 텍스트로 이중 래핑합니다. 적어도 나는 제안의 errors.Wrap 부분에 반대할 것입니다.

그러나 더 확장하면 이것의 예상되는 결과는 무엇입니까?

func baz() (a, b int, err error) {
  a = 1
  b = 2
  a, b, err? = f1()
  return

a 및 b 가 nil 값으로 재할당됩니까? 만약 그렇다면, 그것은 우리가 피해야 한다고 생각하는 마법입니다. 그들은 이전에 할당된 값을 수행합니까? (나는 명명된 반환 값을 신경 쓰지 않지만 이 제안의 목적을 위해 여전히 고려되어야 합니다.)

@dup2X 네, 언어를 제거합시다. 그 이상이어야 합니다.

@object88 오류가 발생하면 다른 모든 것이 null이 될 것으로 예상하는 것이 당연합니다. 이것은 이해하기 쉽고 마법이 없습니다. 이미 Go 코드에 대한 규칙과 거의 비슷하며 기억할 필요가 거의 없으며 특별한 경우가 없습니다. 가치가 유지되도록 허용하면 상황이 복잡해집니다. 오류 확인을 잊어버린 경우 반환된 값이 실수로 사용될 수 있으며 이 경우 어떤 일이 발생할 수 있습니다. nil에 패닉하는 대신 부분적으로 할당된 구조에서 메서드를 호출하는 것과 같습니다. 프로그래머는 오류가 발생한 경우 특정 값이 반환될 것으로 기대하기 시작할 수도 있습니다. 제 생각에는 엉망이 될 것이고 아무 것도 얻을 수 없을 것입니다.

래핑에 관해서는 기본 메시지가 유용한 것을 제공하지 않는다고 생각합니다. 오류를 함께 연결하는 것이 좋습니다. 예외에 내부 예외가 있는 경우와 같습니다. 라이브러리 깊숙한 곳에서 오류를 디버깅하는 데 매우 유용합니다.

정중하게, 나는 동의하지 않습니다, @creker. 우리는 nil이 아닌 오류의 경우에도 nil이 아닌 반환 값의 Go stdlib에 해당 시나리오의 예가 있으며 실제로 bufio.Reader struct 의 여러 함수와 같이 기능적입니다. Go 프로그래머인 우리는 모든 오류를 확인/처리하도록 적극 권장합니다. nil이 아닌 반환 값과 오류를 얻는 것보다 오류를 무시하는 것이 더 지독하게 느껴집니다. 인용한 경우에 nil을 반환하고 오류를 확인하지 않으면 여전히 잘못된 값으로 작업할 수 있습니다.

그러나 이를 제쳐두고 조금 더 살펴보겠습니다. ? 연산자의 의미는 무엇입니까? error 인터페이스를 구현하는 유형에만 적용할 수 있습니까? 다른 유형에 적용하거나 인수를 반환할 수 있습니까? 오류를 구현하지 않는 유형에 적용할 수 있다면 nil이 아닌 값/포인터에 의해 트리거됩니까? ? 연산자를 둘 이상의 반환 값에 적용할 수 있습니까, 아니면 컴파일러 오류입니까?

@erwbgy
유용한 정보 없이 오류를 반환하려는 경우 컴파일러가 처리되지 않은 모든 오류를 "if err != nil return..."으로 처리하도록 지시하는 것이 훨씬 간단합니다. 예를 들면 다음과 같습니다.

func doStuff() error {
    doAnotherStuff() // returns error
}

func doStuff() error {
    res := doAnotherStuff() // returns string, error
}

그리고 추가 미친 필요가 없습니까? 이 경우 기호.

@object88
여기에 표시된 대부분의 오류 래핑 제안을 실제 코드로 적용하려고 시도했지만 한 가지 주요 문제에 직면했습니다. 코드가 너무 조밀하고 읽을 수 없게 됩니다.
그것이 하는 일은 코드 높이를 위해 코드 너비를 희생하는 것뿐입니다.
if err != nil 을 사용하여 오류를 래핑하면 실제로 더 나은 가독성을 위해 코드를 퍼뜨릴 수 있으므로 오류 래핑을 위해 아무 것도 변경해야 한다고 생각하지 않습니다.

@object88

사이트의 경우 nil을 반환하고 오류를 확인하지 않으면 여전히 잘못된 값으로 작업할 수 있습니다.

그러나 이것은 nil에 대한 패닉과 같은 명백하고 찾기 쉬운 오류를 생성합니다. 오류 시 의미 있는 값을 반환해야 하는 경우 명시적으로 반환해야 하며 어떤 경우에 어떤 값을 사용할 수 있는지 정확히 문서화해야 합니다. 오류 시 변수에서 발생한 임의의 항목을 반환하는 것은 위험하고 미묘한 오류로 이어질 것입니다. 다시 말하지만, 아무것도 얻을 수 없습니다.

@gladkikhartem if err != nil의 문제는 실제 논리가 완전히 손실되어 코드가 성공적인 경로에서 수행하는 작업을 이해하고 모든 오류 처리에 신경 쓰지 않으려면 적극적으로 검색해야 한다는 것입니다. . 여러 줄의 실제 코드가 있고 나머지는 모두 오류 검사에 불과한 많은 C 코드를 읽는 것과 같습니다. 사람들은 심지어 그 모든 것을 감싸고 함수의 끝으로 이동하는 매크로에 의존합니다.

제대로 작성된 코드에서 논리가 어떻게 너무 조밀해질 수 있는지 모르겠습니다. 논리입니다. 코드의 모든 줄에는 원하는 실제 코드가 포함되어 있습니다. 당신이 원하지 않는 것은 상용구의 라인과 라인을 통과하는 것입니다. 도움이 되는 경우 주석을 사용하고 코드를 블록으로 분할합니다. 그러나 그것은 언어가 아니라 실제 코드의 문제처럼 들립니다.

다시 포맷하지 않으면 플레이그라운드에서 작동합니다.

a, b, err := Frob("one string"); if err != nil { return a, b, fmt.Errorf("couldn't frob: %v", err) }
// continue doing stuff with a and b

따라서 원래 제안과 위에서 언급한 다른 많은 제안은 100자에 대한 명확한 약식 구문을 제시하고 gofmt가 줄 바꿈을 추가하고 3줄에 걸쳐 블록을 다시 형식화해야 한다고 주장하는 것을 막으려는 것 같습니다.

따라서 gofmt를 변경하여 다중 라인 블록 주장을 중단하고 위의 라인부터 시작하여 더 짧고 명확하게 만드는 방법을 생각해 낸다고 상상해 봅시다.

세미콜론 앞의 부분(할당)을 변경해야 한다고 생각하지 않습니다. 그래서 우리가 줄일 수 있는 69자를 남깁니다. 그 중 49개는 return 문, 반환할 값, 오류 래핑이며 나는 그 구문을 변경하는 데 많은 가치를 보지 못합니다(예: return 문을 선택 사항으로 만들어 사용자를 혼란스럽게 함).

따라서 밑줄이 코드 덩어리를 나타내는 ; if err != nil { _ } 의 약어를 찾습니다. 나는 어떤 속기가 명시 적으로 포함해야한다고 생각 err 우리가 속기와 함께 오는 남겨 그래서는 전무 비교가 다소 눈에 보이지 않는 만드는 경우에도 명확성을 위해 ; if _ != nil { _ } .

우리가 단일 문자를 사용한다고 잠시 상상해보십시오. 그 캐릭터가 무엇이든 간에 §를 자리 표시자로 선택하겠습니다. 코드 줄은 다음과 같습니다.

a, b, err := Frob("one string") § err return a, b, fmt.Errorf("couldn't frob: %v", err)

기존 할당 구문이나 반환 구문을 변경하거나 보이지 않는 마법이 발생하지 않고 이보다 훨씬 더 나은 작업을 수행할 수 있는 방법이 없습니다. (err을 nil과 비교한다는 사실이 쉽게 명백하지 않다는 점에서 여전히 약간의 마법이 있습니다.)

100자 길이의 줄에 총 12자를 저장하는 88자입니다.

그래서 내 질문은: 정말 할 가치가 있습니까?

편집: 내 요점은 사람들이 Go의 if err != nil 블록을 보고 "우리가 그 쓰레기를 없앨 수 있었으면 좋겠어요"라고 말할 때 그들이 말하는 것의 80-90%는 당신이 본질적으로 가지고 있는 것입니다. error_를 처리하기 위해 할 일. Go의 구문으로 인한 실제 오버헤드는 최소화됩니다.

@lpar , 당신은 내가 위에서 적용한 것과 같은 논리를 대부분 따르고 있으므로 자연스럽게 당신의 추론에 동의합니다. 그러나 나는 당신이 모든 오류를 오른쪽에 배치하는 시각적 매력을 무시한다고 생각합니다.

a, b := Frob("one string")  § err { return ... }

단순한 문자 감소를 넘어선 요인으로 가독성이 높아집니다.

@lpar 거의 쓸모없는 fmt.Errorf 를 제거하고 리턴을 일부 특수 구문으로 변경하고 오류에 호출 스택을 도입하여 실제 컨텍스트가 있고 단순한 미화 문자열이 되지 않도록 하면 더 많은 문자를 저장할 수 있습니다. 그것은 당신에게 이와 같은 것을 남길 것입니다

a, b, err? := Frob("one string")

나에게 Go 오류의 문제는 항상 컨텍스트의 부족이었습니다. 문자열을 반환하고 래핑하는 것은 오류가 실제로 발생한 위치를 확인하는 데 전혀 유용하지 않습니다. 그래서 예를 들어 github.com/pkg/errors 가 저에게 필수품이 되었습니다. 이와 같은 오류를 통해 나는 Go 오류 처리 단순성의 이점과 컨텍스트를 완벽하게 포착하고 정확한 실패 위치를 찾을 수 있게 하는 예외의 이점을 얻습니다.

그리고 예를 있는 그대로 가져오더라도 오류 처리가 오른쪽에 있다는 사실은 가독성을 크게 향상시킨 것입니다. 더 이상 코드의 실제 의미를 이해하기 위해 여러 줄의 상용구를 건너뛸 필요가 없습니다. 오류 처리의 중요성에 대해 원하는 대로 말할 수 있지만 코드를 이해하기 위해 읽을 때는 오류에 대해 신경 쓰지 않습니다. 내가 필요한 것은 성공적인 경로입니다. 그리고 오류가 필요할 때 구체적으로 찾을 것입니다. 오류는 본질적으로 예외적인 경우이며 가능한 한 적은 공간을 차지해야 합니다.

fmt.Errorf 가 errors.Wrap 와 비교하여 "쓸모 없는" 것인지에 대한 질문은 둘 다 동등하게 장황하기 때문에 이 문제와 직교한다고 생각합니다. (실제 응용 프로그램에서는 사용하지 않고 오류와 오류가 발생한 코드 줄도 기록하는 다른 것을 사용합니다.)

따라서 오류 처리가 오른쪽에 있는 것을 정말 좋아하는 사람들이 있다고 생각합니다. Perl과 Ruby를 배경으로 해서라도 그렇게 확신하지 못합니다.

@lpar 호출 스택을 자동으로 캡처하기 때문에 errors.Wrap 합니다. 이러한 오류 메시지가 모두 필요하지 않습니다. 나는 그것이 발생한 장소와 아마도 어떤 인수가 오류를 생성한 함수에 전달되었는지에 대해 더 관심이 있습니다. 당신은 비슷한 일을 하고 있다고 말하기도 합니다. 오류 메시지에 대한 컨텍스트를 제공하기 위해 코드 행을 기록합니다. 오류에 더 많은 컨텍스트를 제공하면서 상용구를 줄이는 방법을 생각할 수 있다는 점을 감안할 때(여기서 거의 제안된 내용입니다).

오른쪽에 있는 오류에 관해서. 나에게 그것은 단순히 장소에 관한 것이 아니라 오류 처리로 흩어져 있는 코드를 읽는 데 걸리는 인지 부하를 줄이는 것입니다. 나는 오류가 너무 중요해서 오류가 발생하는 만큼 많은 공간을 차지하기를 원한다는 주장을 믿지 않습니다. 나는 그들이 가능한 한 멀리 떠나는 것을 실제로 선호합니다. 그들은 주요 이야기가 아닙니다.

@크레커

이것은 잘못된 사용자 입력으로 인해 오류를 생성하는 프로덕션 시스템의 오류보다 사소한 개발자 오류를 설명할 가능성이 더 큽니다. 오류를 확인하는 데 필요한 모든 것이 줄 번호와 파일 경로라면, 방금 코드를 작성했고 무엇이 잘못되었는지 이미 알고 있을 가능성이 있습니다.

@ 예외와 유사하기 때문입니다. 대부분의 경우 호출 스택과 예외 메시지는 오류가 발생한 위치와 원인을 파악하기에 충분합니다. 더 복잡한 경우에는 적어도 오류가 발생한 위치를 알고 있습니다. 예외는 기본적으로 이 이점을 제공합니다. Go를 사용하면 기본적으로 호출 스택을 에뮬레이트하는 오류를 함께 연결하거나 실제 호출 스택을 포함해야 합니다.

올바르게 작성된 코드에서는 대부분의 경우 오류가 예상되기 때문에 행 번호와 파일 경로에서 정확한 원인을 알 수 있습니다. 실제로 발생할 수 있는 준비로 일부 코드를 작성했습니다. 예상하지 못한 일이 발생하면 예, 호출 스택이 원인을 제공하지 않지만 검색 공간을 크게 줄일 수 있습니다.

@처럼

내 경험상 사용자 입력 오류는 거의 즉시 처리됩니다. 실제 문제가 되는 프로덕션 오류는 코드 깊숙한 곳에서 발생하며(예: 서비스가 다운되어 다른 서비스에서 오류가 발생함) 적절한 스택 추적을 얻는 데 매우 유용합니다. 그만한 가치가 있기 때문에 Java 스택 추적은 메시지가 아니라 프로덕션 문제를 디버깅할 때 매우 유용합니다.

@크레커
오류는 값일 뿐이며 함수 입력 및 출력의 일부입니다. 그들은 "예상치 못한" 수 없습니다.
함수에서 오류가 발생한 이유를 찾으려면 테스트, 로깅 등을 사용하십시오.

@gladkikhartem 현실 세계에서는 그렇게 간단하지 않습니다. 예, 함수 서명이 반환 값으로 오류를 포함한다는 점에서 오류를 예상합니다. 그러나 내가 예상하여 언급한 것은 문제가 발생한 이유와 원인을 정확히 알고 있기 때문에 실제로 문제를 해결하기 위해 무엇을 해야 하는지 또는 전혀 해결하지 않기 위해 해야 하는지 알 수 있다는 것입니다. 잘못된 사용자 입력은 일반적으로 오류 메시지를 보는 것만으로도 고칠 수 있습니다. 프로포콜 버퍼를 사용하고 일부 필수 필드가 설정되지 않은 경우, 유선으로 수신하는 모든 항목을 적절하게 검증하면 이는 예상되는 것이며 수정하기가 정말 간단합니다.

이 시점에서 나는 우리가 무엇에 대해 논쟁하는지 더 이상 이해하지 못합니다. 스택 추적 또는 오류 메시지 체인은 올바르게 구현되는 경우 매우 유사합니다. 검색 공간을 줄이고 오류를 재현하고 수정하는 데 유용한 컨텍스트를 제공합니다. 우리에게 필요한 것은 충분한 컨텍스트를 제공하면서 오류 처리를 단순화하는 방법에 대해 생각하는 것입니다. 나는 단순함이 적절한 문맥보다 더 중요하다고 옹호하는 것이 아닙니다.

이것이 Java 인수입니다. 모든 오류 코드를 다른 곳으로 이동하여 볼 필요가 없도록 하십시오. 잘못된 것 같아요. 그렇게 하는 Java의 메커니즘이 크게 실패했기 때문이 아니라 내가 코드를 볼 때 오류가 있을 때 어떻게 동작할지가 모든 것이 작동할 때 어떻게 동작할지만큼이나 중요하기 때문입니다.

아무도 그런 주장을 하지 않습니다. 모든 오류 처리가 한 곳에서 이루어지는 예외 처리와 여기에서 논의되는 내용을 혼동하지 맙시다. 그것을 "대부분 실패"라고 부르는 것은 단지 하나의 의견일 뿐이지만, 나는 Go가 어떤 경우에도 그런 식으로 돌아갈 것이라고 생각하지 않습니다. Go 오류 처리는 단지 다르며 개선할 수 있습니다.

@creker 나는 같은 점을 지적 하려고 시도했고 의미 있고 유용한 오류 메시지로 간주되는 것이 무엇인지 명확히 해달라고 요청했습니다.

사실, 나는 호출 스택과 함수 인수에 대한 대가로 가변 품질 오류 메시지 텍스트(개발자가 그 순간에 그 지식을 가지고 작성하는 편향이 있음)를 제공할 것입니다. 오류 메시지 텍스트( fmt.Errorf 또는 errors.New )를 사용하면 호출 스택/백트레이스를 읽는 동안 소스 코드에서 텍스트를 검색하게 됩니다. 파일/라인 번호( errors.Wrap 등)로 직접 조회하는 것에 해당합니다.

두 가지 다른 스타일이지만 목적은 동일합니다. 즉, 해당 조건에서 런타임에 발생한 일을 머릿속으로 재현하려는 것입니다.

이 주제에서 문제 #19991은 의미 있는 오류를 정의하는 두 번째 스타일에 대한 접근 방식에 대한 유효한 요약을 작성하고 있습니다.

볼 필요가 없도록 모든 오류 코드를 다른 곳으로 이동하십시오.

@lpar , 오류 처리를 오른쪽으로 이동하는 것에 대한 내 요점에 응답하는 경우: 각주/미주(자바)와 부주(내 제안) 간에는 큰 차이가 있습니다. 사이드 노트는 맥락을 잃지 않고 약간의 시선 이동만 필요합니다.

@gdm85

소스 코드에서 텍스트를 검색하게 됩니다.

스택 추적과 연결된 오류 메시지가 유사하다는 것이 정확히 의미했습니다. 둘 다 오류가 발생한 경로를 기록합니다. 메시지의 경우에만 주의 깊게 작성하지 않으면 프로그램의 어느 곳에서나 있을 수 있는 완전히 쓸모없는 메시지로 끝날 수 있습니다. 연쇄 오류의 유일한 이점은 변수 값을 기록하는 기능입니다. 그리고 그마저도 함수 인수 또는 일반적인 변수의 경우 자동화될 수 있으며 적어도 저에게는 오류에서 필요한 거의 모든 것을 다룰 것입니다. 그들은 여전히 ​​값이 될 것입니다. 필요한 경우 여전히 switch를 입력할 수 있습니다. 그러나 어느 시점에서 당신은 아마 그것들을 기록할 것이고 스택 추적을 볼 수 있는 것은 매우 유용합니다.

Go가 공황 상태에서 무엇을 하는지 보세요. 모든 고루틴의 전체 스택 추적을 얻습니다. 오류의 원인을 파악하고 즉시 수정하는 데 몇 번이나 도움이 되었는지 기억나지 않습니다. 그것이 얼마나 쉬운지 나는 종종 놀랐다. 디버거가 필요하지 않을 정도로 전체 언어가 매우 예측 가능하므로 완벽하게 흐릅니다.

Java와 관련된 모든 것에 낙인이 있는 것 같으며 사람들은 종종 어떤 주장도 하지 않습니다. 단지 때문에 나쁘다. 나는 Java의 팬은 아니지만 그런 종류의 추론은 누구에게도 도움이 되지 않습니다.

다시 말하지만, 오류는 개발자가 버그를 수정하는 것이 아닙니다. 이것이 오류 처리의 이점 중 하나입니다. Java 방식은 개발자들에게 이것이 오류 처리라는 것을 가르쳤습니다. 오류는 응용 프로그램 계층과 흐름 계층 너머에 있을 수 있습니다. Go의 오류는 컴파일 시간이 아니라 런타임에 시스템이 취하는 복구 전략을 제어하는 ​​데 일상적으로 사용됩니다.

언어가 스택을 풀고 오류가 발생하기 전에 수행한 모든 작업에 대한 메모리를 잃음으로써 오류의 결과로 흐름 제어를 손상시킬 때 이것은 이해하기 어려울 수 있습니다. 오류는 실제로 Go에서 런타임에 유용합니다. 왜 그들이 줄 번호와 같은 것을 전달해야 하는지 모르겠습니다. 실행 중인 코드는 그것에 대해 거의 신경 쓰지 않습니다.

@처럼

다시 말하지만, 오류는 개발자가 버그를 수정하는 것이 아닙니다.

그것은 완전히 그리고 완전히 잘못된 것입니다. 오류는 바로 그 이유 때문입니다. 그것들에 국한되지는 않지만 주요 용도 중 하나입니다. 오류는 시스템에 문제가 있음을 나타내며 이에 대해 조치를 취해야 합니다. 예상되고 쉬운 오류의 경우 예를 들어 TCP 시간 초과와 같은 복구를 시도할 수 있습니다. 더 심각한 문제의 경우 로그에 덤프하고 나중에 문제를 디버그합니다.

이것이 오류 처리의 이점 중 하나입니다. Java 방식은 개발자들에게 이것이 오류 처리라는 것을 가르쳤습니다.

Java가 당신에게 무엇을 가르쳤는지 모르지만 나는 같은 이유로 예외를 사용합니다 - 런타임에 복구 전략 시스템이 취하는 것을 제어하기 위해서입니다. Go는 오류 처리 측면에서 특별한 것이 없습니다.

언어가 스택을 풀고 오류가 발생하기 전에 수행한 모든 작업에 대한 메모리를 잃음으로써 오류의 결과로 흐름 제어를 손상시키는 경우 이는 이해하기 어려울 수 있습니다.

나를 위한 것이 아니라 누군가를 위한 것일 수도 있다.

오류는 실제로 Go에서 런타임에 유용합니다. 왜 그들이 줄 번호와 같은 것을 전달해야 하는지 모르겠습니다. 실행 중인 코드는 그것에 대해 거의 신경 쓰지 않습니다.

코드에서 버그를 수정하는 데 관심이 있다면 줄 번호를 사용하는 것이 좋습니다. 우리에게 이것에 대해 가르쳐 준 것은 Java가 아닙니다. C는 바로 그 이유 때문에 __LINE__ 와 __FUNCTION__ 를 가지고 있습니다. 당신은 당신의 오류를 기록하고 그것이 발생한 정확한 장소를 기록하기를 원합니다. 그리고 문제가 발생하면 최소한 시작해야 할 것이 있습니다. 복구할 수 없는 오류로 인해 발생한 임의의 오류 메시지가 아닙니다. 그런 종류의 정보가 필요하지 않다면 무시하십시오. 그것은 당신을 다치게하지 않습니다. 그러나 최소한 거기에 있고 필요할 때 사용할 수 있습니다.

왜 여기 사람들이 대화를 예외 대 오류 값으로 계속 옮기는지 이해가 되지 않습니다. 아무도 그런 비교를 하지 않았습니다. 논의된 것은 스택 추적이 매우 유용하고 많은 컨텍스트 정보를 전달한다는 것입니다. 그것이 이해할 수 없다면 아마도 당신은 추적이 존재하지 않는 완전히 다른 세계에 살고 있을 것입니다.

그것은 완전히 그리고 완전히 잘못된 것입니다.

그러나 내가 언급하는 프로덕션 시스템은 여전히 ​​실행 중이며 흐름 제어를 위해 오류를 사용하고 Go로 작성되었으며 오류 전파를 위해 스택 추적을 사용하는 언어의 느린 구현을 대체했습니다.

그것이 이해할 수 없다면 아마도 당신은 추적이 존재하지 않는 완전히 다른 세계에 살고 있을 것입니다.

오류 유형을 반환하는 모든 함수에 대한 호출 스택 정보를 연결하려면 재량에 따라 수행하십시오. 스택 추적은 더 느리고 보안상의 이유로 장난감 프로젝트 외부에서 사용하기에 적합하지 않습니다. 무분별한 오류 전파 전략을 돕기 위해 그들을 Go의 일등 시민으로 만드는 것은 기술적인 파울입니다.

그런 종류의 정보가 필요하지 않다면 무시하십시오. 그것은 당신을 다치게하지 않습니다.

소프트웨어 팽창은 서버가 Go에서 다시 작성되는 이유입니다. 보이지 않는 것은 여전히 ​​파이프라인의 처리량을 저하시킬 수 있습니다.

TCP 시간 초과 및 로그 덤핑 처리에 대한 약간 관련 없는 강의 대신 이 기능을 사용하여 이점을 얻을 수 있는 실제 소프트웨어의 예를 선호합니다.

스택 추적이 더 느림

스택 추적이 오류 경로에서 생성된다는 점을 감안할 때 속도가 얼마나 느린지는 아무도 신경 쓰지 않습니다. 소프트웨어의 정상적인 작동이 이미 중단되었습니다.

보안상의 이유로 장난감 프로젝트 외부에서 사용하기에 부적합

지금까지 단일 프로덕션 시스템이 "보안상의 이유" 또는 그 문제로 인해 스택 추적을 끄는 것을 아직 보지 못했습니다. 반면에 코드가 오류를 생성하는 데 걸린 경로를 빠르게 식별할 수 있다는 것은 매우 유용했습니다. 그리고 이것은 코드 기반에서 작업하는 여러 팀과 전체 시스템에 대한 완전한 지식이 없는 대규모 프로젝트를 위한 것입니다.

보이지 않는 것은 여전히 ​​파이프라인의 처리량을 저하시킬 수 있습니다.

아니, 정말 그렇지 않습니다. 앞서 말했듯이 스택 추적은 오류에 대해 생성됩니다. 소프트웨어에서 지속적으로 이러한 문제가 발생하지 않는 한 처리량은 조금도 영향을 받지 않습니다.

스택 추적이 오류 경로에서 생성된다는 점을 감안할 때 속도가 얼마나 느린지는 아무도 신경 쓰지 않습니다. 소프트웨어의 정상적인 작동이 이미 중단되었습니다.

올바르지 않은.

• 정상 작동의 일부로 오류가 발생할 수 있습니다.
• 오류를 복구할 수 있고 프로그램을 계속할 수 있으므로 성능이 여전히 문제입니다.
• 하나의 루틴을 느리게 하면 행복한 경로에서 작동하는 _are_ 다른 루틴의 리소스가 줄어듭니다.

@object88 실제 프로덕션 코드를 상상해보세요. 얼마나 많은 오류가 생성될 것으로 예상합니까? 나는 별로 생각하지 않을 것이다. 적어도 제대로 작성된 신청서에서는. 고루틴이 사용 중인 루프에 있고 반복할 때마다 오류가 계속 발생한다면 코드에 문제가 있는 것입니다. 하지만 그렇다고 해도 대부분의 Go 응용 프로그램이 IO 바인딩되어 있다는 점을 감안할 때 심각한 문제는 아닐 것입니다.

@처럼

그러나 내가 언급하는 프로덕션 시스템은 여전히 ​​실행 중이며 흐름 제어를 위해 오류를 사용하고 Go로 작성되었으며 오류 전파를 위해 스택 추적을 사용하는 언어의 느린 구현을 대체했습니다.

죄송하지만 제 말과 전혀 상관없는 말도 안되는 문장입니다. 대답하지 않을 것입니다.

스택 추적이 더 느림

더 느리지만 얼마나? 상관이 있나? 나는 그렇게 생각하지 않는다. Go 애플리케이션은 일반적으로 IO 바인딩됩니다. 이 경우 CPU 주기를 추적하는 것은 어리석은 일입니다. CPU를 잡아먹는 Go 런타임에는 훨씬 더 큰 문제가 있습니다. 버그 수정에 도움이 되는 유용한 기능을 버리라는 주장이 아닙니다.

보안상의 이유로 장난감 프로젝트 외부에서 사용하기에 부적합합니다.

존재하지 않는 "보안상의 이유"는 다루지 않겠습니다. 그러나 일반적으로 내부에 저장되는 애플리케이션 추적 및 개발자만 액세스할 수 있음을 상기시켜 드리고 싶습니다. 그리고 함수 이름을 숨기는 것은 어쨌든 시간 낭비입니다. 보안이 아닙니다. 그것에 대해 자세히 설명할 필요가 없기를 바랍니다.

보안상의 이유를 고집한다면 예를 들어 macOS/iOS를 생각해 주셨으면 합니다. 모든 스레드의 스택과 모든 CPU 레지스터의 값을 포함하는 패닉 및 크래시 덤프를 발생시키는 데 문제가 없습니다. 이러한 "보안상의 이유"에 의해 영향을 받는 것을 보지 마십시오.

무분별한 오류 전파 전략을 돕기 위해 그들을 Go의 일등 시민으로 만드는 것은 기술적인 파울입니다.

더 주관적일 수 있습니까? "생각 없는 오류 전파 전략" 어디서 봤어?

소프트웨어 팽창은 서버가 Go에서 다시 작성되는 이유입니다. 보이지 않는 것은 여전히 ​​파이프라인의 처리량을 저하시킬 수 있습니다.

또 얼마나?

TCP 시간 초과 및 로그 덤핑 처리에 대한 약간 관련 없는 강의 대신 이 기능을 사용하여 이점을 얻을 수 있는 실제 소프트웨어의 예를 선호합니다.

이 시점에서 나는 프로그래머가 아닌 누구와도 이야기하고 있는 것 같습니다. 추적은 모든 소프트웨어에 이점이 있습니다. 버그를 수정하는 데 도움이 되는 모든 언어와 모든 유형의 소프트웨어에서 공통적인 기술입니다. 더 자세한 정보를 원하시면 위키피디아를 읽어보세요.

합의 없이 너무 많은 비생산적인 토론을 한다는 것은 이 문제를 해결할 우아한 방법이 없다는 것을 의미합니다.

@object88
Go는 다른 고루틴이 차단 해제될 때까지 기다려야 하기 때문에 모든 고루틴을 추적하려는 경우 스택 추적이 느릴 수 있습니다.
현재 실행 중인 고루틴을 추적하면 그렇게 느리지 않습니다.

@크레커
혜택 모든 소프트웨어를 추적, 그러나 당신이 추적하고있는 무슨에 따라 달라집니다. 대부분의 Go 프로젝트에서 스택 추적은 동시성이 관련되어 있기 때문에 좋은 아이디어가 아니었습니다. 데이터는 앞으로 이동하고 많은 것들이 서로 통신하며 일부 고루틴은 몇 줄의 코드에 불과합니다. 이러한 경우 스택 추적을 갖는 것은 도움이 되지 않습니다.
그렇기 때문에 동일한 스택 추적을 재생성하기 위해 로그에 기록된 컨텍스트 정보로 래핑된 오류를 사용하지만 이는 실제 고루틴 스택이 아니라 애플리케이션 로직 자체에 바인딩됩니다.
내가 할 수 있도록 cat *.log | grep "orderID=xxx"를 입력하고 오류를 일으킨 실제 작업 시퀀스의 스택 추적을 가져옵니다.
Go 컨텍스트가 풍부한 오류의 동시성으로 인해 스택 추적보다 더 가치가 있습니다.

@gladkikhartem 시간을 내어 적절한 논거를 작성

나는 당신의 주장을 이해하고 부분적으로 동의합니다. 그럼에도 불구하고 적어도 5개 이상의 함수 스택을 처리해야 한다는 사실을 알게 되었습니다. 이것은 무슨 일이 일어나고 있고 어디서부터 살펴봐야 하는지 이해할 수 있을 만큼 이미 충분히 큽니다. 그러나 매우 작은 고루틴 스택 추적이 많이 포함된 고도로 동시 실행되는 응용 프로그램에서는 이점이 손실됩니다. 동의합니다.

@크레커

실제 프로덕션 코드를 상상해보세요. 얼마나 많은 오류가 생성될 것으로 예상합니까? [...], Go 애플리케이션의 대부분이 IO 바인딩되어 있다는 점을 감안할 때 심각한 문제는 아닐 것입니다.

IO 바인딩 작업을 언급하는 것이 좋습니다. io.Reader Read 메서드는 EOF에서 정상적인 오류를 반환합니다. 그래서 행복한 길에서 많은 일이 일어날 것입니다.

@urandom

스택 추적은 시스템 프로파일링에 중요한 정보를 무의식적으로 노출합니다.

• 사용자 이름
• 파일 시스템 경로
• 백엔드 데이터베이스 유형/버전
• 거래 흐름
• 객체 구조
• 암호화 알고리즘

평균적인 애플리케이션이 오류 유형에서 스택 프레임을 수집하는 오버헤드를 알아차릴지는 모르겠지만, 성능이 중요한 애플리케이션의 경우 현재 함수 호출 오버헤드로 인해 많은 작은 Go 함수가 수동으로 인라인된다는 것을 말할 수 있습니다. 추적하면 악화됩니다.

Go의 목표는 간단하고 빠른 소프트웨어를 만드는 것이며 추적은 뒤로 물러날 것입니다. 우리는 비 전통적인 오류 유형과 수동 인라인을 조장하는 성능 저하 없이 작은 함수를 작성하고 해당 함수에서 오류를 반환할 수 있어야 합니다.

@크레커

더 이상의 불협화음을 야기하는 예를 제시하지 않겠습니다. 실망을 드려 죄송합니다.

나는 그 이름이 그 기능을 즉시 드러내는 새로운 키워드 "returnif"를 사용하는 것을 제안할 것입니다. 또한 오류 처리보다 더 많은 사용 사례에서 사용할 수 있을 만큼 충분히 유연합니다.

예 1(명명된 반환 사용):

a, err = 무언가(b)
오류 != nil {
반품
}

다음이 될 것입니다:

a, err = 무언가(b)
returnif 오류 != nil

예 2(명명된 반환을 사용하지 않음):

a, err := 뭔가(b)
오류 != nil {
반환, 오류
}

다음이 될 것입니다:

a, err := 뭔가(b)
returnif err != nil { a, err }

명명 된 반환 예제와 관련하여 의미하는 것은 ...

a, err = something(b)
returnif err != nil

@ambernardino
대신 fmt 도구를 업데이트하고 언어 구문을 업데이트하고 쓸모없는 새 키워드를 추가할 필요가 없습니다.

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

또는

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

@gladkikhartem 아이디어는 오류를 전파할 때마다 입력하지 않는 것입니다.

a, err? := something(b)

@mrkaspa
아이디어는 코드를 더 읽기 쉽게 만드는 것입니다. 코드를 입력하는 것이 문제가 아니라 읽는 것이 문제입니다.

@gladkikhartem 녹은 그 접근 방식을 사용하며

@gladkikhartem ? 가 가독성을 떨어뜨리지 않는다고 생각합니다. 노이즈를 완전히 제거한다고 합니다. 나에게 문제는 소음으로 인해 유용한 컨텍스트를 제공할 가능성도 제거된다는 것입니다. 일반적인 오류 메시지를 삽입하거나 오류를 래핑할 수 있는 위치가 표시되지 않습니다. 호출 스택은 명백한 솔루션이지만 이미 언급했듯이 모든 사람에게 작동하지는 않습니다.

@mrkaspa
가독성이 떨어진다고 생각합니다. 다음은 무엇인가요? 우리는 최선의 해결책을 찾고 있습니까, 아니면 의견을 공유하고 있습니까?

@크레커
'?' 문자는 무엇을 반환할지 명확하지 않고 물론 사람이 이 작업이 무엇을 하는지 알아야 하기 때문에 독자에게 인지 부하를 추가합니다. 그리고 물론? 기호는 독자의 마음에 질문을 제기합니다.

이전에 말했듯이 err != nil을 제거하려면 컴파일러가 사용하지 않는 오류 매개변수를 감지하여 직접 전달할 수 있습니다.
그리고

a, err? := doStuff(a,b)
err? := doAnotherStuff(b,z,d,g)
a, b, err? := doVeryComplexStuff(b)

더 읽기 쉬워질 것입니다

a := doStuff(a,b)
doAnotherStuff(b,z,d,g)
a, b := doVeryComplexStuff(b)

같은 마법, 입력할 항목과 생각할 항목이 줄어듭니다.

@gladkikhartem 글쎄요, 독자들이 새로운 것을 배울 필요가 없는 솔루션은 없다고 생각합니다. 언어를 바꾼 결과입니다. 우리는 절충안을 만들어야 합니다. 원시 용어로 수행되는 작업을 정확히 보여주는 얼굴 구문에 장황하게 입력하거나 장황함을 숨기거나 구문 설탕 등을 추가할 수 있는 새로운 구문을 도입하거나 다른 방법이 없습니다. 독자가 배울 내용을 추가하는 것을 거부하는 것은 역효과입니다. 모든 Go2 문제를 닫고 하루라고 부를 수도 있습니다.

귀하의 예에서는 더 많은 마법을 도입하고 개발자가 오류에 대한 컨텍스트를 제공할 수 있도록 하는 구문을 도입하기 위해 모든 주입 지점을 숨깁니다. 그리고 가장 중요한 것은 어떤 함수 호출이 오류를 발생시킬 수 있는지에 대한 정보를 완전히 숨깁니다. 그것은 점점 예외의 냄새가 납니다. 그리고 만약 우리가 오류를 다시 던지는 것에 대해 진지하다면 스택 추적은 그 경우에 컨텍스트를 유지할 수 있는 유일한 방법이기 때문에 필수가 됩니다.

원래 제안은 실제로 이미 모든 것을 꽤 잘 다루고 있습니다. 충분히 장황하고 오류를 래핑하고 유용한 컨텍스트를 제공하기에 좋은 위치를 제공합니다. 그러나 주요 문제 중 하나는 이 마법의 '오류'입니다. 나는 그것이 충분히 마술적이지 않고 충분히 장황하지 않기 때문에 추하다고 생각합니다. 그것은 일종의 중간입니다. 더 나은 것은 더 많은 마법을 도입하는 것입니다.

|| 가 원래 오류를 자동으로 래핑하는 새 오류를 생성하면 어떻게 될까요? 그래서 예제는 다음과 같이 됩니다

func Chdir(dir string) error {
    syscall.Chdir(dir) || &PathError{"chdir", dir}
    return nil
}

err 가 사라지고 모든 래핑이 암시적으로 처리됩니다. 이제 이러한 내부 오류에 액세스할 수 있는 방법이 필요합니다. Inner() error 와 같은 다른 메소드를 error 인터페이스에 추가하면 작동하지 않을 것 같습니다. 한 가지 방법은 unwrap(error) []error 와 같은 내장 함수를 도입하는 것입니다. 그것이 하는 일은 모든 내부 오류의 조각을 포장된 순서대로 반환하는 것입니다. 그런 식으로 내부 오류 또는 범위에 액세스할 수 있습니다.

error 가 인터페이스일 뿐이고 사용자 정의 error 유형에 대해 래핑된 오류를 둘 위치가 필요하다는 점을 감안할 때 이것의 구현은 의심스럽습니다.

나를 위해 이것은 모든 상자를 체크하지만 다소 너무 마술적일 수 있습니다. 그러나 오류 인터페이스가 정의상 매우 특별하다는 점을 감안할 때 이를 1급 시민에 더 가깝게 가져오는 것은 나쁜 생각이 아닐 수 있습니다. 오류 처리는 일반 Go 코드이기 때문에 장황합니다. 특별한 것은 없습니다. 그것은 서류상으로나 화려한 헤드라인을 만들기에 좋을지 모르지만 오류는 너무 특별해서 그러한 취급을 정당화할 수 없습니다. 그들은 특별한 케이스가 필요합니다.

원래 제안은 오류 검사의 수를 줄이는 것입니까 아니면 각 개별 검사의 길이를 줄이는 것입니까?

후자라면 조건문과 반복문이 하나만 있다는 이유로 제안의 필요성을 논박하는 것이 간단합니다. 어떤 사람들은 for 루프를 싫어합니다. 암시적 루프 구성도 제공해야 하나요?

지금까지 제안된 구문 변경은 흥미로운 사고 실험으로 작용했지만 그 중 어느 것도 원본만큼 명확하고 발음하기 쉽고 간단하지 않습니다. Go는 bash가 아니며 오류에 대해 "마술"이 되어서는 안 됩니다.

점점 더 많은 사람들이 이러한 제안을 읽고 "새로운 것을 추가하므로 나쁘고 읽을 수 없으며 모든 것을 그대로 둡니다"라고 주장하는 사람들을 점점 더 많이 봅니다.

@as 제안은 달성하려는 것에 대한 요약을 제공합니다. 수행되는 작업은 매우 잘 정의되어 있습니다.

원본처럼 명확하고 발음하기 쉬우며 단순합니다.

모든 제안은 새로운 구문을 도입하고 일부 사람들에게 새로운 것은 "읽을 수 없거나 복잡한 등"으로 들립니다. 새롭다고 해서 명확하지 않고 발음하기 쉬우며 단순하지 않습니다. "||" 그리고 "?" 예제는 기능을 알고 나면 기존 구문만큼 명확하고 간단합니다. 아니면 "->"와 "<-"가 너무 마술적이어서 독자가 그 의미를 알아야 한다고 불평하기 시작해야 합니까? 메서드 호출로 교체해 보겠습니다.

Go는 bash가 아니며 오류에 대해 "마술"이 되어서는 안 됩니다.

그것은 완전히 근거가 없으며 어떤 것에 대한 주장으로 간주되지 않습니다. Bash와 무슨 상관이 있는지는 알 수 없습니다.

@크레커
예, 이벤트에 더 많은 마법을 도입했다는 귀하의 의견에 전적으로 동의합니다. 내 예는 ? 더 적은 항목을 입력하는 운영자의 아이디어.

나는 우리가 무언가를 희생하고 약간의 변화와 마법을 도입해야 한다는 데 동의합니다. 그것은 유용성의 장점과 그러한 마법의 단점의 균형일 뿐입니다.

원본 || 제안은 꽤 훌륭하고 실제로 테스트되었지만 내 생각에는 형식이 추악합니다. 형식을 다음으로 변경하는 것이 좋습니다.

syscal.Chdir(dir)
    || return &PathError{"chdir", dir}

추신 마술 구문의 그러한 변형에 대해 어떻게 생각하십니까?

syscal.Chdir(dir) {
    return &PathError{"chdir", dir}
}

@gladkikhartem 둘 다 가독성 측면에서 꽤 좋아 보이지만 후자에서 나쁜 느낌을 받습니다. 그것은 내가 확신하지 못하는 이 이상한 블록 범위를 소개합니다.

구문을 따로따로 보지 말고 함수의 맥락에서 보는 것이 좋습니다. 이 메서드에는 몇 가지 다른 오류 처리 블록이 있습니다.

func (l *Loader) processDirectory(p *Package) (*build.Package, error) {
        absPath, err := p.preparePath()
        if err != nil {
                return nil, err
        }
    fis, err := l.context.ReadDir(absPath)
    if err != nil {
        return nil, err
    } else if len(fis) == 0 {
        return nil, nil
    }

    buildPkg, err := l.context.Import(".", absPath, 0)
    if err != nil {
        if _, ok := err.(*build.NoGoError); ok {
            // There isn't any Go code here.
            return nil, nil
        }
        return nil, err
    }

    return buildPkg, nil
}

제안된 변경 사항은 이 기능을 어떻게 정리합니까?

func (l *Loader) processDirectory(p *Package) (*build.Package, error) {
    absPath, err? := p.preparePath()
    fis, err? := l.context.ReadDir(absPath)
    if len(fis) == 0 {
        return nil, nil
    }

    buildPkg, err := l.context.Import(".", absPath, 0)
    if err != nil {
         if _, ok := err.(*build.NoGoError); ok {
             // There isn't any Go code here.
             return nil, nil
         }
         return nil, err
    }

    return buildPkg, nil
}

@bcmills 제안이 더 적합합니다.

func (l *Loader) processDirectory(p *Package) (*build.Package, error) {
    absPath := p.preparePath()        =? err { return nil, err }
    fis := l.context.ReadDir(absPath) =? err { return nil, err }
    if len(fis) == 0 {
        return nil, nil
    }
    buildPkg := l.context.Import(".", absPath, 0) =? err {
        if _, ok := err.(*build.NoGoError); ok {
            // There isn't any Go code here.
            return nil, nil
        }
        return nil, err
    }
    return buildPkg, nil
}

@object88

func (l *Loader) processDirectory(p *Package) (p *build.Package, err error) {
        absPath, err := p.preparePath() {
        return nil, fmt.Errorf("prepare path: %v", err)
    }
    fis, err := l.context.ReadDir(absPath) {
        return nil, fmt.Errorf("read dir: %v", err)
    }
    if len(fis) == 0 {
        return nil, nil
    }

    buildPkg, err := l.context.Import(".", absPath, 0) {
        err, ok := err.(*build.NoGoError)
                if !ok {
            return nil, fmt.Errorf("buildpkg: %v",err)
        }
        return nil, nil
    }
    return buildPkg, nil
}

계속 이것저것 찔러봅니다. 어쩌면 우리는 더 완전한 사용 예를 생각해 낼 수 있습니다.

@erwbgy , 나에게 이것이 가장 좋아 보이지만 지불금이 그렇게 좋은지 확신하지 못합니다.

• 오류가 아닌 반환 값은 무엇입니까? 그들은 항상 0 값입니까? 명명된 반환에 대해 이전에 할당된 값이 _was_ 있는 경우 해당 값이 재정의됩니까? 명명된 값이 오류 함수의 결과를 저장하는 데 사용되면 반환됩니까?
• ? 연산자를 오류가 아닌 값에 적용할 수 있습니까? (!ok)? 또는 ok!? 와 같은 작업을 수행할 수 있습니까? 아니면 이 구문은 error 에만 유용합니까?

@rodcorsi , 함수가 ReadDir 아니라 ReadBuildTargetDirectoryForFileInfo 이거나 어리석은 길이면 어떻게 될까요 ? 또는 많은 수의 인수가 있을 수 있습니다. preparePath 대한 오류 처리도 화면 밖으로 밀려납니다. 가로 화면 크기가 제한된 장치(또는 Github와 같이 그렇게 넓지 않은 뷰포트)에서는 =? 부분을 ​​잃을 가능성이 높습니다. 우리는 수직 스크롤에 매우 능숙합니다. 수평에서는 그다지.

@gladkikhartem , error 인터페이스를 구현하는 일부(마지막?) 인수에 연결된 것 같습니다. 그것은 함수 선언과 매우 흡사하고, 그것은 단지... _느낌_ 이상합니다. ok 스타일 반환 값에 묶일 수 있는 방법이 있습니까? 전체적으로 1줄만 구매합니다.

@object88
줄 바꿈은 정말 광범위한 코드 문제를 해결합니다. 널리 사용되지 않습니까?

매우 긴 함수 호출과 관련하여 @object88 . 여기서 주요 문제를 처리해 보겠습니다. 문제는 화면 밖으로 밀려난 오류 처리가 아닙니다. 문제는 긴 함수 이름 및/또는 많은 인수 목록입니다. 화면을 벗어나는 오류 처리에 대해 논쟁을 벌이기 전에 수정해야 합니다.

기본적으로 줄 바꿈으로 설정된 IDE 또는 코드 친화적인 텍스트 편집기를 아직 보지 못했습니다. 그리고 페이지가 로드된 후 CSS를 수동으로 해킹하는 것 외에는 Github을 사용하여 전혀 수행할 수 있는 방법을 찾지 못했습니다.

그리고 저는 코드 너비가 중요한 요소라고 생각합니다. 이것은 이 제안의 추진력인 _가독성_에 대해 말합니다. 주장은 오류 주변에 "너무 많은 코드"가 있다는 것입니다. 기능이 없거나 오류를 다른 방식으로 구현해야 하는 것이 아니라 코드가 잘 읽히지 않는다는 것입니다.

@object88
예, 이 코드는 오류 인터페이스를 마지막 매개변수로 반환하는 모든 함수에서 작동합니다.

줄 저장과 관련하여 더 적은 수의 줄에 더 많은 정보를 넣을 수는 없습니다. 코드는 너무 조밀하지 않고 모든 문장 뒤에 공백이 없어야 하며 고르게 분포되어야 합니다.
나는 그것이 함수 선언처럼 보인다는 것에 동의하지만 동시에 존재하는 if ...; err != nil { 문, 그래서 사람들은 너무 혼란스러워하지 않을 것입니다.

코드 너비는 중요한 요소입니다. 80줄의 편집기와 80줄의 코드가 함수 호출이고 그 후에 || 반환 ? 나는 그 함수가 무언가를 반환한다는 것을 식별할 수 없을 것입니다. 왜냐하면 내가 읽을 것은 반환이 없는 유효한 go 코드가 될 것이기 때문입니다.

완전성을 위해 || 구문, 자동 오류 래핑 및 오류가 아닌 반환 값의 자동 제로화를 사용하여 예제를 던질 것입니다.

func (l *Loader) processDirectory(p *Package) (*build.Package, error) {
        absPath := p.preparePath() || errors.New("prepare path")
    fis := l.context.ReadDir(absPath) || errors.New("ReadDir")
    if len(fis) == 0 {
        return nil, nil
    }

    buildPkg, err := l.context.Import(".", absPath, 0)
    if err != nil {
        if _, ok := err.(*build.NoGoError); ok {
            // There isn't any Go code here.
            return nil, nil
        }
        return nil, err
    }

    return buildPkg, nil
}

다른 반환 값에 대한 질문에 대해. 오류의 경우 모든 경우에 값이 0입니다. 나는 그것이 왜 중요하다고 믿는지 이미 다뤘습니다.

문제는 당신의 예가 처음부터 관련이 없다는 것입니다. 그러나 적어도 나에게는 이 제안이 의미하는 바를 여전히 보여줍니다. 내가 해결하고 싶은 것은 가장 일반적이고 많이 사용되는 관용구입니다.

err := func()
if err != nil {
    return err
}

우리는 이러한 종류의 코드가 일반적으로 오류 처리의 큰 부분(가장 큰 부분은 아니지만)이라는 데 동의할 수 있습니다. 따라서 그 경우를 해결하는 것이 논리적일 뿐입니다. 그리고 오류와 관련된 더 많은 작업을 수행하려면 몇 가지 논리를 적용하십시오. 프로그래머가 읽고 이해할 수 있는 실제 논리가 있는 곳에서 자세한 정보가 있어야 합니다. 우리에게 필요하지 않은 것은 생각 없는 상용구를 읽는 데 공간과 시간을 낭비하는 것입니다. 무의미하지만 여전히 Go 코드의 필수적인 부분입니다.

암시적으로 0 값을 반환하는 것에 대한 이전 이야기와 관련하여. 오류가 발생했을 때 의미 있는 값을 반환해야 하는 경우 실행하십시오. 여기서도 장황함이 좋고 코드를 이해하는 데 도움이 됩니다. 더 복잡한 작업을 수행해야 하는 경우 구문 설탕을 버리는 것은 아무런 문제가 없습니다. 그리고 || 는 두 가지 경우를 모두 해결할 수 있을 만큼 충분히 유연합니다. 오류가 아닌 값을 생략할 수 있으며 암시적으로 0이 됩니다. 또는 필요한 경우 명시적으로 지정할 수 있습니다. 나는 오류를 반환하고 다른 모든 것을 0으로 만들고 싶은 경우를 포함하는 별도의 제안도 있다는 것을 기억합니다.

@object88

주장은 오류 주변에 "너무 많은 코드"가 있다는 것입니다.

단순한 코드가 아닙니다. 주요 문제는 오류와 매우 일반적인 오류 처리 사례에 대한 의미 없는 상용구가 너무 많다는 것입니다. 읽을 가치가 있는 것이 있을 때 장황함이 중요합니다. if err == nil then return err 에는 오류를 다시 발생시키려는 것 외에는 가치가 없습니다. 이러한 원시적 논리에는 많은 공간이 필요합니다. 그리고 로직, 라이브러리 호출, 래퍼 등이 모두 오류를 반환할 수 있는 경우가 많을수록 이 상용구는 코드의 실제 로직인 중요한 항목을 더 많이 지배하기 시작합니다. 그리고 그 논리에는 실제로 몇 가지 중요한 오류 처리 논리가 포함될 수 있습니다. 그러나 주변의 대부분의 상용구의 이러한 반복적인 특성에서 길을 잃습니다. 그리고 그것은 해결될 수 있고 Go가 경쟁하는 다른 현대 언어들은 그것을 해결하려고 노력합니다. 오류 처리는 매우 중요하기 때문에 일반적인 코드가 아닙니다.

@크레커
err != nil return err 가 너무 많은 상용구라면 우리가 두려운 것은 스택 위로 오류를 전달하는 쉬운 방법을 만들면 통계적으로 프로그래머, 특히 주니어가 특정 상황에서 적절한 것.
Go의 오류 처리와 동일한 아이디어입니다. 적절한 작업을 수행하도록 강제합니다.
따라서 이 제안에서 우리는 다른 사람들이 오류를 신중하게 처리하고 감싸도록 권장하고자 합니다.

간단한 오류 처리를 구현하기에는 보기 흉하고 길게 만들어야 하지만, 래핑 또는 스택 추적을 사용한 우아한 오류 처리는 멋지고 쉽게 수행할 수 있도록 해야 한다고 말하고 싶습니다.

@gladkikhartem 나는 항상 고대 편집자들에 대한 이 주장이 어리석은

@gladkikhartem Go는 이미 그 문제를 가지고 있으며 우리가 그것에 대해 아무 것도 할 수 없다고 생각합니다. 개발자는 컴파일 실패나 런타임 패닉으로 강제할 때까지 항상 게으르지만 Go는 하지 않습니다.

Go가 실제로 하는 것은 아무 것도 강요하지 않는 것입니다. Go가 오류를 처리하도록 강요한다는 개념은 오해의 소지가 있으며 항상 그랬습니다. Go 작성자는 블로그 게시물과 컨퍼런스 강연에서 그렇게 하도록 강요합니다. 실제 언어는 사용자가 원하는 모든 작업을 수행할 수 있도록 합니다. 그리고 여기서 주요 문제는 Go가 기본적으로 선택하는 것입니다. 기본적으로 오류는 자동으로 무시됩니다. 변경하자는 제안도 있습니다. Go가 적절한 일을 하도록 강제하는 것이라면 다음을 수행해야 합니다. 컴파일 시간에 오류를 반환하거나 반환된 오류가 제대로 처리되지 않으면 런타임에 패닉을 반환합니다. 내가 이해한 바에 따르면 Rust는 기본적으로 오류를 패닉 상태로 만듭니다. 그것이 바로 내가 옳은 일을 하도록 강요하는 것입니다.

실제로 내가 Go에서 오류를 처리하도록 강요한 것은 개발자의 양심이지 다른 어떤 것도 아닙니다. 하지만 항상 포기하고 싶은 유혹이 있습니다. 지금 당장은 명시적으로 함수 시그니처를 읽지 않으면 오류가 반환된다는 사실을 아무도 알려주지 않습니다. 실제 예가 있습니다. 오랫동안 나는 fmt.Println 가 오류를 반환했다는 사실을 몰랐습니다. 나는 그것의 반환 값을 사용할 필요가 없고 단지 물건을 인쇄하고 싶을 뿐입니다. 그래서 내가 무엇을 반환하는지 볼 인센티브가 없습니다. 그것은 C가 가지고 있는 것과 같은 문제입니다. 오류는 값이며 런타임에 코드가 중단될 때까지 원하는 모든 것을 무시할 수 있으며 처리되지 않은 예외와 같은 유용한 패닉으로 인한 충돌이 없기 때문에 이에 대해 아무 것도 알 수 없습니다.

@gladkikhartem 이 제안에 대해 내가 이해한

나는 주로 Go 오류 처리를 단순화하려는 사람들이 수정되지 않은 오류를 반환하는 것이 아니라 오류 주위에 컨텍스트를 쉽게 감쌀 수 있는 방법에 대해 생각하도록 권장하기 위해 이 제안을 작성합니다.

@크레커
내 편집기는 너비가 100자입니다. 파일 탐색기, git 콘솔 등이 있습니다.... , 우리 팀에서는 아무도 100자 길이 이상의 코드를 작성하지 않습니다. 그냥 어리석은 일입니다(몇 가지 예외 제외).

Go는 오류 처리를 강제하지 않지만 린터는 수행합니다. (아마 우리는 이것을 위해 린터를 작성해야 할까요? )

좋아, 우리가 해결책을 제시할 수 없고 모두가 자신의 방식으로 제안을 이해한다면 - 우리가 필요로 하는 것에 대한 몇 가지 요구 사항을 지정하지 않겠습니까? 먼저 요구 사항에 동의하고 솔루션을 개발하는 것이 훨씬 쉬운 작업이 될 것입니다.

예를 들어:

1. 새 제안의 구문은 텍스트에 return 문을 포함해야 합니다. 그렇지 않으면 독자에게 무슨 일이 일어나고 있는지 명확하지 않습니다. ( 동의 동의하지 않음 )
2. 새 제안은 여러 값을 반환하는 기능을 지원해야 합니다(동의/동의하지 않음).
3. 새로운 제안은 더 적은 공간을 차지해야 합니다( 1줄, 2줄, 동의하지 않음)
4. 새로운 제안은 매우 긴 표현을 처리할 수 있어야 합니다(동의/동의하지 않음).
5. 새로운 제안은 오류가 있는 경우 여러 진술을 허용해야 합니다(동의/동의하지 않음).
6. .....

@creker , 내 개발의 약 75%가

불행히도 화면이 아무리 크더라도 github은 여전히 ​​뷰포트를 제한합니다.

@gladkikhartem

초보자의 게으름이 여기에 해당되지만 이러한 예 중 일부에서 errors.New 를 자유롭게 사용하는 것도 언어에 대한 이해가 부족함을 보여줍니다. 오류는 동적이 아닌 경우 반환 값에 할당되어서는 안 되며, 이러한 오류가 비교 가능한 패키지 범위 변수에 있으면 구문이 페이지에서 더 짧아지고 실제로 프로덕션 코드에서도 허용됩니다. Go 오류 처리 "보일러 플레이트"로 인해 가장 고통받는 사람들은 가장 지름길을 선택하고 오류를 제대로 처리할 충분한 경험이 없습니다.

simplifying error handling 구성하는 것은 분명하지 않지만, less runes != simple 라는 선례가 있습니다. 정량화 가능한 방식으로 구성을 측정할 수 있는 단순성을 위한 몇 가지 한정자가 있다고 생각합니다.

• 구성이 표현되는 방법의 수
• 해당 구성과 다른 구성의 유사성 및 해당 구성 간의 응집력
• 구성으로 요약된 논리 연산의 수
• 자연어에 대한 구성의 유사성(즉, 부정의 부재 등)

예를 들어, 원래 제안은 오류를 전파하는 방법의 수를 2에서 3으로 늘립니다. 논리적 OR과 유사하지만 의미가 다릅니다. 낮은 복잡성의 조건부 반환을 요약합니다( copy 또는 append 또는 >> ). 새로운 방법은 이전 방법보다 덜 자연스럽고 큰 소리로 말하면 abs, err := path(foo) || return err -> if theres an error, it's returning err 입니다. 이 경우 수직 막대를 사용할 수 있는 이유는 다음과 같습니다. 코드 리뷰에서 큰 소리로 말한 것과 같은 방식으로 작성할 수 있습니다.

@처럼
less runes != simple 전적으로 동의합니다.
단순하다는 것은 읽을 수 있고 이해할 수 있음을 의미합니다.
go에 익숙하지 않은 사람은 그것을 읽고 그것이 무엇을하는지 이해해야합니다.
농담처럼 해야 합니다. 설명할 필요가 없습니다.

현재 오류 처리는 실제로 이해할 수 있지만 if err != nil return. 가 너무 많으면 완전히 읽을 수 없습니다.

@object88 괜찮아요. 나는 이 주장이 꽤 자주 나오기 때문에 일반적으로 더 많이 말했다. 예를 들어 바둑을 작성하는 데 사용할 수 있는 우스꽝스러운 고대 터미널 화면을 상상해 봅시다. 그게 무슨 주장입니까? 그 엉뚱함의 한계는 어디까지인가? 우리가 그것에 대해 진지하다면 가장 인기 있는 화면 크기와 해상도라는 사실을 관찰해야 합니다. 그리고 그것에서만 우리는 무언가를 그릴 수 있습니다. 그러나 논쟁은 일반적으로 아무도 사용하지 않는 일부 화면 크기를 상상하지만 누군가가 할 수 있는 가능성은 적습니다.

@gladkikhartem 아니요, linters는 당신을 강요하지 않습니다, 그들은 제안합니다. 여기에는 큰 차이가 있습니다. 선택 사항이며 Go 도구 모음의 일부가 아니며 제안만 제공합니다. 강제 실행은 컴파일 또는 런타임 오류의 두 가지만 의미할 수 있습니다. 다른 모든 것은 선택할 수 있는 제안 및 옵션입니다.

동의합니다. 제안서가 모든 측면을 완전히 다루지 않기 때문에 원하는 것을 더 잘 공식화해야 합니다.

@처럼

새로운 방법은 이전 방법보다 덜 자연스럽습니다. 큰 소리로 말하면 아마도 abs가 될 것입니다. err := path(foo) || return err -> 오류가 있으면 오류를 반환합니다. 이 경우 코드 리뷰에서 큰 소리로 말한 것과 같은 방식으로 쓸 수 있다면 왜 세로 막대를 사용할 수 있는지 미스터리일 것입니다.

새로운 방법은 한 가지 이유로 덜 자연스럽습니다. 바로 지금은 언어의 일부가 아닙니다. 다른 이유는 없습니다. Go가 이미 그 구문을 가지고 있다고 상상해보십시오. 익숙하기 때문에 자연스럽게 될 것입니다. -> , select , go 및 다른 언어에는 없는 기타 항목에 익숙합니다. 리턴 대신 수직 막대를 사용할 수 있는 이유는 무엇입니까? 나는 질문으로 대답한다. 루프로 동일한 작업을 수행할 수 있는데 왜 한 번의 호출로 슬라이스를 추가하는 방법이 있습니까? 루프를 사용하여 동일한 작업을 수행할 수 있는데 한 번의 호출로 판독기에서 작성기 인터페이스로 항목을 복사하는 방법이 있는 이유는 무엇입니까? etc etc etc 코드가 더 간결하고 읽기 쉬워지기를 원하기 때문입니다. Go가 이미 수많은 예제와 모순될 때 이러한 주장을 하는 것입니다. 다시 말하지만, 더 개방적이며 새로운 언어이고 이미 언어로 되어 있지 않다는 이유로 격추하지 말자. 우리는 그것으로 아무것도 달성하지 못할 것입니다. 문제가 있습니다. 많은 사람들이 해결책을 요구하고 있습니다. 처리합시다. 바둑은 그것에 추가되는 어떤 것으로도 모독될 신성한 이상 언어가 아닙니다.

루프로 동일한 작업을 수행할 수 있는데 왜 한 번의 호출로 슬라이스를 추가하는 방법이 있습니까?

if 문 오류 검사를 작성하는 것은 간단합니다. append 구현을 보고 싶습니다.

루프를 사용하여 동일한 작업을 수행할 수 있는데 한 번의 호출로 판독기에서 작성기 인터페이스로 항목을 복사하는 방법이 있는 이유는 무엇입니까?

판독기와 작성기는 복사 작업의 소스와 대상, 버퍼링 전략, 때로는 루프의 센티넬 값까지 추상화합니다. 루프와 슬라이스로 추상화를 표현할 수 없습니다.

Go가 이미 수많은 예제와 모순될 때 이러한 주장을 하는 것입니다.

나는 적어도 그러한 예에서는 그렇지 않다고 생각합니다.

다시 말하지만, 더 개방적이며 새로운 언어이고 이미 언어로 되어 있지 않다는 이유로 격추하지 말자.

Go가 호환성을 보장한다는 점을 감안할 때 새로운 기능이 끔찍하다면 영원히 다루어야 하므로 가장 면밀히 조사해야 합니다. 지금까지 아무도 하지 않은 것은 실제 개념 증명을 만들어 소규모 개발 팀과 함께 사용하는 것입니다.

일부 제안(예: 제네릭)의 이력을 살펴보면 다음과 같은 깨달음이 종종 있음을 알 수 있습니다. "와, 이것은 실제로 좋은 솔루션이 아닙니다. 아직 변경하지 말자." 대안은 제안으로 가득 찬 언어이며 소급하여 쉽게 제거할 수 있는 방법이 없습니다.

와이드와 씬 스크린에 대해 고려해야 할 또 다른 사항은 멀티태스킹 입니다.

여러 개의 창을 나란히 두어 때때로 다른 것을 추적하면서 약간의 코드를 함께 던질 수 있습니다. 단순히 편집기를 쳐다보는 것이 아니라 컨텍스트를 완전히 다른 창으로 전환하여 기능을 조회할 수 있습니다(아마도 StackOverflow, 편집기로 다시 이동합니다.

@처럼
대부분의 제안된 기능이 비실용적이라는 데 전적으로 동의합니다. || 그리고 ? 물건이 될 수 있습니다.

@크레커
copy() 및 append() 는 구현하기 쉬운 작업이 아닙니다.

CI/CD에 린터가 있고 말 그대로 모든 오류를 처리하도록 강요합니다. 그것들은 언어의 일부가 아니지만 상관하지 않습니다. 나는 결과가 필요합니다.
(그리고 그건 그렇고, 나는 강한 의견을 가지고 있습니다 - 누군가가 Go에서 린터를 사용하지 않는다면 그는 단지 ....... )

화면 크기에 대해 - 진지하게 웃기지도 않습니다. 이 관련없는 토론을 중단하십시오. 화면은 원하는 만큼 넓을 수 있습니다. 코드의 || return &PathError{Err:err} 부분이 보이지 않을 가능성은 항상 있습니다. "ide"라는 단어를 Google에 표시하고 코드에 사용할 수 있는 공간의 종류를 확인하세요.

그리고 다른 사람의 글을 잘 읽어보세요. 저는 Go가 모든 오류를 처리하도록 강요한다고 말하지 않았습니다.

Go의 오류 처리와 동일한 아이디어입니다. 적절한 작업을 수행하도록 강제합니다.

@gladkikhartem Go는 오류 처리 측면에서 아무 것도 강요하지 않습니다. 그게 문제입니다. 괜찮은 물건이든 아니든 그것은 중요하지 않습니다. 나를 위해 그것은 fmt.Println 와 같은 것을 제외하고 모든 경우에 모든 오류를 처리한다는 것을 의미합니다.

누군가 Go에서 린터를 사용하지 않는다면

어쩌면 그럴지도 몰라. 그러나 무언가가 정말로 강요되지 않는다면 그것은 날지 않을 것입니다. 일부는 사용할 것이고 다른 일부는 사용하지 않을 것입니다.

화면 크기에 대해 - 진지하게 웃기지도 않습니다. 이 관련없는 토론을 중단하십시오.

나는 의사 결정에 영향을 미칠 임의의 숫자를 던지기 시작한 사람이 아닙니다. 나는 문제를 이해하지만 객관적이어야 한다고 분명히 말합니다. "나는 80개의 심볼 너비의 IDE를 가지고 있습니다. Go는 그것을 고려하고 다른 모든 것을 무시해야 합니다"가 아닙니다.

내 화면 크기에 대해 이야기하는 경우. Visual Studio 코드는 270개의 수평 공간 기호를 제공합니다. 나는 그렇게 많은 공간을 차지하는 것이 정상이라고 옹호하지 않을 것입니다. 그러나 주석이 있는 구조체와 특히 긴 이름의 필드 유형을 고려할 때 내 코드는 쉽게 120개 기호를 초과할 수 있습니다. || 구문을 사용한다면 3-5개의 인수 함수 호출 및 사용자 정의 메시지와 함께 래핑된 오류의 경우 100-120에 쉽게 맞을 것입니다.

이더 방식으로 || 와 같은 것이 구현된다면 gofmt는 아마도 한 줄에 작성하도록 강요해서는 안 됩니다. 어떤 경우에는 너무 많은 공간을 차지할 수 있습니다.

@erwbgy , 이것은 나에게 가장 좋아 보이지만 지불금이 그렇게 좋은지 확신하지 못합니다.

@object88 저에게 지불금은 단순한 오류 처리를 위해 일반적인 상용구를 제거하고 너무 많은 일을 하지 않는다는 것입니다. 그것은 단지 다음을 만듭니다:

val, err := func()
if err != nil {
    return nil, errors.WithStack(err)
}

더 간단:

val, err? := func()

더 복잡한 오류 처리가 현재 방식으로 수행되는 것을 막는 것은 없습니다.

오류가 아닌 반환 값은 무엇입니까? 그들은 항상 0 값입니까? 명명된 반환에 대해 이전에 할당된 값이 있는 경우 해당 값이 재정의됩니까? 명명된 값이 오류 함수의 결과를 저장하는 데 사용되면 반환됩니까?

다른 모든 반환 매개변수는 적절한 nil 값입니다. 명명된 매개변수의 경우 이미 일부 값이 할당되도록 보장되므로 이전에 할당된 값을 유지할 것으로 예상합니다.

할 수 있습니까? 연산자가 오류가 아닌 값에 적용됩니까? (!ok)와 같이 할 수 있습니까? 아니면 괜찮아!? (할당과 작업을 함께 묶고 있기 때문에 조금 이상합니다)? 아니면 이 구문이 오류에만 적합합니까?

아니요, 오류 값 이외의 다른 용도로 이 구문을 사용하는 것이 합리적이지 않다고 생각합니다.

"필수" 기능이 더 읽기 쉬운 코드에 대한 절박함에서 확산될 것이라고 생각합니다.

SQLX

db.MustExec(schema)

HTML 템플릿

var t = template.Must(template.New("name").Parse("html"))

나는 패닉 오퍼레이터를 제안합니다(' 오퍼레이터'라고 불러야 하는지 확실하지 않습니다)

a,  😱 := someFunc(b)

와 같지만 더 즉각적일 수 있습니다.

a, err := someFunc(b)
if err != nil {
  panic(err)
}

😱는 아마도 입력하기 너무 어려울 것입니다. !, !!, 또는

a,  !! := someFunc(b)

!! = maybeReturnsError()

아마도 !! 공황과 ! 보고

내 2센트를 위한 시간. 스택 추적에 표준 라이브러리의 debug.PrintStack() 를 사용할 수 없는 이유는 무엇입니까? 아이디어는 오류가 발생한 가장 깊은 수준에서만 스택 추적을 인쇄하는 것입니다.

스택 추적에 표준 라이브러리의 debug.PrintStack() 를 사용할 수 없는 이유는 무엇입니까?

오류는 여러 스택에 걸쳐 발생할 수 있습니다. 채널을 통해 보내거나 변수 등에 저장할 수 있습니다. 오류가 처음 생성된 부분을 아는 것보다 이러한 전환 지점을 아는 것이 더 도움이 되는 경우가 많습니다.

또한 스택 추적 자체에는 종종 내부(내보내지 않은) 도우미 기능이 포함됩니다. 이는 예기치 않은 충돌을 디버그하려고 할 때 편리하지만 정상 작동 과정에서 발생하는 오류에는 도움이 되지 않습니다.

완전한 프로그래밍 초보자를 위한 가장 사용자 친화적인 접근 방식은 무엇입니까?

더 간단한 버전을 찾았습니다. if !err 하나만 있으면 됩니다.
특별하지 않고 직관적이며 추가 구두점도 없고 훨씬 더 작은 코드

```가다
absPath, 오류 := p.preparePath()
nil을 반환하고 err이면 err

err := doSomethingWith(absPath) if !err
doSomethingElse() if !err

doSomethingRegardlessOfErr()

// 한 곳에서 오류를 처리합니다. 필요한 경우; 들여쓰기가 없는 캐치형
오류가 있으면 {
"코드 오염 없는 오류" 반환, 오류
}
```

err := doSomethingWith(absPath) if !err
doSomethingElse() if !err

다시 오신 것을 환영합니다, 좋은 오래된 MUMPS 포스트 조건 ;-)

고맙지 만 괜찮습니다.

@dmajkic 이것은 "추가 컨텍스트 정보와 함께 오류를 반환"하는 데 도움이 되지 않습니다.

@erwbgy 이 문제의 제목은 _proposal: Go 2: ||로 오류 처리 단순화 err suffix_ 내 의견은 그 맥락에있었습니다. 이전 토론에 참여했다면 죄송합니다.

@cznic 네 . 사후 조건은 Go-way가 아니지만 사전 조건도 오염된 것처럼 보입니다.

if !err; err := doSomethingWith(absPath)
if !err; doSomethingElse()

@dmajkic 제안에는 제목보다 더 많은 것이 있습니다. ianlancetaylor는 오류를 처리하는 세 가지 방법을 설명하고 특히 몇 가지 제안이 추가 정보와 함께 오류를 반환하는 것이 더 쉽다고 지적합니다.

@erwbgy @ianlancetaylor 가 지정한 모든 문제를 검토했습니다. 모두 새 키워드(예 try() )를 추가하거나 영숫자가 아닌 특수 문자를 사용하는 것과 관련이 있습니다. 개인적으로 - !"#$%& 로 오버로드된 코드가 욕설처럼 공격적으로 보이는 경향이 있기 때문에 저는 그것을 좋아하지 않습니다.

나는 이 문제의 처음 몇 줄의 상태에 동의하고 느낍니다. 너무 많은 Go 코드가 오류 처리에 사용됩니다. 내가 한 제안은 추가 키워드나 키 문자가 필요 없이 지금 Go가 느끼는 것과 매우 유사한 제안으로 그 감정과 일치합니다.

조건부 연기는 어떻습니까

func something() (int, error) {
    var error err
    var oth err

    defer err != nil {
        return 0, mycustomerror("More Info", err)
    }
    defer oth != nil {
        return 1, mycustomerror("Some other case", oth)
    }

    _, err = a()
    _, err = b()
    _, err = c()
    _, oth = d()
    _, err = e()

    return 2, nil
}


func something() (int, error) {
    var error err
    var oth err

    _, err = a()
    if err != nil {
        return 0, mycustomerror("More Info", err)
    }
    _, err = b()
    if err != nil {
        return 0, mycustomerror("More Info", err)
    }
    _, err = c()
    if err != nil {
        return 0, mycustomerror("More Info", err)
    }
    _, oth = d()
    if oth != nil {
        return 1, mycustomerror("Some other case", oth)
    }
    _, err = e()
    if err != nil {
        return 0, mycustomerror("More Info", err)
    }

    return 2, nil
}

그러면 defer 의 의미가 크게 변경됩니다. 이는 범위가 일찍 종료되도록 하는 것이 아니라 범위의 끝에서 실행되는 것입니다.

그들이 이 언어로 Try Catch를 도입하면 이 모든 문제가 매우 쉬운 방법으로 해결될 것입니다.

그들은 이런 것을 소개해야 합니다. error 값이 nil이 아닌 다른 값으로 설정되면 현재 워크플로를 중단하고 catch 섹션을 자동으로 트리거한 다음 finally 섹션과 현재 라이브러리도 변경 없이 작동할 수 있습니다. 문제 해결됨!

try (var err error){
     i, err:=DoSomething1()
     i, err=DoSomething2()
     i, err=DoSomething3()
} catch (err error){
   HandleError(err)
   // return err  // similar to throw err
} finally{
  // Do something
}

Marcel은 다음과 같이 생각하고 있는 것 같습니다.

• https://github.com/gopherchina/conference/blob/master/2018/1.3%20Rethinking%20Errors%20for%20Go%202.pdf

@sbinet 이것은 아무것도 없는 것보다 낫지 만 모두가 익숙한 동일한 try-catch 패러다임을 사용하면 훨씬 좋습니다.

@KamyarM 변수가 0이 아닌 값으로 설정될 때마다 예외를 throw하는 메커니즘을 추가하는 것을 제안하는 것 같습니다. 그것은 "모두에게 익숙한 패러다임"이 아닙니다. 그런 식으로 작동하는 언어를 알지 못합니다.

예외처럼 작동하지 않는 "예외"도 있는 Swift와 유사해 보입니다.

다른 언어에서는 try catch가 실제로는 2급 솔루션이라는 것을 보여주지만 Go는 Maybe 모나드 등으로 이를 해결할 수 없을 것이라고 생각합니다.

@ianlancetaylor 방금 C++, Java, C# 등의 다른 프로그래밍 언어에서 Try-Catch를 참조했으며 여기에 있는 솔루션이 아닙니다. GoLang에 1일차부터 Try-Catch가 있으면 더 좋았으므로 이러한 방식의 오류 처리를 처리할 필요가 없었습니다(실제로 새로운 것은 아닙니다. 원하는 경우 다른 프로그래밍 언어로 동일한 GoLang 오류 처리를 작성할 수 있습니다. 그런 식으로 코딩) 하지만 내가 제안한 것은 오류 개체를 반환할 수 있는 현재 라이브러리와 하위 호환성을 갖는 방법이었습니다.

Java 예외는 기차 사고이므로 @KamyarM에서 귀하와 단호하게 동의하지 않습니다. 어떤 것이 익숙하다고 해서 그것이 좋은 선택이라는 의미는 아닙니다.

내 말은.

@KamyarM 설명 감사합니다. 우리는 예외를 명시적으로 고려하고 거부했습니다. 오류는 예외가 아닙니다. 모든 종류의 완전히 정상적인 이유로 발생합니다. https://blog.golang.org/errors-are-values

예외적이든 아니든 오류 처리 상용구로 인한 코드 팽창 문제를 해결합니다. 같은 문제로 인해 Go와 거의 비슷하게 작동하는 Objective-C가 손상되었습니다. 오류는 NSError 유형의 값일 뿐이며 특별한 것은 없습니다. 그리고 많은 if 및 오류 래핑과 동일한 문제가 있습니다. 이것이 Swift가 상황을 바꾼 이유입니다. 그들은 두 가지가 혼합되어 끝났습니다. 실행을 종료하고 예외를 잡아야한다는 것을 의미하는 예외처럼 작동합니다. 그러나 스택을 풀지 않고 일반 반환처럼 작동합니다. 따라서 제어 흐름에 예외를 사용하는 것에 대한 기술적인 주장은 여기에 적용되지 않습니다. 이러한 "예외"는 일반 반환만큼 빠릅니다. 그것은 구문상의 설탕에 가깝습니다. 그러나 Swift에는 고유한 문제가 있습니다. 많은 Cocoa API는 비동기식(콜백 및 GCD)이며 이러한 종류의 오류 처리와 호환되지 않습니다. 예외는 wait와 같은 것이 없으면 쓸모가 없습니다. 그러나 거의 모든 Go 코드는 동기식이며 이러한 "예외"가 실제로 작동할 수 있습니다.

@urandom
Java의 예외는 나쁘지 않습니다. 문제는 그것을 사용하는 방법을 모르는 나쁜 프로그래머들입니다.

당신의 언어에 끔찍한 기능이 있다면 누군가는 결국 그 기능을 사용할 것입니다. 당신의 언어에 그러한 기능이 없다면 0%의 가능성이 있습니다. 간단한 수학입니다.

@ 나는 try-catch가 끔찍한 기능이라는 것에 동의하지 않습니다. 그것은 매우 유용한 기능이며 우리의 삶을 훨씬 더 쉽게 만들어줍니다. 그래서 우리가 여기에 언급하는 이유입니다. 그래서 Google GoLang 팀이 유사한 기능을 추가할 수도 있습니다. 저는 개인적으로 GoLang의 if-elses 오류 처리 코드를 싫어하고 defer-panic-recover 개념을 그다지 좋아하지 않습니다(try-catch와 유사하지만 Try-Catch-Finally 블록만큼 정리되지 않음) . 코드에 너무 많은 노이즈를 추가하여 많은 경우에 코드를 읽을 수 없게 만듭니다.

상용구 없이 오류를 처리하는 기능은 이미 언어에 존재합니다. 예외 기반 언어에서 온 초보자를 만족시키기 위해 더 많은 기능을 추가하는 것은 좋은 생각이 아닌 것 같습니다.

그리고 C/C++, Objective-C에서 온 사람은 어떻습니까? 우리가 상용구에 대해 똑같은 문제를 가지고 있는 곳은 무엇입니까? 그리고 Go와 같은 현대 언어가 똑같은 문제로 고통받는 것을 보는 것은 실망스럽습니다. 이것이 가치로서의 오류에 대한 이 모든 과장된 주장이 너무 거짓되고 어리석게 느껴지는 이유입니다. 이미 수년, 수십 년 동안 이루어졌습니다. Go는 그 경험에서 아무것도 배우지 못한 것 같습니다. 특히 실제로 더 나은 방법을 찾으려고 노력하는 Swift/Rust를 살펴보세요. Java/C#과 같은 기존 솔루션으로 해결하고 예외로 해결했지만 적어도 그것들은 훨씬 오래된 언어입니다.

@KamyarM 철도 지향 프로그래밍을 사용해 본 적이 있습니까? 빔?

예외를 사용한다면 그렇게 많이 칭찬하지 않을 것입니다.

@ShalokShalom 별로. 그러나 그것은 단지 상태 기계가 아닙니까? 실패하면 이렇게 하고 성공하면 저것으로? 모든 유형의 오류가 예외처럼 처리되어야 하는 것은 아니라고 생각합니다. 사용자 입력 유효성 검사만 필요한 경우 유효성 검사 오류에 대한 세부 정보와 함께 부울 값을 반환하기만 하면 됩니다. 예외는 IO 또는 네트워크 액세스 또는 잘못된 기능 입력으로 제한되어야 하며 오류가 정말 중요하고 모든 비용을 들여 행복한 실행 경로를 중지하려는 경우입니다.

일부 사람들이 Try-Catch가 좋지 않다고 말하는 이유 중 하나는 성능 때문입니다. 예외가 발생할 수 있는 각 장소에 대해 핸들러 맵 테이블을 사용하기 때문에 발생하는 것일 수 있습니다. If Error check(오류 여부에 관계없이 항상 확인됨)와 비교하여 예외조차도 더 빠릅니다(예외가 발생하지 않을 때 비용이 0이지만 실제로 발생할 때 비용이 더 많이 듭니다). 그 외에는 Try-Catch 구문에 문제가 있다고 생각하지 않습니다. 구문이 아니라 컴파일러에서 구현하는 방식일 뿐입니다.

@ShalokShalom 이것을 확인하십시오:
https://mortoray.com/2013/09/12/the-true-cost-of-zero-cost-exceptions/

C/C++에서 온 사람들은 예외가 없는 Go를 정확히 칭찬하고
현명한 선택을 하고 그것이 "현대적"이라고 주장하는 사람들에 저항하고
읽을 수 있는 워크플로(특히 C++ 이후)에 대해 하나님께 감사드립니다.

2018년 4월 17일 화요일 03:46, Antonenko Artem [email protected]
썼다:

그리고 C/C++, Objective-C에서 온 사람은 어떻습니까?
상용구의 정확한 문제? 그리고 현대 언어를 보면 답답하다
Go는 정확히 같은 문제를 겪고 있습니다. 그래서 이 모든 과대 광고
값이 너무 가짜이고 어리석게 느껴지기 때문에 오류 주위에 - 이미 완료되었습니다.
몇 년, 수십 년 동안. Go는 그것으로부터 아무것도 배우지 못한 것 같다
경험. 특히 실제로 찾으려는 Swift/Rust를 보면
더 나은 방법. Java/C#과 같은 기존 솔루션으로 정착
예외지만 적어도 그것들은 훨씬 오래된 언어입니다.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/golang/go/issues/21161#issuecomment-381793840 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AICzv9w608ea2fwPq_wNpTDBnKMAdAKTks5tpTtsgaJpZM4Oi1c-
.

@kirillx 저는 C++에서와 같은 예외를

예외를 옹호하는 사람들은 이 기사를 읽어야 합니다: https://ckwop.me.uk/Why-Exceptions-Suck.html

Java/C++ 스타일 예외가 본질적으로 나쁜 이유는 특정 구현의 성능과 관련이 없습니다. 예외는 BASIC의 "on error goto"이기 때문에 좋지 않으며, goto가 적용될 수 있는 컨텍스트에서 보이지 않습니다. 예외는 쉽게 잊어버릴 수 있는 위치에서 오류 처리를 숨깁니다. Java의 확인된 예외는 이 문제를 해결해야 하지만 실제로는 사람들이 예외를 포착하여 먹었거나 모든 곳에서 스택 추적을 덤프했기 때문에 실제로 해결되지 않았습니다.

저는 대부분의 주에 Java를 작성하며 성능이 아무리 높아도 Go에서 Java 스타일 예외를 보고 싶지 않습니다.

@lpar 모든 for 루프, while 루프, if elses , switch case , 중단 및 GoTo 종류의 계속이 아닙니다. 그러면 프로그래밍 언어에서 무엇이 남습니까?

동안, for 및 if/else는 실행 흐름이 표시되지 않는 다른 곳으로 보이지 않게 점프하는 것을 포함하지 않습니다.

누군가 GoLang의 이전 호출자에게 오류를 전달하고 해당 호출자가 이를 이전 호출자에게 반환하는 등의 방식으로(많은 코드 노이즈 제외) 무엇이 다른가요? 누가 오류를 처리할 것인지 확인하기 위해 얼마나 많은 코드를 살펴보고 통과해야 합니까? try-catch도 마찬가지입니다.

무엇이 프로그래머를 막을 수 있습니까? 때로는 함수가 실제로 오류를 처리할 필요가 없습니다. 사용자나 시스템 관리자가 문제를 해결하거나 해결 방법을 찾을 수 있도록 UI에 오류를 전달하기만 하면 됩니다.

함수가 예외를 처리하지 않으려는 경우 이전 호출자가 처리할 수 있도록 단순히 try-catch 블록을 사용하지 않습니다. 구문에는 문제가 없다고 생각합니다. 또한 훨씬 깨끗합니다. 성능과 언어로 구현되는 방식은 다릅니다.

아래에서 볼 수 있듯이 오류를 처리하지 않기 위해 4줄의 코드를 추가해야 합니다.

func myFunc1() error{
  // ...
  if (err){
      return err
  }
  return nil
}

처리하기 위해 호출자에게 오류를 다시 전달하려는 경우 괜찮습니다. 요점은 오류가 반환된 지점에서 그렇게 하고 있음을 볼 수 있다는 것입니다.

고려하다:

x, err := lib.SomeFunc(100, 4)
if err != nil {
  // A
}
// B

코드를 보면 함수를 호출할 때 오류가 발생할 수 있음을 알 수 있습니다. 오류가 발생하면 코드 흐름이 지점 A에서 종료된다는 것을 알고 있습니다. 다른 장소 코드 흐름이 종료될 유일한 곳은 지점 B입니다. 또한 err이 nil이면 x가 유효한 값이라는 암시적 계약이 있습니다. 0 또는 기타.

자바와 대조:

x = SomeFunc(100, 4)

코드를 보면 함수가 호출될 때 오류가 발생할 수 있는지 여부를 알 수 없습니다. 오류가 발생하고 예외로 표현되면 goto 가 발생하고 주변 코드의 맨 아래 어딘가에 있을 수 있습니다. 또는 예외가 catch되지 않으면 종료될 수 있습니다. 코드의 완전히 다른 부분의 맨 아래 어딘가에 있습니다. 또는 다른 사람의 코드로 끝날 수 있습니다. 사실, 기본 예외 처리기를 교체할 수 있기 때문에 다른 사람의 코드에서 수행한 작업을 기반으로 문자 그대로 모든 위치에 잠재적으로 끝날 수 있습니다.

또한 x가 유효하다는 암시적 계약이 없습니다. 함수가 오류나 누락된 값을 나타내기 위해 null을 반환하는 것이 일반적입니다.

Java를 사용하면 이러한 문제는 모든 단일 호출에서 발생할 수 있습니다. 잘못된 코드뿐만 아니라 _all_ Java 코드에 대해 걱정해야 하는 것입니다. 그렇기 때문에 Java 개발 환경에는 사용자가 가리키는 기능이 예외를 유발할 수 있는지 여부와 발생할 수 있는 예외를 보여주는 팝업 도움말이 있습니다. 이것이 Java가 확인된 예외를 추가한 이유입니다. 따라서 일반적인 오류의 경우 함수 호출이 예외를 발생시키고 프로그램 흐름을 우회할 수 있다는 경고가 최소한 있어야 했습니다. 한편 반환된 null과 NullPointerException 의 확인되지 않은 특성은 비용이 명시적으로 랩핑되어야 함에도 불구하고 Java 8에 Optional 클래스를 추가하여 이를 개선하려고 시도하는 것과 같은 문제입니다. 객체를 반환하는 모든 단일 함수에 대한 반환 값.

내 경험에 따르면 예상치 못한 null 값의 NullPointerException 는 Java 코드가 충돌하는 가장 일반적인 단일 방법이며 일반적으로 거의 완전히 쓸모없는 큰 역추적으로 끝납니다. 오류가 있는 코드에서 멀리 떨어져 생성되었기 때문에 원인을 나타내지 않는 오류 메시지입니다. 바둑에 대한 경험이 훨씬 적음에도 불구하고 바둑에서는 솔직히 역참조 패닉이 심각한 문제라는 것을 발견하지 못했습니다. 나에게 그것은 자바가 그 반대가 아니라 Go에서 배워야 함을 나타냅니다.

구문에는 문제가 없다고 생각합니다.

나는 아무도 구문이 Java 스타일 예외의 문제라고 말하지 않는다고 생각합니다.

@lpar , Go의 nil 역참조 패닉이 Java의 NullPointerException보다 나은 이유는 무엇입니까? "패닉"과 "던짐"의 차이점은 무엇입니까? 의미론의 차이점은 무엇입니까?

공황 상태는 회복할 수 있고 던지기는 잡을 수 있습니까? 오른쪽?

방금 한 가지 차이점을 기억했습니다. 패닉을 사용하면 오류 객체 또는 문자열 객체를 당황하게 할 수 있거나 다른 유형의 객체가 될 수 있습니다(틀린 경우 수정하십시오). 그러나 throw를 사용하면 Exception 또는 하위 클래스 유형의 객체를 던질 수 있습니다. 예외의.

Go의 nil 역참조 패닉이 Java의 NullPointerException보다 나은 이유는 무엇입니까?

내가 설명한 이유 때문에 전자는 내 경험에서 거의 발생하지 않는 반면 후자는 항상 발생하기 때문입니다.

@lpar 글쎄, 나는 최근에 Java로 프로그래밍하지 않았고 그것이 새로운 것(지난 5년)이라고 생각하지만 C#에는 예외를 생성하기 위해 null 참조를 피하기 위해 안전한 탐색 연산자가 있지만 Go에는 무엇이 있습니까? 잘은 모르겠지만 그런 상황에 대처할 수 있는 건 없는 것 같아요. 따라서 패닉을 피하려면 여전히 코드에 추악한 중첩 if-not-nil-else 문을 추가해야 합니다.

일반적으로 오류 반환 값을 확인하는 한 Go에서 반환 값이 nil인지 확인하기 위해 반환 값을 확인할 필요가 없습니다. 따라서 추악한 중첩 if 문이 없습니다.

Null 역참조는 나쁜 예입니다. 그것을 잡지 않으면 Go와 Java가 정확히 동일하게 작동합니다. 스택 추적에 충돌이 발생합니다. 스택 추적이 어떻게 쓸모가 없을 수 있습니까? 당신은 그것이 일어난 정확한 장소를 알고 있습니다. C#과 Go 모두 내 경험에서 null 역참조가 단순한 프로그래머 오류로 인한 것이기 때문에 일반적으로 그런 종류의 충돌을 수정하는 것은 간단합니다. 이 특별한 경우에는 누구에게서도 배울 것이 없습니다.

@lpar

내가 설명한 이유 때문에 전자는 내 경험에서 거의 발생하지 않는 반면 후자는 항상 발생하기 때문입니다.

그것은 우발적이며 Java가 Go보다 nil/null에서 더 나쁘다는 귀하의 의견에서 어떤 이유도 보지 못했습니다. Go 코드에서 수많은 nil 역참조 충돌을 관찰했습니다. C#/Java의 null 역참조와 정확히 동일합니다. 도움이 되지만(C#에도 있음) 아무것도 변경하지 않는 더 많은 값 유형을 Go에서 사용할 수 있습니다.

예외로 Swift를 살펴보겠습니다. 오류가 발생할 수 있는 함수에 대한 키워드 throws 가 있습니다. 함수가 없으면 던질 수 없습니다. 구현은 반환처럼 작동합니다. 아마도 일부 레지스터는 오류 반환을 위해 예약되어 있으며 함수를 던질 때마다 정상적으로 반환되지만 오류 값도 함께 전달됩니다. 따라서 예기치 않은 오류 문제가 해결되었습니다. 어떤 함수가 throw될 수 있는지 정확히 알고 있으며 발생할 수 있는 정확한 위치를 알고 있습니다. 오류는 값이며 스택 해제가 필요하지 않습니다. 당신이 그것을 잡을 때까지 그들은 단지 반환됩니다.

또는 결과와 오류를 전달하는 특별한 Result 유형이 있는 Rust와 유사한 것입니다. 명시적 조건문 없이 오류가 전파될 수 있습니다. 게다가 수많은 패턴 매칭이 가능하지만 Go에서는 그렇지 않을 것입니다.

이 두 언어는 두 가지 솔루션(C 및 Java)을 모두 사용하여 더 나은 것으로 결합합니다. 예외로 인한 오류 전파 + 오류 값 및 C의 명백한 코드 흐름 + 유용하지 않은 못생긴 상용구 코드 없음. 따라서 이러한 특정 구현을 살펴보고 어떤 면에서 예외와 유사하다고 해서 완전히 외면하지 않는 것이 현명하다고 생각합니다. 예외는 긍정적인 측면이 있기 때문에 많은 언어에서 예외가 사용되는 데는 이유가 있습니다. 그렇지 않으면 언어가 무시합니다. 특히 C++ 이후.

스택 추적이 어떻게 쓸모가 없을 수 있습니까?

나는 "거의 완전히 쓸모없다"고 말했다. 마찬가지로 정보는 한 줄만 필요하지만 수십 줄입니다.

그것은 우발적이며 Java가 Go보다 nil/null에서 더 나쁘다는 귀하의 의견에서 어떤 이유도 보지 못했습니다.

그럼 당신은 듣고 있지 않습니다. 뒤로 돌아가 묵시적 계약에 대한 부분을 읽으십시오.

명시적 조건문 없이 오류가 전파될 수 있습니다.

그리고 그것이 바로 문제입니다. 오류가 전파되고 제어 흐름이 변경될 것이라는 명시적인 표시 없이 변경됩니다. 분명히 당신은 그것이 문제라고 생각하지 않지만 다른 사람들은 동의하지 않습니다.

Rust 또는 Swift에 의해 구현된 예외가 Java와 동일한 문제를 겪고 있는지 여부는 잘 모르겠습니다. 해당 언어에 대해 경험이 있는 사람에게 맡기겠습니다.

@KamyarM 당신은 기본적으로 nil을 불필요하게 만들고 그것에 대한 완전한 유형 안전성을 얻습니다.

https://fsharpforfunandprofit.com/posts/the-option-type/

그리고 그것이 바로 문제입니다. 오류가 전파되고 제어 흐름이 변경될 것이라는 명시적인 표시 없이 변경됩니다.

이것은 나에게 사실로 들린다. 다른 패키지를 사용하는 일부 패키지를 개발하고 해당 패키지에서 예외가 발생하는 경우 이제 _I_도 해당 기능을 사용하려는지 여부에 관계없이 이를 인식해야 합니다. 이것은 제안된 언어 기능 중 드문 측면입니다. 대부분은 프로그래머가 선택하거나 재량에 따라 사용하지 않을 수 있는 것입니다. 예외는 그 의도에 따라 예상되든 그렇지 않든 모든 종류의 경계를 넘습니다.

나는 "거의 완전히 쓸모없다"고 말했다. 마찬가지로 정보는 한 줄만 필요하지만 수십 줄입니다.

그리고 수백 개의 고루틴이 있는 거대한 Go 추적이 어떻게 든 더 유용할까요? 나는 당신이 이것을 가지고 어디로 가는지 이해할 수 없습니다. Java와 Go는 여기에서 정확히 동일합니다. 그리고 때때로 전체 스택을 관찰하여 코드가 어떻게 충돌했는지 이해하는 것이 유용하다는 것을 알게 됩니다. C# 및 Go 추적은 여러 번 도움이 되었습니다.

그럼 당신은 듣고 있지 않습니다. 뒤로 돌아가 묵시적 계약에 대한 부분을 읽으십시오.

읽어보니 변한게 없습니다. 제 경험상 문제가 되지 않습니다. 이것이 두 언어 모두에 대한 문서입니다(예 net.ParseIP ). 값이 nil/null인지 확인하는 것을 잊어버린 경우 두 언어 모두에서 똑같은 문제가 발생합니다. 대부분의 경우 Go는 오류를 반환하고 C#은 예외를 throw하므로 nil에 대해 걱정할 필요조차 없습니다. 좋은 API는 예외를 던지거나 무엇이 잘못되었는지 알려주지 않고 null을 반환하지 않습니다. 다른 경우에는 명시적으로 확인합니다. 내 경험에 따르면 null이 있는 가장 일반적인 오류 유형은 각 필드가 포인터/객체인 프로토콜 버퍼가 있거나 내부 상태에 따라 클래스/구조 필드가 0일 수 있고 전에 확인하는 것을 잊어버린 내부 논리가 있는 경우입니다. 입장. 이것이 저에게 가장 일반적인 패턴이며 Go의 어떤 것도 이 문제를 크게 완화하지 않습니다. 나는 약간 도움이 되는 두 가지 이름을 말할 수 있습니다. 유용한 빈 값과 값 유형입니다. 그러나 사용하기 전에 모든 변수를 구성할 필요가 없기 때문에 프로그래밍이 더 쉽습니다.

그리고 그것이 바로 문제입니다. 오류가 전파되고 제어 흐름이 변경될 것이라는 명시적인 표시 없이 변경됩니다. 분명히 당신은 그것이 문제라고 생각하지 않지만 다른 사람들은 동의하지 않습니다.

그것은 문제입니다. 나는 달리 말하지 않았지만 여기 사람들은 Java/C#/C++ 예외에 너무 집착하여 약간 유사한 것은 무시합니다. 정확히 왜 Swift는 throws 함수를 표시하도록 요구하여 함수에서 기대해야 하는 것과 제어 흐름이 중단될 수 있는 위치 및 Rust에서 사용하는 위치를 정확히 볼 수 있습니까? 더 많은 컨텍스트를 제공하기 위해 다양한 도우미 메서드로 오류를 명시적으로 전파합니다. 둘 다 값과 동일한 오류 개념을 사용하지만 상용구를 줄이기 위해 구문 설탕으로 포장합니다.

그리고 수백 개의 고루틴이 있는 거대한 Go 추적이 어떻게 든 더 유용할까요?

Go를 사용하면 오류가 감지된 지점의 위치와 함께 오류를 기록하여 처리합니다. 추가하기로 선택하지 않는 한 역추적은 없습니다. 그럴 필요가 딱 한 번 있었어요.

제 경험상 문제가 되지 않습니다.

글쎄, 내 경험은 다르고 대부분의 사람들의 경험은 다르다고 생각하며, 그 증거로 Java 8에 Optional 유형이 추가되었다는 사실을 인용했습니다.

이 스레드는 예외 여부에 대한 논의를 포함하여 Go 및 오류 처리 시스템의 많은 강점과 약점에 대해 논의했습니다. 이 스레드를 읽는 것이 좋습니다.

https://elixirforum.com/t/discussing-go-split-thread/13006/2

오류 처리에 2센트(위에서 그러한 아이디어가 언급된 경우 죄송합니다).

우리는 대부분의 경우 오류를 다시 던지기를 원합니다. 이는 다음과 같은 스니펫으로 이어집니다.

a, err := fn()
if err != nil {
    return err
}
use(a)
return nil

변수에 할당되지 않은 경우(추가 구문 없이) nil이 아닌 오류를 자동으로 다시 던지자. 위의 코드는 다음과 같이 됩니다.

a := fn()
use(a)

// or just

use(fn())

컴파일러는 err 를 암시적(보이지 않는) 변수에 저장하고 nil 하고 계속 진행하거나(err == nil인 경우) 반환하거나(err != nil인 경우) 반환하고 끝에 nil을 반환합니다. 일반적으로 함수 실행 중에 오류가 발생하지 않은 경우 함수의 자동 및 암시적입니다.

err 를 처리해야 하는 경우 명시적 변수에 할당하고 사용해야 합니다.

a, err := fn()
if err != nil {
    doSomething(err)
} else {
    use(a)
}
return nil

오류는 다음과 같은 방식으로 억제될 수 있습니다.

a, _ := fn()
use(a)

두 개 이상의 오류가 반환된 드문(환상적인) 경우에 명시적 오류 처리는 필수입니다(지금처럼):

err1, err2 := fn2()
if err1 != nil || err2 != nil {
    return err1, err2
}
return nil, nil

그것이 제 주장이기도 합니다. 우리는 대부분의 경우에 오류를 다시 던지기를 원합니다. 이는 일반적으로 기본 경우입니다. 그리고 약간의 컨텍스트를 제공할 수도 있습니다. 예외를 제외하고 컨텍스트는 스택 추적에 의해 자동으로 추가됩니다. Go에서와 같은 오류는 오류 메시지를 추가하여 직접 처리합니다. 왜 더 간단하게 만들지 않습니까? 그리고 그것이 바로 다른 언어들이 명확성의 문제와 균형을 맞추면서 하려고 하는 것입니다.

그래서 저는 "변수에 할당되지 않은 경우(추가 구문 없이) nil이 아닌 오류를 자동으로 다시 던지자"는 데 동의하지만 후자는 저를 괴롭힙니다. 그것이 바로 예외 문제의 근본 원인이며, 제 생각에 사람들이 자신과 약간 관련된 것에 대해 이야기하는 것을 반대하는 이유입니다. 추가 구문 없이 제어 흐름을 변경합니다. 그건 나쁜 일이야.

예를 들어 Swift를 보면 이 코드는 컴파일되지 않습니다.

func a() throws {}
func b() throws {
  a()
}

a 는 오류를 발생시킬 수 있으므로 오류를 전파하려면 try a() 를 작성해야 합니다. 당신이 제거하면 throws 에서 b 다음도 함께 컴파일되지 않습니다 try a() . b 내부의 오류를 처리해야 합니다. 이는 예외의 불명확한 제어 흐름과 Objective-C 오류의 장황함 문제를 모두 해결하는 훨씬 더 나은 오류 처리 방법입니다. 후자는 Go의 오류 및 Swift가 대체하려는 것과 거의 비슷합니다. 내가 좋아하지 않는 것은 Swift도 사용하는 try, catch 입니다. 나는 오류를 반환 값의 일부로 남겨두는 것을 훨씬 선호합니다.

그래서 제가 제안하고 싶은 것은 실제로 추가 구문을 갖는 것입니다. 따라서 호출 사이트는 제어 흐름이 변경될 수 있는 잠재적인 장소임을 자체적으로 알려줍니다. 내가 제안하는 것은 이 추가 구문을 작성하지 않으면 컴파일 오류가 발생한다는 것입니다. 지금 Go가 작동하는 방식과 달리 오류를 처리해야 합니다. 어떤 경우에는 모든 작은 오류를 처리하는 것이 매우 실망스러울 수 있기 때문에 _ 와 같은 것으로 오류를 침묵시키는 기능을 던질 수 있습니다. 예를 들어 printf . 나는 그것이 무언가를 기록하는 데 실패하더라도 상관하지 않습니다. Go에는 이미 이러한 성가신 가져오기가 있습니다. 그러나 그것은 최소한 도구로 해결되었습니다.

지금 생각할 수 있는 컴파일 시간 오류에 대한 두 가지 대안이 있습니다. 지금 Go처럼 오류를 조용히 무시하십시오. 나는 그것이 마음에 들지 않으며 그것은 항상 Go 오류 처리에 대한 내 문제였습니다. 아무 것도 강요하지 않으며 기본 동작은 오류를 자동으로 무시하는 것입니다. 그것은 당신이 강력하고 디버그하기 쉬운 프로그램을 작성하는 방법이 아닙니다. 나는 게으르거나 시간이 없을 때 Objective-C에서 너무 많은 경우가 있었고 동일한 코드에서 버그가 발생했지만 왜 발생했는지에 대한 진단 정보가 없는 오류를 무시했습니다. 적어도 로깅하면 많은 경우에 문제를 해결할 수 있습니다.

단점은 사람들이 오류를 무시하고 try, catch(...) 어디에나 배치할 수 있다는 것입니다. 그것은 가능성이 있지만 동시에 기본적으로 오류가 무시되므로 그렇게 하는 것이 훨씬 쉽습니다. 예외에 대한 논쟁은 여기에 적용되지 않는다고 생각합니다. 예외를 제외하고 일부 사람들이 달성하려고 하는 것은 프로그램이 더 안정적이라는 환상입니다. 처리되지 않은 예외가 프로그램을 충돌시킨다는 사실이 여기서 문제입니다.

다른 대안은 당황하는 것입니다. 그러나 그것은 단지 실망스럽고 예외에 대한 기억을 불러옵니다. 그것은 분명히 사람들이 프로그램이 충돌하지 않도록 "방어적" 코딩을 하도록 이끌 것입니다. 나에게 현대 언어는 컴파일 타임에 가능한 한 많은 작업을 수행하고 런타임에 가능한 한 적은 결정을 남겨야 합니다. 패닉이 적절할 수 있는 곳은 호출 스택의 맨 위에 있습니다. 예를 들어, main 함수에서 오류를 처리하지 않으면 자동으로 패닉이 발생합니다. 고루틴에도 적용되나요? 아마 하지 말아야 합니다.

왜 타협을 고려합니까?

@nick-korsakov 원래 제안(이 문제)은 오류에 더 많은 컨텍스트를 추가하려고 합니다.

오류를 무시하는 것은 이미 쉽습니다(아마도 너무 쉽습니다)(#20803 참조). 오류 처리에 대한 많은 기존 제안은 수정되지 않은 오류를 반환하는 것을 더 쉽게 만듭니다(예: #16225, #18721, #21146, #21155). 추가 정보와 함께 오류를 더 쉽게 반환할 수 있는 사람은 거의 없습니다.

이 주석 도 참조하십시오.

이 의견에서 나는 이 토론에서 진행을 하기 위해(루프에서 실행하는 것보다) 우리가 신중하게 처리된 오류 메시지와 같은 목표를 더 잘 정의해야 한다고 제안합니다. 전체 내용은 꽤 흥미롭게 읽을 수 있지만 3초 금붕어 메모리 문제의 영향을 받는 것 같습니다.

또 다른 자전거 보관소:

func makeFile(url string) (size int, err error){
    rsp, err := http.Get(url)
    try err
    defer rsp.Body.Close()

    var data dataStruct
    dec := json.NewDecoder(rsp.Body)
    err := dec.Decode(&data)
    try errors.Errorf("could not decode %s: %v", url, err)

    f, err := os.Create(data.Path)
    try errors.Errorf("could not open file %s: %v", data.Path, err)
    defer f.Close()

    return f.Write([]byte(data.Rows))
}

try 는 "빈 값이 아닌 경우 반환"을 의미합니다. 여기서는 err이 nil일 때 errors.Errorf 가 nil 반환한다고 가정합니다. 나는 이것이 쉬운 포장이라는 목표를 고수하면서 우리가 기대할 수 있는 만큼의 비용 절감이라고 생각합니다.

옵션 유형이 제정신인 이유는 무엇입니까?

표준 라이브러리의 스캐너 유형은 진행하기 전에 오류의 존재를 책임감 있게 확인할 수 있는 구조 내부의 오류 상태를 저장합니다.

type Scanner struct{
    err error
}
func (s *Scanner) Scan() bool{
   if s.err != nil{
       return false
   }
   // scanning logic
}
func (s *Scanner) Err() error{ return s.err }

유형을 사용하여 오류 상태를 저장하면 이러한 유형을 사용하는 코드를 중복 오류 검사 없이 유지할 수 있습니다.

또한 창의적이고 기괴한 구문 변경이나 언어의 예기치 않은 제어 전송이 필요하지 않습니다.

또한 try/catch와 같은 것을 제안해야 합니다. 여기서 err은 try{} 내부에 정의되어 있고 err이 nil이 아닌 값으로 설정되어 있으면 try{}에서 err 핸들러 블록(있는 경우)으로 흐름이 중단됩니다.

내부적으로는 예외가 없지만 전체가 더 가까워야 합니다.
if err != nil break 를 수행하는 구문은 err이 할당될 수 있는 모든 행 다음에 확인합니다.
예:

...
try(err) {
   err = doSomethig()
   err, value := doSomethingElse()
   doSomethingObliviousToErr()
   err = thirdErrorProneThing()
} 
catch(err SomeErrorType) {
   handleSomeSpecificErr(err)
}
catch(err Error) {
  panic(err)
}

나는 그것이 C++처럼 보인다는 것을 알고 있지만 모든 줄 뒤에 수동 if err != nil {...} 보다 잘 알려져 있고 깔끔합니다.

@처럼

스캐너 유형은 모든 작업을 수행하기 때문에 작동하므로 도중에 자체 오류를 추적할 여유가 있습니다. 이것이 보편적인 해결책이라고 스스로를 속이지 마십시오.

@carlmjohnson

간단한 오류에 대해 하나의 라이너 처리를 원하면 return 문이 한 줄 블록의 시작이 되도록 구문을 변경할 수 있습니다.
사람들이 다음과 같이 작성할 수 있습니다.

func makeFile(url string) (size int, err error){
    rsp, err := http.Get(url)
    if err != nil return err
    defer rsp.Body.Close()

    var data dataStruct
    dec := json.NewDecoder(rsp.Body)
    err := dec.Decode(&data)
    if err != nil return errors.Errorf("could not decode %s: %v", url, err)

    f, err := os.Create(data.Path)
    if err != nil return errors.Errorf("could not open file %s: %v", data.Path, err)
    defer f.Close()

    return f.Write([]byte(data.Rows))
}

사양이 다음과 같이 변경되어야 한다고 생각합니다(이것은 매우 순진할 수 있습니다 :))

Block = "{" StatementList "}" | "return" Expression .

err이 세 줄 대신 한 줄을 확인하는 경우 특수 케이싱 반환이 단순히 gofmt를 변경하는 것보다 더 낫다고 생각하지 않습니다.

@urandom

하나의 boxable 유형을 넘어서는 오류 병합 및 해당 작업은 권장되어서는 안 됩니다. 나에게 이것은 관련되지 않은 다른 작업에서 발생하는 오류 사이에 오류 컨텍스트를 래핑하거나 추가하려는 노력이 부족함을 나타냅니다.

스캐너 접근 방식은 "오류는 가치다"라는 만트라의 맥락에서 내가 읽은 최악의 것 중 하나입니다.

1. 많은 오류 처리 보일러 플레이트가 필요한 거의 모든 사용 사례에서 쓸모가 없습니다. 여러 외부 패키지를 호출하는 함수는 이점을 얻지 못합니다.
2. 복잡하고 생소한 개념이다. 이를 도입하면 미래의 독자를 혼란스럽게 만들고 언어 디자인 결함을 해결할 수 있도록 코드를 필요한 것보다 더 복잡하게 만들 것입니다.
3. 논리를 숨기고 이익을 취하지 않고 최악의 상황(복잡한 제어 흐름)을 취함으로써 예외와 유사하려고 합니다.
4. 경우에 따라 컴퓨팅 리소스가 낭비됩니다. 모든 호출은 오래 전에 발생한 쓸모없는 오류 검사에 시간을 낭비해야 합니다.
5. 오류가 발생한 정확한 위치를 숨깁니다. 일부 파일 형식을 구문 분석하거나 직렬화하는 경우를 상상해 보십시오. 일련의 읽기/쓰기 호출이 있을 것입니다. 첫 번째 실패를 상상해보십시오. 정확히 어디에서 오류가 발생했는지 어떻게 알 수 있습니까? 어떤 필드를 구문 분석하거나 직렬화했습니까? "IO 오류", "시간 초과" - 이러한 오류는 이 경우 쓸모가 없습니다. 각 읽기/쓰기에 컨텍스트를 제공할 수 있습니다(예: 필드 이름). 그러나 이 시점에서 당신에게 불리하게 작용하는 전체 접근 방식을 포기하는 것이 좋습니다.

경우에 따라 컴퓨팅 리소스가 낭비됩니다.

벤치마크? "컴퓨팅 리소스"란 정확히 무엇입니까?

오류가 발생한 정확한 위치를 숨깁니다.

아니오, 그렇지 않습니다. nil이 아닌 오류는 덮어쓰지 않기 때문입니다.

여러 외부 패키지를 호출하는 함수는 이점을 얻지 못합니다.
복잡하고 생소한 개념
스캐너 접근 방식은 이 전체 "오류는 값입니다"라는 맥락에서 읽은 최악의 것 중 하나입니다.

내 인상은 당신이 접근 방식을 이해하지 못한다는 것입니다. 논리적으로 독립적인 유형의 일반 오류 검사와 동일합니다. 예제를 자세히 연구하여 아마도 _읽는 것 중 가장 나쁜 것보다 가장 나쁜 것이 될 수 있도록 예제를 자세히 연구하는 것이 좋습니다.

죄송합니다. 제 제안을 더미에 추가하겠습니다. 나는 여기에 있는 대부분의 내용을 읽었고 일부 제안은 마음에 들지만 그들이 너무 많은 일을 하려고 한다는 생각이 듭니다. 문제는 오류 상용구입니다. 내 제안은 단순히 구문 수준에서 해당 상용구를 제거하고 오류가 전달되는 방식을 그대로 두는 것입니다.

제안

_! 토큰을 nil이 아닌 error 값이 할당될 때 패닉을 일으키는 구문 설탕으로 사용하여 오류 상용구를 줄입니다.

val, err := something.MayError()
if err != nil {
    panic(err)
}

될 수 있었다

val, _! := something.MayError()

그리고

if err := something.MayError(); err != nil {
    panic(err)
}

될 수 있었다

_! = something.MayError()

물론 특정 기호는 논쟁의 여지가 있습니다. _^ , _* , @ 등도 고려했습니다. 한 눈에 가장 친숙할 것 같아서 사실상의 제안으로 _! 를 선택했습니다.

구문적으로 _! (또는 선택한 토큰)은 사용되는 범위에서 사용할 수 있는 error 유형의 기호입니다. nil 로 시작하고 할당될 때마다 nil 검사가 수행됩니다. nil이 아닌 error 값으로 설정하면 패닉이 시작됩니다. _! (또는 선택한 토큰)는 go에서 구문적으로 유효한 식별자가 아니기 때문에 이름 충돌은 문제가 되지 않습니다. 이 미묘한 변수는 명명된 반환 값과 유사하게 사용되는 범위에서만 도입됩니다. 구문적으로 유효한 식별자가 필요한 경우 컴파일 시간에 고유한 이름으로 다시 작성되는 자리 표시자를 사용할 수 있습니다.

정당화

내가 볼 때 평준화되는 더 일반적인 비판 중 하나는 오류 처리의 장황함입니다. API 경계의 오류는 나쁜 것이 아닙니다. API 경계에 대한 오류를 가져와야 하는 것은 특히 심도 있는 재귀 알고리즘의 경우 고통스러울 수 있습니다. 재귀 코드에 추가된 자세한 오류 전파를 피하기 위해 패닉을 사용할 수 있습니다. 이것은 꽤 일반적으로 사용되는 기술이라고 생각합니다. 내 자신의 코드에서 사용했으며 go의 파서를 포함하여 야생에서 사용되는 것을 보았습니다. 때로는 프로그램의 다른 곳에서 유효성 검사를 수행했으며 오류가 0일 것으로 예상합니다. nil이 아닌 오류가 수신되면 이는 불변을 위반하게 됩니다. 불변량이 위반되면 당황할 수 있습니다. 복잡한 초기화 코드에서는 때때로 오류를 패닉 상태로 만들고 컨텍스트에 대한 더 많은 지식이 있는 곳에서 반환되도록 복구하는 것이 합리적입니다. 이러한 모든 시나리오에는 오류 상용구를 줄일 수 있는 기회가 있습니다.

최대한 공황상태에 빠지지 않는 것이 바둑의 철학임을 깨달았다. API 경계를 넘어 오류 전파를 위한 도구가 아닙니다. 그러나 이는 언어의 기능이며 위에서 설명한 것과 같은 합법적인 사용 사례가 있습니다. 패닉은 개인 코드에서 오류 전파를 단순화하는 환상적인 방법이며 구문 단순화는 코드를 더 깨끗하고 틀림없이 더 명확하게 만드는 데 큰 도움이 될 것입니다. _! (or @ , `_^ 등... ) 을 'if-error-panic' 형식보다 한 눈에 알아보기 쉽다고 생각합니다. 토큰은 전달/이해하기 위해 작성/읽기해야 하는 코드의 양을 크게 줄일 수 있습니다.

1. 오류가 있을 수 있습니다
2. 오류가 있는 경우 예상하지 않습니다.
3. 오류가 있는 경우 아마도 체인에서 처리되고 있을 것입니다.

모든 구문 기능과 마찬가지로 남용의 가능성이 있습니다. 이 경우 go 커뮤니티에는 이미 패닉을 다루는 모범 사례가 있습니다. 이 구문 추가는 패닉에 대한 구문 설탕이므로 해당 모범 사례 집합을 사용에 적용할 수 있습니다.

패닉에 대한 수용 가능한 사용 사례를 단순화하는 것 외에도 빠른 프로토타이핑을 더 쉽게 만듭니다. 코드에 기록하고 싶은 아이디어가 있고 장난을 치는 동안 오류로 인해 프로그램이 중단되기를 원하는 경우 "if-error-panic" 형식 대신 이 구문 추가를 사용할 수 있습니다. 개발 초기 단계에서 더 적은 줄로 나를 표현할 수 있다면 더 빨리 내 아이디어를 코드로 구현할 수 있습니다. 코드에 대한 완전한 아이디어가 있으면 돌아가서 적절한 경계에서 오류를 반환하도록 코드를 리팩토링합니다. 나는 프로덕션 코드에 무료 패닉을 남기지 않겠지만 강력한 개발 도구가 될 수 있습니다.

패닉은 다른 이름의 예외일 뿐이고, 내가 Go에 대해 좋아하는 한 가지는 예외가 예외적이라는 것입니다. 나는 그들에게 구문상의 설탕을 주어 더 많은 예외를 조장하고 싶지 않습니다.

@carlmjohnson 두 가지 중 하나가 사실이어야 합니다.

1. 공황은 합법적인 사용 사례가 있는 언어의 일부이거나
2. 패닉에는 합법적인 사용 사례가 없으므로 언어에서 제거해야 합니다.

나는 대답이 1이라고 생각합니다.
나는 또한 "공황은 다른 이름의 예외일 뿐"이라는 데 동의하지 않습니다. 그런 악수는 진정한 토론을 방해한다고 생각합니다. 대부분의 다른 언어에서 볼 수 있듯이 패닉과 예외 사이에는 주요 차이점이 있습니다.

나는 무릎 꿇는 "공황이 나쁘다"라는 반응을 이해하지만 공황 사용에 대한 개인적인 감정은 공황이 사용된다는 사실을 바꾸지 않으며 실제로 유용합니다. go 컴파일러는 파서와 유형 검사 단계(내가 마지막으로 본) 모두에서 심도 있는 재귀 프로세스를 피하기 위해 패닉을 사용합니다.
심도 있는 재귀 코드를 통해 오류를 전파하는 데 사용하는 것은 허용되는 사용일 뿐만 아니라 go 개발자가 승인한 사용으로 보입니다.

패닉은 다음과 같은 구체적인 내용을 전달합니다.

뭔가 여기 핸들에 준비되지 않았 음을 잘못 여기에 갔다

그것이 사실인 코드의 위치는 항상 있을 것입니다. 특히 개발 초기에. Go는 이전에 리팩토링 경험을 개선하기 위해 수정되었습니다: 유형 별칭 추가. 소스에 더 가까운 수준에서 처리할 수 있는지 여부와 방법을 구체화할 수 있을 때까지 원치 않는 오류를 패닉 상태로 전파할 수 있으면 코드를 작성하고 점진적으로 리팩토링하는 것이 훨씬 덜 장황해집니다.

여기 있는 대부분의 제안이 언어에 대한 큰 변화를 제안하는 것 같습니다. 이것은 내가 생각해낼 수 있는 가장 투명한 접근 방식입니다. 이는 오류 처리의 전체 현재 인지 모델을 그대로 유지하면서 특정하지만 일반적인 경우에 대한 구문 축소를 가능하게 합니다. 모범 사례는 현재 "go 코드가 API 경계를 넘어 패닉해서는 안 된다"고 명시하고 있습니다. 패키지에 공개 메서드가 있는 경우 오류를 복구할 수 없는 드문 경우(예: 불변 위반)를 제외하고 문제가 발생하면 오류를 반환해야 합니다. 이 언어 추가는 해당 모범 사례를 대체하지 않습니다. 이것은 단순히 내부 코드의 상용구를 줄이고 스케치 아이디어를 더 명확하게 만드는 방법입니다. 확실히 코드를 선형으로 읽기 쉽게 만듭니다.

var1, _! := trySomeTask1()
var2, _! := trySomeTask2(var1)
var3, _! := trySomeTask3(var2)
var4, _! := trySomeTask4(var3)

보다 훨씬 읽기 쉽습니다.

var1, err := trySomeTask1()
if err != nil {
    panic(err)
}
var2, err := trySomeTask2(var1)
if err != nil {
    panic(err)
}
var3, err := trySomeTask3(var2)
if err != nil {
    panic(err)
}
var4, err := trySomeTask4(var3)
if err != nil {
    panic(err)
}

Go의 패닉과 Java 또는 Python 등의 예외 사이에는 구문과 객체 계층 구조의 부족(Go에는 상속이 없기 때문에 의미가 있음)을 제외하고는 근본적인 차이가 없습니다. 작동 방식과 사용 방식은 동일합니다.

물론 공황은 언어에서 정당한 위치를 차지합니다. 패닉은 다른 방법으로는 복구할 수 없는 프로그래머 오류로 인해 발생해야 하는 오류를 처리하기 위한 것입니다. 예를 들어, 정수 컨텍스트에서 0으로 나누면 가능한 반환 값이 없으며 먼저 0을 확인하지 않은 자신의 잘못이므로 패닉이 발생합니다. 마찬가지로, 범위를 벗어난 슬라이스를 읽으면 nil을 값으로 사용하는 등의 작업을 시도합니다. 이는 네트워크가 다운되거나 파일에 잘못된 권한이 있는 것과 같은 예상되는 조건이 아니라 프로그래머 오류로 인해 발생하므로 당황하게 됩니다. 그리고 스택을 날려버리세요. Go는 템플릿과 같이 패닉하는 몇 가지 도우미 함수를 제공합니다. 프로그래머 오류로 인해 오류가 발생해야 하는 하드코딩된 문자열과 함께 사용할 것으로 예상되기 때문에 반드시 필요합니다. 메모리 부족은 그 자체로 프로그래머 오류가 아니지만 복구할 수 없고 어디에서나 발생할 수 있으므로 오류가 아니라 패닉입니다.

사람들은 또한 때때로 패닉을 스택을 단락시키는 방법으로 사용하지만 일반적으로 가독성과 성능상의 이유로 눈살을 찌푸리며 Go가 사용을 장려하기 위해 변경할 가능성은 보이지 않습니다.

Go 패닉과 Java의 확인되지 않은 예외는 거의 동일하며 동일한 이유와 동일한 사용 사례를 처리하기 위해 존재합니다. 다른 언어의 예외와 동일한 문제가 있기 때문에 사람들이 다른 경우에 대해 패닉을 사용하도록 권장하지 마십시오.

사람들은 때때로 스택을 단락시키는 방법으로 패닉을 사용하지만 일반적으로 가독성과 성능상의 이유로 눈살을 찌푸립니다.

우선, 가독성 문제는 이 구문 변경이 직접 해결하는 문제입니다.

// clearly, linearly shows that these steps must occur in order,
// and any errors returned cause a panic, because this piece of
// code isn't responsible for reporting or handling possible failures:
// - IO Error: either network or disk read/write failed
// - External service error: some unexpected response from the external service
// - etc...
// It's not this code's responsibility to be aware of or handle those scenarios.
// That's perhaps the parent process's job.
var1, _! := trySomeTask1()
var2, _! := trySomeTask2(var1)
var3, _! := trySomeTask3(var2)
var4, _! := trySomeTask4(var3)

대

var1, err := trySomeTask1()
if err != nil {
    panic(err)
}
var2, err := trySomeTask2(var1)
if err != nil {
    panic(err)
}
var3, err := trySomeTask3(var2)
if err != nil {
    panic(err)
}
var4, err := trySomeTask4(var3)
if err != nil {
    panic(err)
}

가독성을 잠시 제쳐두고 다른 이유는 성능입니다.
예, 패닉 및 지연 문을 사용하면 성능이 저하되는 것은 사실이지만 많은 경우 이 차이는 수행 중인 작업에 대해 무시할 수 있습니다. 평균적으로 디스크 및 네트워크 IO는 지연/패닉 관리를 위한 잠재적인 스택 마술보다 훨씬 더 오래 걸립니다.

패닉에 대해 이야기할 때 이 점을 많이 앵무새로 들었는데, 패닉이 성능 저하라고 말하는 것은 사실이 아니라고 생각합니다. 확실히 그럴 수 있지만 반드시 그럴 필요는 없습니다. 언어의 다른 많은 것들처럼. 성능 적중이 실제로 중요한 빡빡한 루프 내부에서 패닉 상태에 빠지면 해당 루프 내에서 연기하지 않아야 합니다. 사실, 패닉을 선택하는 함수는 일반적으로 자체 패닉을 잡아서는 안 됩니다. 마찬가지로, 오늘 작성된 go 함수는 오류 와 패닉을 모두 반환하지 않습니다. 그것은 불분명하고 어리석고 모범 사례가 아닙니다. 아마도 이것이 우리가 Java, Python, Javascript 등에서 사용되는 예외를 보는 데 익숙해진 방법일 수 있지만 일반적으로 go 코드에서 패닉이 사용되는 방식은 아니며 오류를 전파하는 경우를 위해 특별히 연산자를 추가하는 것이 아니라고 생각합니다. 패닉을 통해 호출 스택을 올리면 사람들이 패닉을 사용하는 방식이 바뀔 것입니다. 그들은 어쨌든 공황을 사용하고 있습니다. 이 구문 확장의 요점은 개발자가 패닉을 사용하고 완벽하게 합법적인 용도가 있다는 사실을 인정 하고 주변의 상용구를 줄이는 것입니다.

이 구문 기능이 가능하다고 생각하지만 현재 가능하지 않거나 모범 사례에 어긋나는 문제가 있는 코드의 몇 가지 예를 들어 주시겠습니까? 누군가가 패닉/복구를 통해 코드 사용자에게 오류를 전달하는 경우, 이는 현재 눈살을 찌푸리게 하고 분명히 이와 같은 구문이 추가되더라도 여전히 계속될 것입니다. 가능하시다면 다음 답변을 부탁드립니다.

1. 이와 같은 구문 확장으로 인해 어떤 남용이 발생할 것이라고 상상하십니까?
2. var1, err := trySomeTask1(); if err != nil { panic(err) } 는 var1, _! := trySomeTask1() 가 전달하지 않는 것을 무엇을 전달합니까? 왜요?

당신 주장의 핵심은 "공황 상태가 심하고 우리는 그것을 사용해서는 안 된다"는 것입니다.
그것들이 공유되지 않는다면 나는 그 이유를 풀고 토론할 수 없습니다.

이러한 것들은 네트워크 다운이나 잘못된 권한이 있는 파일과 같은 예상되는 조건이 아니라 프로그래머 오류로 인해 발생하므로 패닉 상태에 빠지고 스택이 폭발합니다.

나는 대부분의 gophers와 마찬가지로 오류를 가치로 보는 아이디어를 좋아합니다. 문서를 볼 필요 없이 API의 어떤 부분이 결과를 보장하고 어떤 부분이 실패할 수 있는지 명확하게 전달하는 데 도움이 된다고 생각합니다.

그것은 오류를 수집하고 더 많은 정보로 오류를 보강하는 것과 같은 것을 허용합니다. 이는 코드가 사용자 코드와 교차하는 API 경계에서 매우 중요합니다. 그러나 이러한 API 경계 내에서 오류로 모든 작업을 수행할 필요는 없는 경우가 많습니다 . 특히 행복한 경로를 예상하고 해당 경로가 실패할 경우 오류 처리를 담당하는 다른 코드가 있는 경우.

오류를 처리하는 것이 코드의 일이 아닌 경우가 있습니다.
라이브러리를 작성 중이라면 네트워크 스택이 다운되더라도 상관하지 않습니다. 이는 라이브러리 개발자로서 제어할 수 없는 일입니다. 해당 오류를 사용자 코드로 다시 반환하겠습니다.

내 자신의 코드에서도 부모 함수에 오류를 되돌려주는 역할만 하는 코드를 작성하는 경우가 있습니다.

예를 들어, 응답으로 디스크에서 파일을 읽는 http.HandlerFunc가 있다고 가정합니다. 이것은 거의 항상 작동하며 실패하면 프로그램이 제대로 작성되지 않았거나(프로그래머 오류) 파일 시스템에 문제가 있을 수 있습니다. 프로그램의 책임 범위를 벗어납니다. http.HandlerFunc 패닉이 발생하면 종료되고 일부 기본 핸들러가 해당 패닉을 포착하여 클라이언트에 500을 씁니다. 나중에 해당 오류를 다르게 처리하고 싶은 경우 _! 를 err 바꾸고 오류 값으로 원하는 모든 작업을 수행할 수 있습니다. 문제는 프로그램의 수명 동안 그렇게 할 필요가 없을 것입니다. 그런 문제가 발생하면 핸들러는 해당 오류를 처리하는 코드의 일부가 아닙니다.

IO 실패, 네트워크 실패 등과 같은 경우 핸들러에 if err != nil { panic(err) } 또는 if err != nil { return ..., err } 를 쓸 수 있고 일반적으로 그렇게 합니다. 오류를 확인해야 할 때 여전히 그렇게 할 수 있습니다. 하지만 대부분의 경우 if err != nil { panic(err) } 만 쓰고 있습니다.

또는 또 다른 예입니다. 재귀적으로 trie를 검색하는 경우(예: http 라우터 구현에서) func (root *Node) Find(path string) (found Value, err error) 함수를 선언합니다. 이 함수는 트리 아래로 내려가면서 발생하는 모든 패닉을 복구하는 함수를 연기합니다. 프로그램이 잘못된 시도를 생성하면 어떻게 됩니까? 프로그램이 올바른 권한을 가진 사용자로 실행되지 않아 일부 IO가 실패하면 어떻게 됩니까? 이러한 문제는 내가 나중에 명시적으로 확인하지 않는 한 내 시도 검색 알고리즘의 문제가 아니지만 내가 접할 수 있는 오류일 수 있습니다. 스택의 모든 방법을 반환하면 스택에서 이상적으로는 몇 개의 nil 오류 값을 유지하는 것을 포함하여 많은 추가 정보가 필요합니다. 대신 해당 공용 API 함수까지 오류를 패닉시키고 사용자에게 반환하도록 선택할 수 있습니다. 현재로서는 여전히 추가 정보가 필요하지만 반드시 그럴 필요는 없습니다.

다른 제안에서는 하나의 반환 값을 특별하게 처리하는 방법에 대해 논의하고 있습니다. 본질적으로 같은 생각이지만 언어에 이미 내장된 기능을 사용하는 대신 특정 경우에 대해 언어의 동작을 수정하려고 합니다. 구현의 용이성 측면에서 이러한 유형의 제안(이미 지원되는 구문 설탕)이 가장 쉬울 것입니다.

추가하려면 편집:
제가 작성한 제안과 결혼한 상태는 아니지만, 오류 처리 문제를 새로운 각도에서 바라보는 것이 중요하다고 생각합니다. 아무도 그 참신한 것을 제안하지 않으며, 나는 우리가 이 문제에 대한 우리의 이해를 재구성할 수 있는지 알고 싶습니다. 문제는 오류가 필요하지 않을 때 명시적으로 오류가 처리되는 위치가 너무 많고 개발자가 추가 상용구 코드 없이 오류를 스택 위로 전파하는 방법을 원한다는 것입니다. Go에는 이미 해당 기능이 있지만 이에 대한 좋은 구문은 없습니다. 이것은 동작을 변경하지 않고 언어를 보다 인체공학적으로 만들기 위해 덜 장황한 구문으로 기존 기능을 래핑하는 것에 대한 논의입니다. 우리가 이룰 수 있다면 그것이 승리가 아닌가?

@mccolljr 감사합니다. 하지만 이 제안의 목표 중 하나는 오류를 무시하고, 수정되지 않은 상태로 오류를 반환하고, 추가 컨텍스트 정보와 함께 오류를 반환하는 오류 처리의 세 가지 경우를 모두 처리하는 새로운 방법을 개발하도록 사람들을 격려하는 것입니다. 당신의 패닉 제안은 세 번째 경우를 다루지 않습니다. 중요한 것입니다.

@mccolljr API 경계는 당신이 생각하는 것보다 훨씬 더 일반적이라고 생각합니다. API 내 호출을 일반적인 경우로 보지 않습니다. 다른 경우일 수 있습니다(일부 데이터는 여기에서 흥미로울 것입니다). 따라서 API 내 호출을 위한 특수 구문을 개발하는 것이 올바른 방향인지 확신할 수 없습니다. 또한 API 내에서 panic ed 오류 대신 return ed 오류를 사용하는 것이 일반적으로 좋은 방법입니다(특히 이 문제에 대한 계획이 있는 경우). panic ed 오류는 용도가 있지만 분명히 더 나은 상황은 드물어 보입니다.

나는 패닉을 통해 호출 스택 위로 오류를 전파하는 경우를 위해 특별히 연산자를 추가하는 것이 사람들이 패닉을 사용하는 방식을 바꿀 것이라고 믿지 않습니다.

당신이 틀렸다고 생각합니다. 사람들은 당신의 속기 연산자가 너무 편리하기 때문에 손을 뻗을 것이고, 결국 이전보다 더 많이 패닉을 사용하게 될 것입니다.

패닉이 때때로 유용한지 또는 드물게 유용한지, API 경계를 넘어 유용한지 여부는 적청입니다. 오류에 대해 취할 수 있는 조치가 많이 있습니다. 우리는 한 작업을 다른 작업보다 우선시하지 않고 오류 처리 코드를 줄이는 방법을 찾고 있습니다.

그러나 많은 경우 이 차이는 수행 중인 작업에 대해 무시할 수 있습니다.

사실이지만, 나는 그것이 가야 할 위험한 길이라고 생각합니다. 처음에는 무시해도 될 정도로 쌓여서 나중에 이미 늦은 시간에 병목 현상을 일으킬 것입니다. 처음부터 성능을 염두에 두고 더 나은 솔루션을 찾아야 한다고 생각합니다. 이미 언급한 Swift와 Rust에는 오류 전파가 있지만 기본적으로 구문 설탕에 싸인 단순 반환으로 구현합니다. 예, 기존 솔루션을 재사용하는 것은 쉽지만 단순화하고 사람들이 기본적으로 예외라는 사실을 숨기려는 익숙하지 않은 구문 설탕 뒤에 숨겨진 공황을 사용하도록 권장하는 것보다 모든 것을 그대로 두는 것을 선호합니다.

처음에는 무시해도 될 정도로 쌓여서 나중에 이미 늦은 시간에 병목 현상을 일으킬 것입니다.

고맙지 만 사양 할게. 가상의 성능 병목 현상은 기하학적으로 무시할 수 있는 성능 병목 현상입니다.

고맙지 만 사양 할게. 가상의 성능 병목 현상은 기하학적으로 무시할 수 있는 성능 병목 현상입니다.

이 주제에서 개인적인 느낌을 남겨주세요. 당신은 분명히 저에게 문제가 있고 유용한 정보를 제공하고 싶지 않습니다. 그래서 제 의견을 무시하고 이전에 거의 모든 의견에 대해 했던 것처럼 반대 투표를 남겨주세요. 이 무의미한 답변을 계속 게시할 필요가 없습니다.

나는 당신에게 문제가 없습니다. 당신은 그것을 뒷받침할 어떤 데이터도 없이 성능 병목 현상에 대해 주장하고 있으며 나는 그것을 단어와 엄지손가락으로 지적하고 있습니다.

여러분, 대화를 정중하고 주제에 맞게 유지하십시오. 이 문제는 Go 오류 처리에 관한 것입니다.

https://golang.org/conduct

오류를 무시하는 것이 이미 존재하는 _ 이미 포함되어 있다고 가정하기 때문에 "return error/with additional context" 부분을 다시 방문하고 싶습니다.

(선택적으로) 문자열이 뒤따를 수 있는 2단어 키워드를 제안합니다. 두 단어로 된 키워드인 이유는 두 가지입니다. 첫째, 본질적으로 비밀스러운 연산자와 달리 너무 많은 사전 지식 없이도 수행하는 작업을 파악하는 것이 더 쉽습니다. 할당된 오류가 없는 or 라는 단어가 nil이 아닌 경우 여기에서 오류가 처리되고 있음을 사용자에게 나타내기를 희망하기 때문에 "또는 거품"을 선택했습니다. 일부 사용자는 이미 연결합니다 or 다른 언어 (펄, 파이썬)에서 falsy 값을 처리하고, 읽는 data := Foo() or ... 무의식적으로 그들에게 수 data 사용할 수 없게 된 경우 or 명령문의 bubble 키워드는 비교적 짧지만 사용자에게 무언가가 올라가고 있음을 나타낼 수 있습니다(스택). up 단어도 적합할 수 있지만 전체 or up 가 충분히 이해할 수 있는지 확실하지 않습니다. 마지막으로, 모든 것이 키워드인데, 무엇보다도 가독성이 더 높기 때문에 그리고 두 번째로 그 동작을 함수 자체로 작성할 수 없기 때문입니다. t 스스로 멈추면 다른 사람이 회복해야 합니다).

다음은 오류 전파만을 위한 것이므로 오류를 반환하는 함수와 다른 반환 인수의 0 값에만 사용할 수 있습니다.

어떤 식으로든 수정하지 않고 오류를 반환하는 경우:

func Worker(path string) ([]byte, error) {
    data := ioutil.ReadFile(path) or bubble

    return data;
}

추가 메시지와 함께 오류를 반환하는 경우:

func Worker(path string) ([]byte, error) {
    data := ioutil.ReadFile(path) or bubble fmt.Sprintf("reading file %s", path)

    modified := modifyData(data) or bubble "modifying the data"

    return data;
}

마지막으로 사용자 지정 오류 수정을 위한 전역 어댑터 메커니즘을 도입합니다.

// Default Bubble Processor
errors.BubbleProcessor(func(msg string, err error) error {
    return fmt.Errorf("%s: %v", msg, err)
})

// Some program might register the following:
errors.BubbleProcessor(func(msg string, err error) error {
    return errors.WithMessage(err, msg)
})

마지막으로, 정말 복잡한 처리가 필요한 몇몇 장소에서는 이미 존재하는 장황한 방법이 이미 최선의 방법입니다.

흥미로운. 전역 버블 핸들러를 사용하면 스택 추적을 원하는 사람들이 추적을 호출할 수 있는 장소를 제공하는데, 이는 해당 방법의 좋은 이점입니다. OTOH, func(string, error) error 시그니처가 있으면 버블링은 error 구현하는 구체적인 유형과 같은 다른 유형이 아니라 기본 제공 오류 유형으로 수행되어야 함을 의미합니다.

또한 or bubble 의 존재는 or die 또는 or panic 의 가능성을 암시합니다. 그것이 기능인지 버그인지 잘 모르겠습니다.

본질적으로 비밀스러운 연산자와 달리 너무 많은 사전 지식 없이도 수행하는 작업을 파악하는 것이 더 쉽습니다.

처음 접했을 때 좋을 것 같습니다. 그러나 반복해서 읽고 쓰는 것은 너무 장황하고 아주 간단한 것을 전달하기에는 너무 많은 공간을 차지합니다. 스택에 거품이 생기는 처리되지 않은 오류입니다. 연산자는 처음에는 애매하지만 간결하고 다른 모든 코드와 잘 대조됩니다. 그들은 실제로 구분자이기 때문에 오류 처리에서 주요 논리를 명확하게 분리합니다. 한 줄에 너무 많은 단어가 있으면 제 생각에는 가독성이 떨어질 것입니다. 최소한 orbubble 로 병합하거나 그 중 하나를 삭제하십시오. 나는 거기에 두 개의 키워드가 있다는 요점을 보지 못합니다. Go를 음성 언어로 변환하고 어떻게 진행되는지 알고 있습니다(예: VB).

나는 글로벌 어댑터의 팬이 아닙니다. 내 패키지가 맞춤형 프로세서를 설정하고 당신의 패키지도 맞춤형 프로세서를 설정한다면 누구의 승자는?

@object88
기본 로거와 비슷하다고 생각합니다. 출력을 프로그램에서 한 번만 설정하면 사용하는 모든 패키지에 영향을 줍니다.

오류 처리는 로깅과 매우 다릅니다. 하나는 프로그램의 정보 출력을 설명하고 다른 하나는 프로그램의 흐름을 관리합니다. 내 패키지에서 논리적 흐름을 적절하게 관리해야 하는 한 가지 작업을 수행하도록 어댑터를 설정하고 다른 패키지나 프로그램이 이를 변경하면 잘못된 위치에 있는 것입니다.

Try Catch Final을 다시 가져와서 더 이상 싸움이 필요하지 않습니다. 그것은 모두를 행복하게 만듭니다. 다른 프로그래밍 언어에서 기능과 구문을 차용하는 데 아무런 문제가 없습니다. Java가 그렇게 했고 C#도 그렇게 했으며 둘 다 정말 성공적인 프로그래밍 언어입니다. GO 커뮤니티(또는 저자)는 필요할 때 변경 사항을 수용할 수 있습니다.

@KamyarM , 나는 정중하게 동의하지 않습니다. try/catch는 모두를 행복하게 하지 _않습니다_. 코드에서 이를 구현하려는 경우에도 예외가 발생하면 코드를 사용하는 모든 사람이 예외를 처리해야 합니다. 이는 코드에 맞게 지역화할 수 있는 언어 변경 사항이 아닙니다.

@object88
사실, 버블 프로세서는 프로그램의 유익한 오류 출력을 설명하므로 로거와 크게 다르지 않은 것 같습니다. 그리고 나는 당신이 애플리케이션 전체에 걸쳐 단일 오류 표현을 원하고 패키지마다 다르지 않기를 원한다고 상상합니다.

짧은 예를 제공할 수 있지만 제가 놓치고 있는 부분이 있을 수 있습니다.

엄지척 해주셔서 정말 감사합니다. 그것이 바로 내가 말하는 문제입니다. GO 커뮤니티는 변경 사항에 대해 개방적이지 않으며 저는 그것을 느끼고 정말로 좋아하지 않습니다.

이것은 아마도 이 경우와 관련이 없지만 C++의 삼항 연산자에 해당하는 Go에 대해 다른 날을 찾고 있었고 이 대체 접근 방식을 발견했습니다.

v := map[bool]int{true: first_expression, false: second_expression} [조건]
단순히 대신
v= 조건 ? 첫 번째 표현식 : 두 번째 표현식;

여러분은 2가지 형태 중 어떤 것을 선호하시나요? 성능 문제가 많은 위의 읽을 수 없는 코드(Go My Way) 또는 C++(Highway)의 두 번째 간단한 구문? 나는 고속도로 사람을 선호합니다. 나는 당신에 대해 모른다.

요약하자면 새로운 구문을 가져와서 다른 프로그래밍 언어에서 차용하십시오. 아무 문제가 없습니다.

친애하는,

GO 커뮤니티는 변경 사항에 대해 개방적이지 않으며 저는 그것을 느끼고 정말로 좋아하지 않습니다.

나는 이것이 당신이 경험하고 있는 것의 기저에 깔린 태도를 잘못 특성화했다고 생각합니다. 예, 커뮤니티는 누군가가 try/catch 또는 ?:를 제안할 때 많은 푸시백을 생성합니다. 그러나 그 이유는 우리가 새로운 아이디어에 저항하기 때문이 아닙니다. 우리는 거의 모두 이러한 기능이 있는 언어를 사용한 경험이 있습니다. 우리는 그것들에 매우 익숙하며 우리 중 누군가는 몇 년 동안 매일 그것들을 사용해 왔습니다. 우리의 저항은 이것이 새로운 것이 아니라 _오래된 생각_이라는 사실에 근거합니다. 우리는 이미 변경 사항을 수용했습니다. try/catch에서 변경하고 ?:를 사용하지 않는 변경입니다. 우리가 저항하는 것은 우리가 이미 사용하고 좋아하지 않는 것들을 사용하도록 _back_을 변경하는 것입니다.

사실, 버블 프로세서는 프로그램의 유익한 오류 출력을 설명하므로 로거와 크게 다르지 않은 것 같습니다. 그리고 나는 당신이 애플리케이션 전체에 걸쳐 단일 오류 표현을 원하고 패키지마다 다르지 않기를 원한다고 상상합니다.

누군가가 버블링을 사용하여 스택 추적을 전달한 다음 이를 사용하여 결정을 내리길 원하면 어떻게 될까요? 예를 들어, 오류가 파일 작업에서 비롯된 경우 실패하지만 네트워크에서 발생한 경우 기다렸다가 다시 시도하십시오. 이에 대한 일부 논리를 오류 처리기에 빌드하는 것을 볼 수 있지만 런타임당 오류 처리기가 하나만 있는 경우 충돌의 원인이 됩니다.

@urandom , 아마도 이것은 사소한 예일 수 있지만 내 어댑터가 내 코드의 다른 곳에서 사용할 것으로 예상되는 error 를 구현하는 또 다른 구조체를 반환한다고 가정해 보겠습니다. 다른 어댑터가 와서 내 어댑터를 교체하면 내 코드가 올바르게 작동하지 않습니다.

@KamyarM 언어와 관용구는 함께 갑니다. 오류 처리에 대한 변경 사항을 고려할 때 구문 변경뿐 아니라 (잠재적으로) 코드의 구조 자체도 변경하는 것입니다.

Try-catch-finally는 그러한 변화에 매우 침습적일 것입니다. 바둑 프로그램이 구조화되는 방식을 근본적으로 바꿀 것입니다. 대조적으로, 여기에서 볼 수 있는 다른 제안의 대부분은 각 함수에 대해 로컬입니다. 오류는 여전히 명시적으로 반환되는 값이고, 제어 흐름은 로컬이 아닌 점프를 방지합니다.

삼항 연산자의 예를 사용하려면: 예, 오늘 지도를 사용하여 가짜 연산자를 만들 수 있지만 실제로 프로덕션 코드에서 찾지 않기를 바랍니다. 관용구를 따르지 않습니다. 대신 일반적으로 다음과 같이 표시됩니다.

    var v int
    if condition {
        v = first_expression
    } else {
        v = second_expression
    }

구문을 빌리고 싶지 않다는 것이 아니라 오늘날 이미 존재하는 나머지 언어 및 나머지 코드에 어떻게 들어맞을지 고려해야 한다는 것입니다.

@KamyarM 저는 Go와 Java를 모두 사용하며 Go가 Java에서 예외 처리를 복사하는 것을 단호하게 _싫습니다_. Java를 원하면 Java를 사용하십시오. 그리고 삼항 연산자에 대한 논의를 적절한 문제(예: #23248)로 가져오십시오.

@lpar 그래서 내가 회사에서 일하고 어떤 알 수 없는 이유로 GoLang을 프로그래밍 언어로 선택했다면 직장을 그만두고 Java 언어를 신청하면 됩니다!? 가자!

@bcmills 거기에서 제안한 코드를 셀 수 있습니다. 한 줄 대신 6줄의 코드가 필요하다고 생각합니다. 아마 그에 대한 몇 가지 코드 순환적 복잡성 포인트를 얻을 수 있을 것입니다(여러분은 Linter를 사용합니다. 맞죠?).

@carlmjohnson 및 @bcmills 오래되고 성숙한 구문이 나쁘다는 의미는 아닙니다. 실제로 if else 구문이 삼항 연산자 구문보다 훨씬 오래되었다고 생각합니다.

이 GO 관용구를 가져오길 잘했습니다. 이것이 바로 이 언어의 문제 중 하나라고 생각합니다. 변경 요청이 있을 때마다 누군가는 Go 관용구에 위배되는 oh no라고 말합니다. 나는 그것을 변화에 저항하고 새로운 아이디어를 차단하기 위한 변명일 뿐이라고 생각합니다.

@KamyarM 정중히 부탁드립니다. 언어를 작게 유지하는 것에 대한 생각에 대해 더 알고 싶다면 https://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html을 추천

또한 최근 try/catch 토론과 관련이 없는 일반적인 설명입니다.

이 스레드에는 많은 제안이 있었습니다. 스스로에게 말해서, 나는 여전히 내가 해결해야 할 문제에 대해 강한 이해를 갖고 있지 않다고 생각합니다. 나는 그들에 대해 더 듣고 싶습니다.

나는 또한 누군가가 논의된 문제의 체계적이고 요약된 목록을 유지 관리하는 부끄럽지만 중요한 작업을 수행하고 싶어한다면 기쁠 것입니다.

@josharian 그냥 솔직하게 얘기했어요. 언어나 커뮤니티에서 정확한 문제를 보여주고 싶었습니다. 더 많은 비판으로 생각하십시오. GoLang은 비판에 열려 있습니다. 맞습니까?

@KamyarM 프로그래밍 언어로 Rust를 선택한 회사에서 일했다면 Rust Github에 가서 가비지 수집 메모리 관리와 C++ 스타일 포인터를 요구하기 시작하여 차용 검사기를 다룰 필요가 없습니까?

Go 프로그래머가 Java 스타일 예외를 원하지 않는 이유는 익숙하지 않은 것과 관련이 없습니다. 나는 1988년 Lisp를 통해 예외를 처음 접했고 이 스레드에 더 일찍 예외를 만난 다른 사람들이 있을 것이라고 확신합니다. 아이디어는 1970년대 초로 거슬러 올라갑니다.

삼항식의 경우에도 마찬가지입니다. 바둑의 역사 읽기 -- 바둑 창시자 중 한 명인 Ken Thompson은 1969년 Bell Labs에서 B 언어(C의 전신)로 삼항 연산자를 구현했습니다. Go에 포함할지 여부.

바둑은 비판의 여지가 있지만 바둑 포럼에서의 토론은 정중해야 합니다. 솔직하다는 것은 무례한 것과는 다릅니다. https://golang.org/conduct 의 "고퍼 가치" 섹션을

@lpar 예, Rust에 그런 포럼이 있다면 그렇게 할 것입니다 ;-) 진심으로 그렇게 할 것입니다. 내 목소리를 듣고 싶으니까.

@ianlancetaylor 저속한 단어나 언어를 사용했나요? 차별적인 언어를 사용하거나 누군가를 괴롭히거나 원치 않는 성적 접근을 했습니까? 나는 그렇게 생각하지 않는다.
이봐, 우리는 여기에서 Go 프로그래밍 언어에 대해 이야기하고 있습니다. 종교나 정치나 그런 얘기가 아닙니다.
나는 솔직했다. 내 목소리가 들리길 바랐다. 그래서 이 포럼이 있는 것 같아요. 목소리가 들리도록. 내 제안이나 비판이 마음에 들지 않을 수도 있습니다. 괜찮아. 하지만 제가 이야기하고 토론할 수 있도록 해야 한다고 생각합니다. 그렇지 않으면 우리 모두가 모든 것이 완벽하고 문제가 없으므로 추가 토론이 필요하지 않다고 결론을 내릴 수 있습니다.

@josharian 기사 주셔서 감사합니다. 한 번 살펴보겠습니다.

글쎄, 나는 거기에 나쁜 것이 있는지 확인하기 위해 내 의견을 뒤돌아 보았다. 내가 모욕했을 수 있는 유일한 것은(나는 여전히 그 비판을 btw라고 부른다) GoLang 프로그래밍 언어 숙어입니다! 하하하!

우리의 주제로 돌아가려면 내 목소리가 들리면 Go Authors에게 Try catch 블록을 다시 가져오는 것을 고려하십시오. 올바른 위치에서 사용할지 여부를 결정하는 것은 프로그래머에게 맡기십시오(이미 비슷한 것이 있습니다. 패닉 상태에서 복구를 연기한 다음 프로그래머에게 더 친숙한 Try Catch를 사용하지 않는 이유는 무엇입니까?).
이전 버전과의 호환성을 위해 현재 Go Error 처리에 대한 해결 방법을 제안했습니다. 나는 그것이 최선의 선택이라고 말하지는 않지만 그것이 실행 가능하다고 생각합니다.

이 주제에 대해 더 이상 논의하지 않도록 하겠습니다.

기회를 주셔서 감사합니다.

@KamyarM 당신은 당신의 주장에 대한 우리의 의견 불일치로

다시 한 번: 예의를 갖추십시오. 기술적 주장에 충실하십시오. 아이디어보다 사람들을 공격하는 광고적인 논쟁을 피하십시오. 진심으로 내 말을 이해하지 못한다면 오프라인에서 논의할 의향이 있습니다. 저에게 이메일을 보내주세요. 감사 해요.

나는 내 2c를 던질 것이고, 그것이 다른 N백 개의 댓글(또는 urandom의 제안에 대한 논의를 밟는 것)에서 말 그대로 무언가를 반복하지 않기를 바랍니다.

게시된 원래 아이디어가 마음에 들지만 두 가지 기본 조정이 있습니다.

• 구문 바이크쉐딩: 묵시적 제어 흐름이 있는 모든 것은 기존 운영자의 과부하가 아니라 그 자체로 운영자여야 한다고 강력히 믿습니다. 나는 ?! 를 거기에 던질 것이지만, Go의 기존 연산자와 쉽게 혼동되지 않는 것은 무엇이든 만족합니다.

• 이 연산자의 RHS는 임의로 주입된 값이 있는 표현식이 아닌 함수를 취해야 합니다. 이렇게 하면 개발자가 의도에 대해 명확하고 무엇을 할 수 있는지 유연하면서도 매우 간결한 오류 처리 코드를 작성할 수 있습니다.

func returnErrorf(s string, args ...interface{}) func(error) error {
  return func(err error) error {
    return errors.New(fmt.Sprintf(s, args...) + ": " + err.Error())
  }
}

func foo(r io.ReadCloser, callAfterClosing func() error, bs []byte) ([]byte, error) {
  // If r.Read fails, returns `nil, errors.New("reading from r: " + err.Error())`
  n := r.Read(bs) ?! returnErrorf("reading from r")
  bs = bs[:n]
  // If r.Close() fails, returns `nil, errors.New("closing r after reading [[bs's contents]]: " + err.Error())`
  r.Close() ?! returnErrorf("closing r after reading %q", string(bs))
  // Not that I advocate this inline-func approach, but...
  callAfterClosing() ?! func(err error) error { return errors.New("oh no!") }
  return bs, nil
}

오류가 발생하지 않으면 RHS를 평가해서는 안 되므로 이 코드는 클로저 또는 해피 경로에 있는 모든 것을 할당하지 않습니다.

더 흥미로운 경우에 작동하도록 이 패턴을 "오버로드"하는 것도 매우 간단합니다. 세 가지 예를 염두에 두고 있습니다.

첫째, RHS가 func(error) (error, bool) 인 경우 return 를 조건부로 할 수 있습니다(이를 허용한다면 무조건 반환과 별개의 연산자를 사용해야 한다고 생각합니다. ?? 를 사용하지만 "별도의 차이가 있는 한 상관하지 않습니다" 문구가 여전히 적용됩니다.

func maybeReturnError(err error) (error, bool) {
  if err == io.EOF {
    return nil, false
  }
  return err, true
}

func id(err error) error { return err }

func ignoreError(err error) (error, bool) { return nil, false }

func foo(n int) error {
  // Does nothing
  id(io.EOF) ?? ignoreError
  // Still does nothing
  id(io.EOF) ?? maybeReturnError
  // Returns the given error
  id(errors.New("oh no")) ?? maybeReturnError
  return nil
}

또는 다음과 같이 외부 함수의 반환 유형과 일치하는 반환 유형을 가진 RHS 함수를 수락할 수 있습니다.

func foo(r io.Reader) ([]int, error) {
  returnError := func(err error) ([]int, error) { return []int{0}, err }
  // returns `[]int{0}, err` on a Read failure
  n := r.Read(make([]byte, 4)) ?! returnError
  return []int{n}, nil
}

마지막으로, 우리가 정말로 원한다면, 인수 유형을 변경하여 단순한 오류 이상으로 작동하도록 이것을 일반화할 수 있습니다.

func returnOpFailed(name string) func(bool) error {
  return func(_ bool) error {
    return errors.New(name + " failed")
  }
}

func returnErrOpFailed(name string) func(error) error {
  return func(err error) error {
    return errors.New(name + " failed: " + err.Error())
  }
}

func foo(c chan int, readInt func() (int, error), d map[int]string) (string, error) {
  n := <-c ?! returnOpFailed("receiving from channel")
  m := readInt() ?! returnErrOpFailed("reading an int")
  result := d[n + m] ?! returnOpFailed("looking up the number")
  return result, nil
}

... map[string]interface{} 손으로 디코딩하는 것과 같은 끔찍한 일을 해야 할 때 개인적으로 정말 유용하다고 생각합니다.

분명히 하기 위해 저는 주로 확장 기능을 예시로 보여주고 있습니다. 나는 그들 중 (있는 경우) 어느 것이 단순성, 명확성 및 일반적인 유용성 사이에서 좋은 균형을 이루는지 잘 모르겠습니다.

오류를 무시하는 것이 이미 존재하는 _에 의해 이미 덮여 있다고 가정하기 때문에 "오류 반환/추가 컨텍스트 포함" 부분을 다시 방문하고 싶습니다.

(선택적으로) 문자열이 뒤따를 수 있는 2단어 키워드를 제안합니다.

@urandom 귀하의 제안서의 첫 번째 부분은 동의할 수 있습니다. 하나는 항상 그것으로 시작하고 두 번째 수정을 위해 BubbleProcessor 를 남겨둘 수 있습니다. @object88 이 제기한 문제는 유효한 IMO입니다. 나는 최근에 " http 의 기본 클라이언트/전송을 덮어쓰지 말아야 합니다"와 같은 조언을 본 적이 있습니다. 이것은 또 다른 것이 될 것입니다.

이 스레드에는 많은 제안이 있었습니다. 스스로에게 말해서, 나는 여전히 내가 해결해야 할 문제에 대해 강한 이해를 갖고 있지 않다고 생각합니다. 나는 그들에 대해 더 듣고 싶습니다.

나는 또한 누군가가 논의된 문제의 체계적이고 요약된 목록을 유지 관리하는 부끄럽지만 중요한 작업을 수행하고 싶어한다면 기쁠 것입니다.

@ianlancetaylor 당신을 임명하는 경우 그것은 당신을 @josharian 될 수 있을까? : 홍당무: 다른 문제가 어떻게 계획/토론되고 있는지 모르겠지만 아마도 이 토론이 "제안 상자"로 사용되는 것 같습니까?

@KamyarM

@bcmills 거기에서 제안한 코드를 셀 수 있습니다. 한 줄 대신 6줄의 코드가 필요하다고 생각합니다. 아마 그에 대한 몇 가지 코드 순환적 복잡성 포인트를 얻을 수 있을 것입니다(여러분은 Linter를 사용합니다. 맞죠?).

순환적 복잡성을 숨기면 보기가 더 어려워지지만 제거되지는 않습니다( strlen 기억?). 오류 처리를 "단축"하게 하면 오류 처리 의미를 무시하기가 더 쉬워지지만 보기는 더 어렵습니다.

흐름 제어를 재라우팅하는 소스의 모든 명령문이나 표현식은 명확하고 간결해야 합니다. 그러나 이것이 명백한 것과 간결한 것 사이의 결정이라면 이 경우 명백한 것이 선호되어야 합니다.

이 GO 관용구를 가져오길 잘했습니다. 이것이 바로 이 언어의 문제 중 하나라고 생각합니다. 변경 요청이 있을 때마다 누군가는 Go 관용구에 위배되는 oh no라고 말합니다. 나는 그것을 변화에 저항하고 새로운 아이디어를 차단하기 위한 변명일 뿐이라고 생각합니다.

새로운 것과 유익한 것은 다릅니다. 당신은 아이디어가 있기 때문에 그 존재 자체가 승인받을 가치가 있다고 믿습니까? 연습으로 이슈 트래커를 보고 커뮤니티의 생각과 상관없이 모든 아이디어가 승인된다면 오늘 바둑을 상상해 보세요.

아마도 당신은 당신의 아이디어가 다른 사람들보다 낫다고 생각할 것입니다. 여기에서 토론이 시작됩니다. 관용구 때문에 전체 시스템이 어떻게 망가졌는지에 대해 이야기하는 것으로 대화를 퇴화시키는 대신, 비판을 직접 요점별로 다루거나 귀하와 동료 사이의 중간 지점을 찾으십시오.

@gdm85
반환된 오류 부분에 일종의 사용자 지정을 위해 프로세서를 추가했습니다. 그리고 저는 그것이 기본 로거를 사용하는 것과 약간 비슷하다고 생각하지만, 대부분의 시간 동안 그것을 사용하지 않고 벗어날 수 있다는 점에서 저는 제안에 열려 있다고 말했습니다. 그리고 기록을 위해 기본 로거와 기본 http 클라이언트가 같은 범주에 원격으로 있다고 생각하지 않습니다.

나는 또한 @gburgessiv 의 제안을 좋아합니다. 비록 제가 비밀 연산자 자체에 대한 열렬한 팬은 아니지만(최소한 Rust에서와 같이 ? 고를 수도 있지만, 여전히 그것이 비밀이라고 생각하지만). 더 읽기 쉽게 보이나요?

func foo(r io.ReadCloser, callAfterClosing func() error, bs []byte) ([]byte, error) {
  // If r.Read fails, returns `nil, errors.New("reading from r: " + err.Error())`
  n := r.Read(bs) or returnErrorf("reading from r")
  bs = bs[:n]
  // If r.Close() fails, returns `nil, errors.New("closing r after reading [[bs's contents]]: " + err.Error())`
  r.Close() or returnErrorf("closing r after reading %q", string(bs))
  // Not that I advocate this inline-func approach, but...
  callAfterClosing() or func(err error) error { return errors.New("oh no!") }
  return bs, nil
}

그리고 그의 제안에 errors 패키지의 어딘가에 그의 returnErrorf와 유사한 기능의 기본 구현도 포함되기를 바랍니다. 아마도 errors.Returnf() .

@KamyarM
당신은 이미 여기에 당신의 의견을 표명했고 예외 원인에 대해 어떤 코멘트나 반응도 얻지 못했습니다. 같은 일을 반복하는 것이 다른 토론을 방해하는 것 외에 무엇을 성취할지 모르겠습니다. 그리고 그것이 당신의 목표라면, 그것은 멋지지 않습니다.

@josharian , 토론을 간략하게 요약하려고 합니다. 전체 스레드를 다시 읽을 수 없기 때문에 믹스에 제안이 있고 불완전하기 때문에 편향될 것입니다.

우리가 해결하려는 문제는 Go 오류 처리로 인한 시각적 혼란입니다. 다음은 좋은 예입니다( 출처 ).

func (ds *GitDataSource) Fetch(from, to string) ([]string, error) {
    if err := createFolderIfNotExist(to); err != nil {
        return nil, err
    }
    if err := clearFolder(to); err != nil {
        return nil, err
    }
    if err := cloneRepo(to, from); err != nil {
        return nil, err
    }
    dirs, err := getContentFolders(to)
    if err != nil {
        return nil, err
    }
    return dirs, nil
}

이 스레드의 여러 댓글 작성자는 이 문제를 수정할 필요가 없다고 생각합니다. 그들은 오류를 처리하는 것이 오류가 아닌 경우를 처리하는 것만큼 중요하기 때문에 오류 처리가 방해가 되는 것에 만족합니다. 그들에게는 여기에 있는 어떤 제안도 가치가 없습니다.

이와 같은 코드를 단순화하려는 제안은 몇 개의 그룹으로 나뉩니다.

일부는 예외 처리 형식을 제안합니다. Go가 처음에 예외 처리를 선택하고 선택하지 않았을 수 있다는 점을 감안할 때 이것이 받아들여질 것 같지 않습니다.

여기에 있는 많은 제안은 함수에서 반환(원래 제안) 또는 패닉과 같은 기본 작업을 선택하고 해당 작업을 쉽게 표현할 수 있도록 약간의 구문을 제안합니다. 제 생각에는 그 제안들은 모두 실패했습니다. 왜냐하면 그것들은 다른 사람들을 희생시키면서 한 가지 행동에 특권을 주기 때문입니다. 나는 정기적으로 t.Fatal 및 log.Fatal 를 사용하여 오류를 처리하며 때로는 모두 같은 날에 처리합니다.

다른 제안은 원래 오류를 늘리거나 감쌀 방법을 제공하지 않으며 그렇지 않은 것보다 훨씬 더 어렵게 만듭니다. 래핑은 오류에 컨텍스트를 추가하는 유일한 방법이고 건너뛰기 너무 쉽게 만들면 지금보다 훨씬 덜 자주 수행되기 때문에 이것들도 부적절합니다.

나머지 제안의 대부분은 가능한 작업이나 래핑 기능을 제한하지 않고 일을 단순화하기 위해 약간의 설탕과 때로는 약간의 마법을 추가합니다. My 와 @bcmills 의 제안은 가독성을 약간 높이고 불쾌한 종류의 버그 를 방지하기 위해 최소한의 설탕과 제로 마법을 추가합니다.

몇 가지 다른 제안은 함수의 시작이나 끝에 오류 처리 섹션과 같은 일종의 제한된 비-로컬 제어 흐름을 추가합니다.

마지막으로 @mpvl 은 패닉 상태에서 오류 처리가 매우 까다로울 수 제안 합니다. 그는 설득력 있는 주장을 하고 있지만 결국 그의 경우는 급격한 변화가 필요하지 않고 기존 메커니즘 으로 처리될 수 있다고 생각합니다.

여기에 아이디어가 표시되지 않은 사람에게 사과드립니다.

누군가 내게 설탕과 마법의 차이에 대해 물어볼 것 같은 느낌이 든다. (직접 물어봅니다.)

Sugar는 언어의 규칙을 근본적으로 변경하지 않고 코드를 단축하는 약간의 구문입니다. 짧은 할당 연산자 := 는 설탕입니다. C의 삼항 연산자 ?: 마찬가지입니다.

Magic은 변수를 선언하지 않고 범위에 도입하거나 non-local control transfer를 수행하는 것과 같이 언어에 대한 보다 폭력적인 중단입니다.

확실히 선이 흐릿하네요.

해주셔서 감사합니다, @jba. 매우 도움이 됩니다. 하이라이트를 뽑아내기 위해 지금까지 확인된 문제는 다음과 같습니다.

Go 오류 처리로 인한 시각적 혼란

그리고

오류 처리는 패닉이 있을 때 매우 까다로울 수 있습니다.

@jba 와 내가 놓친 근본적으로 다른 문제(해결책 아님)가 불러 주세요. FWIW, 나는 인체 공학, 코드 클러터, 순환적 복잡성, 스터터, 상용구 등을 "시각적 클러터" 문제(또는 문제 클러스터)의 변형으로 간주합니다.

@josharian 범위 지정 문제(https://github.com/golang/go/issues/21161#issuecomment-319277657)를 "시각적 혼란" 문제의 변형으로 간주하시겠습니까, 아니면 별도의 문제로 간주하시겠습니까?

@bcmills 는 미학/인체 공학(또는 기껏해야 코드 벌크와 관련된 정확성 문제)과 대조되는 미묘한 정확성 문제에 관한 것이기 때문에 저에게

누군가 내게 설탕과 마법의 차이에 대해 물어볼 것 같은 느낌이 든다. (직접 물어봅니다.)

저는 이 마법의 정의를 사용합니다. 약간의 소스 코드를 살펴보면 다음 알고리즘의 일부 변형에 의해 수행되어야 하는 작업을 파악할 수 있습니다.

1. 줄이나 함수에 있는 모든 식별자, 키워드 및 문법 구성을 찾습니다.
2. 문법 구성 및 키워드에 대해서는 공식 언어 문서를 참조하십시오.
3. 식별자의 경우, 보고 있는 코드의 정보를 사용하고 언어에 정의된 대로 코드가 현재 위치한 범위를 사용하여 식별자의 정의를 얻을 수 있는 명확한 메커니즘이 있어야 합니다. 런타임에 정확해야 합니다.

이 알고리즘이 _신뢰성 있게_ 코드가 수행할 작업에 대한 올바른 이해를 생성한다면 그것은 마법이 아닙니다. 그렇지 않다면 그 안에 어느 정도의 마법이 있는 것입니다. 문서 참조 및 식별자 정의를 따라 다른 식별자 정의를 따르려고 할 때 이를 얼마나 재귀적으로 적용해야 하는지는 문제의 구성/코드의 _복잡도_가 아닌 _복잡도_에 영향을 미칩니다.

마법의 예는 다음과 같습니다. 네임스페이스 없이 가져오기 때문에 원본으로 돌아가는 명확한 경로가 없는 식별자(특히 둘 이상이 있는 경우 Go에서 점 가져오기). 코드가 함수 참조를 비-로컬로 완전히 재정의하거나 언어가 존재하지 않는 식별자에 대해 수행하는 작업을 재정의할 수 있는 동적 언어와 같이 언어가 일부 연산자가 해결될 대상을 비-로컬로 정의해야 할 수 있는 모든 기능. 런타임 시 데이터베이스에서 로드된 스키마에 의해 생성된 객체, 그래서 코드 타임에는 그것이 있기를 어느 정도 맹목적으로 바라고 있습니다.

이것에 대한 좋은 점은 질문에서 거의 모든 주관성을 제거한다는 것입니다.

당면한 주제로 돌아가서 이미 수많은 제안이 만들어진 것 같고 다른 사람이 다른 제안으로 이 문제를 해결하여 모든 사람이 "예! 바로 그것입니다!" 제로에 접근합니다.

여기에서 제안된 제안의 다양한 차원을 분류하고 우선 순위를 파악하는 방향으로 대화가 진행되어야 할 것 같습니다. 특히 여기 사람들이 모호하게 적용하는 모순된 요구 사항을 드러내는 눈으로 이것을 보고 싶습니다.

예를 들어, 제어 흐름에 추가되는 추가 점프에 대한 불만을 본 적이 있습니다. 그러나 나 자신을 위해, 매우 독창적인 제안의 말투로, 나는 그것들이 공통적이라면 함수 내에 || &PathError{"chdir", dir, err} 8번 추가하지 않아도 되는 것을 가치 있게 생각합니다. (나는 Go가 다른 언어만큼 반복되는 코드에 알레르기가 없다는 것을 알고 있지만, 여전히 반복되는 코드는 발산 버그의 위험이 매우 높습니다.) 그러나 정의상, 그러한 오류 처리를 제거하는 메커니즘이 있다면, 코드는 점프 없이 위에서 아래로, 왼쪽에서 오른쪽으로 흐를 수 없습니다. 일반적으로 어느 것이 더 중요합니까? 사람들이 코드에 암묵적으로 배치하는 요구 사항을 주의 깊게 조사하면 다른 상호 모순적인 요구 사항이 드러날 것이라고 생각합니다.

그러나 일반적으로 이 모든 분석 후에 커뮤니티가 요구 사항에 동의할 수 있다면 올바른 솔루션이 명확하게 나오지 않거나 최소한 올바른 솔루션 세트가 너무 명확하게 제한되어 문제는 다루기 쉬워집니다.

(나는 또한 이것이 제안이므로 현재 행동은 일반적으로 새로운 제안과 동일한 분석을 받아야 한다는 점을 지적하고 싶습니다. 목표는 완벽이 아니라 상당한 개선입니다. 둘 중 하나가 하나도 없기 때문에 두세 가지 중요한 개선을 거부합니다. 모든 제안은 마비로 가는 길입니다.어쨌든 모든 제안은 이전 버전과 호환되므로 현재 접근 방식이 어쨌든 이미 최고인 경우(임호, 모든 오류가 합법적으로 다르게 처리되는 경우, 내 경험상 드물지만 발생함) , 현재 접근 방식을 계속 사용할 수 있습니다.)

나는 두 번째로 함수에서 if err !=nil을 썼을 때부터 이것에 대해 생각해 왔습니다. 상당히 간단한 해결책은 다음과 같은 이해와 함께 삼항의 첫 번째 부분처럼 보이는 조건부 반환을 허용하는 것입니다. 조건이 실패하면 반환하지 않습니다.

이것이 구문 분석/컴파일 측면에서 얼마나 잘 작동하는지 잘 모르겠지만 '?' 보이지 않는 곳에서 호환성을 깨지 않고 볼 수 있으므로 옵션으로 버릴 생각입니다.

또한 오류 처리 이외의 다른 용도가 있습니다.

따라서 다음과 같이 할 수 있습니다.

func example1() error {
    err := doSomething()
    return err != nil ? err
    //more code
}

func example2() (*Mything, error) {
    err := doSomething()
    return err != nil ? nil, err
    //more code
}

handleErr이 오류를 반환했다고 가정하고 정리 코드가 있을 때 이와 같은 작업을 수행할 수도 있습니다.

func example3() error {
    err := doSomething()
    return err !=nil ? handleErr(err)
    //more code
}

func example4() (*Mything, error) {
    err := doSomething()
    return err != nil ? nil, handleErr(err)
    //more code
}

아마도 당신이 원한다면 이것을 하나의 라이너로 줄일 수 있을 것입니다:

func example5() error {
    return err := doSomething(); err !=nil ? handleErr(err)
    //more code
}

func example6() (*Mything, error) {
    return err := doSomething(); err !=nil ? nil, handleErr(err)
    //more code
}

@jba의 이전 가져오기 예제는 다음과

func (ds *GitDataSource) Fetch(from, to string) ([]string, error) {

    return err := createFolderIfNotExist(to); err != nil ? nil, err
    return err := clearFolder(to); err != nil ? nil, err
    return err := cloneRepo(to, from); err != nil ? nil, err
    dirs, err := getContentFolders(to)

    return dirs, err
}

이 제안에 대한 반응에 관심이 있을 것입니다. 아마도 상용구를 절약하는 데 있어 큰 승리는 아니지만 상당히 명시적으로 유지하고 작은 이전 버전과 호환되는 변경(아마도 그 전면에 대한 몇 가지 매우 부정확한 가정)만 필요로 하기를 바랍니다.

별도의 반품으로 이것을 분리할 수 있습니까? 반환과의 호환성에 대해 걱정할 필요가 없다는 점에서 명확성을 더하고 삶을 더 단순하게 만들 수 있는 키워드(모든 도구를 생각함)는 다음과 같이 내부적으로 if/return 문으로 다시 작성할 수 있습니다.

func (ds *GitDataSource) Fetch(from, to string) ([]string, error) {

    return? err := createFolderIfNotExist(to); err != nil ? nil, err
    return? err := clearFolder(to); err != nil ? nil, err
    return? err := cloneRepo(to, from); err != nil ? nil, err
    dirs, err := getContentFolders(to)

    return dirs, err
}

별로 차이가 없어보입니다

return err != nil ? err

그리고

 if err != nil { return err }

또한 panic 또는 log.Fatal 호출과 같이 반환 이외의 다른 작업을 수행하려는 경우도 있습니다.

지난주에 제안서를 제출한 이후로 이것에 대해 고민해 왔으며 @jerf에 동의한다는 결론에 도달했습니다. 각각에 대해, 각각에 대해 싫어하는 것, "적절한" 솔루션을 위한 우선순위가 무엇인지.

가장 일반적으로 언급되는 요구 사항은 하루가 끝날 때 Go가 4가지 경우의 오류 처리를 처리할 수 있어야 한다는 것입니다.

1. 오류 무시
2. 수정되지 않은 오류 반환
3. 컨텍스트가 추가된 오류 반환
4. 패닉(또는 프로그램 종료)

제안은 다음 세 가지 범주 중 하나에 속하는 것 같습니다.

1. try-catch-finally 스타일의 오류 처리로 되돌립니다.
2. 위에 나열된 4가지 경우를 모두 처리하기 위해 새 구문/내장 추가
3. go를 주장하는 것은 일부 경우를 충분히 잘 처리하고 다른 경우를 돕기 위해 구문/내장을 제안합니다.

주어진 제안에 대한 비판은 코드 가독성, 명확하지 않은 점프, 범위에 변수의 암시적 추가, 간결성에 대한 우려로 나뉘는 것 같습니다. 개인적으로는 제안에 대한 비판에 개인적인 의견이 많이 나왔다고 생각합니다. 그것이 나쁘다는 말은 아니지만, 제안서를 평가할 객관적인 기준은 없는 것 같습니다.

내가 그 기준 목록을 만들려고 하는 사람은 아닐지 모르지만 누군가가 그것을 정리한다면 매우 도움이 될 것이라고 생각합니다. 나는 지금까지 논쟁에 대한 나의 이해를 1. 우리가 본 것, 2. 무엇이 잘못되었는지, 3. 그것들이 잘못된 이유 , 4. 우리가 무엇을 대신 보고 싶어. 나는 처음 3개 항목의 상당한 양을 캡처했다고 생각하지만 "현재 Go가 가지고 있는 것"에 의지하지 않고 항목 4에 대한 답을 찾는 데 어려움을 겪고 있습니다.

@jba 에는 더 많은 컨텍스트를 위해 위의 또 다른 멋진 요약 주석이 있습니다. 그는 내가 여기서 말한 많은 것을 다른 말로 말합니다.

@ianlancetaylor 또는 나보다 프로젝트에 더 밀접하게 관련된 다른 사람이

나는 포괄적이고 공식적인 기준 세트를 작성할 수 없다고 생각합니다. 내가 할 수 있는 최선은 그렇게 함으로써 상당한 이점이 있는 경우에만 무시되어야 하는 중요한 일의 불완전한 목록입니다.

• 1) 오류 무시; 2) 수정되지 않은 오류를 반환합니다. 3) 추가 컨텍스트로 오류를 래핑합니다.
• 오류 처리 코드는 명확해야 하지만 기능을 지배해서는 안 됩니다. 비 오류 처리 코드를 읽기 쉬워야 합니다.
• 기존 Go 1 코드는 계속 작동하거나 최소한 Go 1을 완전히 신뢰할 수 있는 새로운 접근 방식으로 기계적으로 변환할 수 있어야 합니다.
• 새로운 접근 방식은 프로그래머가 오류를 올바르게 처리하도록 권장해야 합니다. 어떤 상황에서 옳은 일이든 옳은 일을 하는 것은 이상적으로 쉬워야 합니다.
• 새로운 접근 방식은 현재 접근 방식보다 짧고 반복적이지 않으면서도 명확해야 합니다.
• 언어는 오늘날에도 작동하며 모든 변경에는 비용이 따릅니다. 변경의 이점은 분명히 비용의 가치가 있어야 합니다. 그것은 단지 세척이 아니라 분명히 더 좋아야 합니다.

나는 여기에서 어떤 시점에서 메모를 수집하기를 희망하지만 이 토론에서 IMHO가 또 다른 주요 걸림돌인 예의 사소함을 다루고 싶습니다.

내 실제 프로젝트에서 이것을 추출하고 외부 릴리스를 위해 스크럽했습니다. (나는 stdlib가 무엇보다도 로깅 문제가 없기 때문에 최고의 소스가 아니라고 생각합니다.)

func NewClient(...) (*Client, error) {
    listener, err := net.Listen("tcp4", listenAddr)
    if err != nil {
        return nil, err
    }
    defer func() {
        if err != nil {
            listener.Close()
        }
    }()

    conn, err := ConnectionManager{}.connect(server, tlsConfig)
    if err != nil {
        return nil, err
    }
    defer func() {
        if err != nil {
            conn.Close()
        }
    }()

    if forwardPort == 0 {
        env, err := environment.GetRuntimeEnvironment()
        if err != nil {
            log.Printf("not forwarding because: %v", err)
        } else {
            forwardPort, err = env.PortToForward()
            if err != nil {
                log.Printf("env couldn't provide forward port: %v", err)
            }
        }
    }
    var forwardOut *forwarding.ForwardOut
    if forwardPort != 0 {
        u, _ := url.Parse(fmt.Sprintf("http://127.0.0.1:%d", forwardPort))
        forwardOut = forwarding.NewOut(u)
    }

    client := &Client{...}

    toServer := communicationProtocol.Wrap(conn)
    err = toServer.Send(&client.serverConfig)
    if err != nil {
        return nil, err
    }

    err = toServer.Send(&stprotocol.ClientProtocolAck{ClientVersion: Version})
    if err != nil {
        return nil, err
    }

    session, err := communicationProtocol.FinalProtocol(conn)
    if err != nil {
        return nil, err
    }
    client.session = session

    return client, nil
}

(코드를 너무 많이 사용하지 말자. 물론 막을 수는 없지만 이것은 내 실제 코드가 아니며 약간 수정되었음을 기억하십시오. 그리고 귀하의 샘플 코드를 게시하는 것을 막을 수는 없습니다.)

관찰:

1. 이것은 완벽한 코드가 아닙니다. 나는 너무 쉽고 정확히 우리가 문제가 있는 코드 종류이기 때문에 베어 오류를 많이 반환합니다. 제안서는 간결성과 이 코드 수정을 얼마나 쉽게 시연하는지에 따라 점수를 매겨야 합니다.
2. if forwardPort == 0 절은 _의도적으로_ 오류를 통해 계속되며, 예, 이것은 실제 동작이며 이 예제에서 추가한 것이 아닙니다.
3. 이 코드는 유효한 연결된 클라이언트를 반환하거나 오류를 반환하고 리소스 누수가 없으므로 .Close() 주변 처리(함수 오류가 발생한 경우에만)는 의도적입니다. 또한 닫기의 오류는 실제 바둑에서 매우 일반적으로 사라지는 것에 유의하십시오.
4. 포트 번호는 다른 곳에서 제한되므로 url.Parse는 (검사에 의해) 실패할 수 없습니다.

이것이 가능한 모든 오류 동작을 보여준다고 주장하지는 않겠지만 꽤 많은 영역을 다룹니다. (나는 내 ​​코드가 요리될 때쯤이면 내 네트워크 서버에서 내가 _모든 종류의_ 오류 동작을 하는 경우가 종종 있음을 지적함으로써 HN 등에서 Go를 변호합니다. 오류의 1/2이 단순히 반환되는 것 이외의 다른 작업을 수행했습니다.)

나는 또한 이 코드에 적용된 내 자신의 (업데이트된) 제안을 (다시) 게시할 것입니다(누군가 그 전에 더 나은 것을 가지고 있다고 확신하지 않는 한), 그러나 대화를 독점하지 않기 위해 나는 기다릴 것입니다 적어도 주말에는. (이것은 소스의 거대한 덩어리이기 때문에 보이는 것보다 적은 텍스트이지만 여전히 ....)

try 경우 try 는 if != nil return의 지름길일 뿐입니다. 코드는 59개 중 6개 줄(약 10%) 줄입니다.

func NewClient(...) (*Client, error) {
    listener, err := net.Listen("tcp4", listenAddr)
    try err

    defer func() {
        if err != nil {
            listener.Close()
        }
    }()

    conn, err := ConnectionManager{}.connect(server, tlsConfig)
    try err

    defer func() {
        if err != nil {
            conn.Close()
        }
    }()

    if forwardPort == 0 {
        env, err := environment.GetRuntimeEnvironment()
        if err != nil {
            log.Printf("not forwarding because: %v", err)
        } else {
            forwardPort, err = env.PortToForward()
            if err != nil {
                log.Printf("env couldn't provide forward port: %v", err)
            }
        }
    }
    var forwardOut *forwarding.ForwardOut
    if forwardPort != 0 {
        u, _ := url.Parse(fmt.Sprintf("http://127.0.0.1:%d", forwardPort))
        forwardOut = forwarding.NewOut(u)
    }

    client := &Client{...}

    toServer := communicationProtocol.Wrap(conn)
    err = toServer.Send(&client.serverConfig)
    try err

    err = toServer.Send(&stprotocol.ClientProtocolAck{ClientVersion: Version})
    try err

    session, err := communicationProtocol.FinalProtocol(conn)
    try err

    client.session = session

    return client, nil
}

특히, 여러 곳에서 try x() 를 쓰고 싶었지만 연기가 제대로 작동하려면 err을 설정해야 했기 때문에 그렇게 할 수 없었습니다.

하나 더. try 가 할당 줄에서 발생할 수 있는 경우 47줄로 줄어듭니다.

func NewClient(...) (*Client, error) {
    try listener, err := net.Listen("tcp4", listenAddr)

    defer func() {
        if err != nil {
            listener.Close()
        }
    }()

    try conn, err := ConnectionManager{}.connect(server, tlsConfig)

    defer func() {
        if err != nil {
            conn.Close()
        }
    }()

    if forwardPort == 0 {
        env, err := environment.GetRuntimeEnvironment()
        if err != nil {
            log.Printf("not forwarding because: %v", err)
        } else {
            forwardPort, err = env.PortToForward()
            if err != nil {
                log.Printf("env couldn't provide forward port: %v", err)
            }
        }
    }
    var forwardOut *forwarding.ForwardOut
    if forwardPort != 0 {
        u, _ := url.Parse(fmt.Sprintf("http://127.0.0.1:%d", forwardPort))
        forwardOut = forwarding.NewOut(u)
    }

    client := &Client{...}

    toServer := communicationProtocol.Wrap(conn)
    try err = toServer.Send(&client.serverConfig)

    try err = toServer.Send(&stprotocol.ClientProtocolAck{ClientVersion: Version})

    try session, err := communicationProtocol.FinalProtocol(conn)

    client.session = session

    return client, nil
}

import "github.com/pkg/errors"

func Func3() (T1, T2, error) {...}

type PathError {
    err Error
    x   T3
    y   T4
}

type MiscError {
    x   T5
    y   T6
    err Error
}


func Foo() (T1, T2, error) {
    // Old school
    a, b, err := Func(3)
    if err != nil {
        return nil
    }

    // Simplest form.
    // If last unhandled arg's type is same 
    // as last param of func,
    // then use anon variable,
    // check and return
    a, b := Func3()
    /*    
    a, b, err := Func3()
    if err != nil {
         return T1{}, T2{}, err
    }
    */

    // Simple wrapper
    // If wrappers 1st param TypeOf Error - then pass last and only unhandled arg from Func3() there
    a, b, errors.WithStack() := Func3() 
    /*
    a, b, err := Func3()
    if err != nil {
        return T1{}, T2{}, errors.WithStack(err)
    }
    */

    // Bit more complex wrapper
    a, b, errors.WithMessage("unable to get a and b") := Func3()
    /*
    a, b, err := Func3()
    if err != nil {
        return T1{}, T2{}, errors.WithMessage(err, "unable to get a and b")
    }
    */

    // More complex wrapper
    // If wrappers 1nd param TypeOf is not Error - then pass last and only unhandled arg from Func3() as last
    a, b, fmt.Errorf("at %v Func3() return error %v", time.Now()) := Func3()
    /*
    a, b, err := Func3()
    if err != nil {
        return T1{}, T2{}, fmt.Errorf("at %v Func3() return error %v", time.Now(), err)
    }
    */

    // Wrapping with error types
    a, b, &PathError{x,y} := Func3()
    /*
    a, b, err := Func3()
    if err != nil {
        return T1{}, T2{}, &PathError{err, x, y}
    }
    */
    a, b, &MiscError{x,y} := Func3()
    /*
    a, b, err := Func3()
    if err != nil {
        return T1{}, T2{}, &MiscError{x, y, err}
    }
    */

    return a, b, nil
}

약간의 마법(-1까지 자유롭게)이지만 기계적 번역을 지원합니다.

이것은 (다소 업데이트된) 내 제안이 다음과 같을 것입니다.

func NewClient(...) (*Client, error) {
    defer annotateError("client couldn't be created")

    listener := pop net.Listen("tcp4", listenAddr)
    defer closeOnErr(listener)
    conn := pop ConnectionManager{}.connect(server, tlsConfig)
    defer closeOnErr(conn)

    if forwardPort == 0 {
        env, err := environment.GetRuntimeEnvironment()
        if err != nil {
            log.Printf("not forwarding because: %v", err)
        } else {
            forwardPort, err = env.PortToForward()
            if err != nil {
                log.Printf("env couldn't provide forward port: %v", err)
            }
        }
    }
    var forwardOut *forwarding.ForwardOut
    if forwardPort != 0 {
         forwardOut = forwarding.NewOut(pop url.Parse(fmt.Sprintf("http://127.0.0.1:%d", forwardPort)))
    }

    client := &Client{listener: listener, conn: conn, forward: forwardOut}

    toServer := communicationProtocol.Wrap(conn)
    pop toServer.Send(&client.serverConfig)
    pop toServer.Send(&stprotocol.ClientProtocolAck{ClientVersion: Version})
    session := pop communicationProtocol.FinalProtocol(conn)
    client.session = session

    return client, nil
}

func closeOnErr(c io.Closer) {
    if err := erroring(); err != nil {
        closeErr := c.Close()
        if err != nil {
            seterr(multierror.Append(err, closeErr))
        }
    }
}

func annotateError(annotation string) {
    if err := erroring(); err != nil {
        log.Printf("%s: %v", annotation, err)
        seterr(errwrap.Wrapf(annotation +": {{err}}", err))
    }
}

정의:

pop 는 맨 오른쪽 값이 오류인 함수 표현식에 적합합니다. "오류가 nil이 아닌 경우 결과 및 해당 오류의 다른 모든 값에 대해 0 값을 사용하여 함수에서 반환하고, 그렇지 않으면 오류 없이 값 집합을 생성"으로 정의됩니다. pop 에는 erroring() 와 권한 있는 상호 작용이 없습니다. 오류의 정상적인 반환은 erroring() 계속 표시됩니다. 이것은 또한 다른 반환 값에 대해 0이 아닌 값을 반환하고 지연된 오류 처리를 계속 사용할 수 있음을 의미합니다. 은유는 반환 값의 "목록"에서 가장 오른쪽 요소를 팝핑하는 것입니다.

erroring() 는 실행 중인 지연된 함수로 스택을 이동한 다음 이전 스택 요소(지연이 실행 중인 함수, 이 경우 NewClient)로 이동하여 현재 반환된 오류 값에 액세스하는 것으로 정의됩니다. 진행 중입니다. 함수에 그러한 매개변수가 없으면 패닉하거나 nil을 반환합니다(둘 중 더 합리적인 것). 이 오류 값은 pop 에서 올 필요가 없습니다. 대상 함수에서 오류를 반환하는 모든 것입니다.

seterr(error) 사용하면 반환되는 오류 값을 변경할 수 있습니다. 그러면 미래의 erroring() 호출에서 볼 수 있는 오류가 표시되며 여기에 표시된 대로 지금 수행할 수 있는 것과 동일한 지연 기반 연결이 허용됩니다.

여기에서 hashcorp wraping 및 multierror를 사용하고 있습니다. 원하는 대로 자신만의 영리한 패키지를 삽입하십시오.

추가 기능이 정의되어 있어도 합계가 더 짧습니다. 추가 사용에 걸쳐 두 기능을 상각할 것으로 예상하므로 부분적으로만 계산해야 합니다.

주변에 더 많은 구문을 사용하지 않고 forwardPort 처리를 그대로 두는 것을 관찰하십시오. 예외적인 경우로 더 자세한 것은 괜찮습니다.

이 제안서 IMHO에서 가장 흥미로운 점은 일반적인 예외를 제외하고 이것을 작성하려고 한다고 상상할 때만 볼 수 있습니다. 상당히 깊게 중첩되어 발생하고 발생할 수 있는 오류의 _collection_을 처리하는 것은 예외 처리로 상당히 지루합니다. (실제 Go 코드에서 .Close 오류가 무시되는 경향이 있는 것처럼 예외 처리기 자체에서 발생하는 오류는 예외 기반 코드에서 무시되는 경향이 있습니다.)

이것은 defer 와 같은 기존 Go 패턴과 값으로서의 오류 사용을 확장하여 어떤 경우에는 현재 Go 또는 예외로 표현하기 어려운 오류 처리 패턴을 쉽게 수정하고 근본적인 수술이 필요하지 않습니다. 런타임에 (나는 생각하지 않습니다), 또한 실제로 Go 2.0을 _요구하지_ 않습니다.

단점으로는 erroring , pop , seterr 를 키워드로 사용하고 이러한 기능에 대해 defer 오버헤드가 발생한다는 점, 인수분해 오류 처리가 일부를 우회한다는 사실이 있습니다. 핸들링 기능에 대해, 그리고 올바른 핸들링을 "강제"하기 위해 아무 것도 하지 않는다는 것입니다. 마지막이 가능한지 확실하지 않지만 이전 버전과의 (올바른) 요구 사항에 따라 항상 현재 작업을 수행할 수 있습니다.

여기에서 매우 흥미로운 토론이 있습니다.

마술처럼 나타나는 변수가 도입되지 않도록 오류 변수를 왼쪽에 유지하고 싶습니다. 원래 제안과 마찬가지로 같은 줄에서 오류를 처리하고 싶습니다. || -operator는 "너무 부울"처럼 보이고 어떻게든 "반환"을 숨기므로 사용하지 않습니다.

그래서 확장된 키워드 "return?"을 사용하여 더 읽기 쉽게 만들 것입니다. C#에서 물음표는 바로 가기를 만들기 위해 일부 위치에서 사용됩니다. 예를 들어 쓰는 대신:

if(foo != null)
{ foo.Bar(); }

다음과 같이 작성할 수 있습니다.
foo?.Bar();

따라서 Go 2의 경우 이 솔루션을 제안하고 싶습니다.

func foobar() error {
    return fmt.Errorf("Some error happened")
}

// Implicitly return err (there must be exactly one error variable on the left side)
err := foobar() return?
// Explicitly return err
err := foobar() return? err
// Return extended error info
err := foobar() return? &PathError{"chdir", dir, err}
// Return tuple
err := foobar() return? -1, err
// Return result of function (e. g. for logging the error)
err := foobar() return? handleError(err)
// This doesn't compile as you ignore the error intentionally
foobar() return?

그냥 생각:

foo, err := myFunc()
오류 != 없음 ? 리턴 랩(오류)

또는

오류 != nil이면? 리턴 랩(오류)

그 주위에 중괄호를 넣을 의향이 있다면 아무것도 변경할 필요가 없습니다!

if err != nil { return wrap(err) }

원하는 사용자 정의 처리를 _모두_ 가질 수 있고(또는 전혀), 일반적인 경우에서 두 줄의 코드를 저장했으며, 100% 이전 버전과 호환되며(언어에 대한 변경 사항이 없기 때문에) 더 간결하고 쉬운. 그것은 Ian의 드라이빙 포인트의 많은 부분을 공격합니다. 유일한 변경 사항은 gofmt 도구입니까?

나는 비슷한 carlmjohnson의 제안을 읽기 전에 이것을 썼습니다 ...

오류가 발생하기 전에 # 입니다.

그러나 실제 응용 프로그램에서는 여전히 일반 if err != nil { ... } 해야 오류를 기록할 수 있습니다. after 라는 주석을 통해 반환 미들웨어를 추가할 수 없다면 최소한의 오류 처리를 쓸모 없게 만듭니다. , 함수가...를 반환한 후 실행됩니다( defer 와 비슷하지만 args 포함).

@after(func (data string, err error) {
  if err != nil {
    log.Error("error", data, " - ", err)
  }
})
func alo() (string, error) {
  // this is the equivalent of
  // data, err := db.Find()
  // if err != nil { 
  //   return "", err 
  // }
  str, #err := db.Find()

  // ...

  #err = db.Create()

  // ...

  return str, nil
}

func alo2() ([]byte, []byte, error, error) {
  // this is the equivalent of
  // data, data2, err, errNotFound := db.Find()
  // if err != nil { 
  //   return nil, nil, err, nil
  // } else if errNotFound != nil {
  //   return nil, nil, nil, errNotFound
  // }
  data, data2, #err, #errNotFound := db.Find()

  // ...

  return data, data2, nil, nil
}

보다 깨끗함:

func alo() (string, error) {
  str, err := db.Find()
  if err != nil {
    log.Error("error on find in database", err)
    return "", err
  }

  // ...

  if err := db.Create(); err != nil {
    log.Error("error on create", err)
    return "", err
  }

  // ...

  return str, nil
}

func alo2() ([]byte, []byte, error, error) {
  data, data2, err, errNotFound := db.Find()
  if err != nil { 
    return nil, nil, err, nil
  } else if errNotFound != nil {
    return nil, nil, nil, errNotFound
  }

  // ...

  return data, data2, nil, nil
}

같은 스위프트에 대해 어떻게 guard 문, 대신를 제외시켰다 guard...else 그것의 guard...return :

file, err := os.Open("fails.txt")
guard err return &FooError{"Couldn't foo fails.txt", err}

guard os.Remove("fails.txt") return &FooError{"Couldn't remove fails.txt", err}

나는 go 오류 처리의 명시성을 좋아합니다. imho의 유일한 문제는 얼마나 많은 공간이 필요한가입니다. 2가지 조정을 제안합니다.

1. 부울 컨텍스트에서 nil-able 항목을 사용할 수 있습니다. 여기서 nil 는 false , nil ~ true
2. && 및 || 와 같은 단일 행 조건문 연산자 지원

그래서

file, err := os.Open("fails.txt")
if err != nil {
    return &FooError{"Couldn't foo fails.txt", err}
}

될 수 있다

file, err := os.Open("fails.txt")
if err {
    return &FooError{"Couldn't foo fails.txt", err}
}

또는 더 짧은

file, err := os.Open("fails.txt")
err && return &FooError{"Couldn't foo fails.txt", err}

그리고, 우리는 할 수 있습니다

i,ok := v.(int)
ok || return fmt.Errorf("not a number")

또는 아마도

i,ok := v.(int)
ok && s *= i

&& 및 || 를 오버로드하면 모호성이 너무 커지면 ? 및 # 또는 ?? 와 같이 다른 문자(2개 이하)를 선택할 수 있습니다. ## , 또는 ?? 및 !! , 무엇이든. 요점은 최소한의 "노이즈" 문자(필요한 괄호, 중괄호 등이 필요 없음)로 한 줄 조건문을 지원하는 것입니다. && 및 || 연산자는 다른 언어에서 이러한 사용법이 있기 때문에 좋습니다.

이 복잡한 단일 라인 조건식 만 한 줄 조건문을 지원하기위한 제안이 아니다.

또한 이것은 일부 다른 언어를 포함한 "진실성"의 전체 범위를 지원하기 위한 제안이 아닙니다 . 이러한 조건문은 nil/non-nil 또는 부울 만 지원합니다.

이러한 조건부 연산자의 경우 단일 변수로 제한하고 표현식을 지원하지 않는 것이 적합할 수도 있습니다. 더 복잡하거나 else 절이 있는 것은 표준 if ... 구문으로 처리됩니다.

왜 바퀴를 발명하고 @mattn이 이전에 말한 대로 알려진 try..catch 형식을 사용하지 않습니까 ? )

try {
    a := foo() // func foo(string, error)
    b := bar() // func bar(string, error)
} catch (err) {
    // handle error
}

당신은 정말이 필요하면 당신은 항상의 이전 형태로 사용할 수 있습니다 때문에 혔 오류 소스를 구별 할 이유가없는 것 같습니다 if err != nil 하지 않고 try..catch .

또한 그것에 대해 잘 모르겠지만 처리되지 않으면 오류를 "던질" 수 있는 기능을 추가할 수 있습니까?

func foo() (string, error) {
    f := bar() // similar to if err != nil { return "", err }
}

func baz() string {
    // Compilation error.
    // bar's error must be handled because baz() does not return error.
    return bar()
}

@gobwas 는 가독성의 관점에서 제어 흐름을 완전히 이해하는 것이 매우 중요합니다. 귀하의 예를 보면 어떤 줄이 catch 블록으로 점프할 수 있는지 알 수 없습니다. 숨겨진 goto 문과 같습니다. 현대 언어가 이에 대해 명시적으로 시도하고 프로그래머가 오류 발생으로 인해 제어 흐름이 분기될 수 있는 위치를 명시적으로 표시하도록 요구하는 것은 놀라운 일이 아닙니다. return 또는 goto 와 비슷하지만 훨씬 더 좋은 구문을 사용합니다.

@creker 네, 전적으로 동의합니다. 위의 예에서 흐름 제어에 대해 생각하고 있었지만 간단한 형식으로 이것을 수행하는 방법을 깨닫지 못했습니다.

아마도 다음과 같습니다.

try {
    a ::= foo() // func foo(string, error)
    b ::= bar() // func bar(string, error)
} catch (err) {
    // handle error
}

또는 try a := foo() 와 같은 다른 제안이 ..?

@gobwas

catch 블록에 들어갈 때 try 블록의 어떤 함수가 오류를 일으켰는지 어떻게 알 수 있습니까?

@urandom 알아야 한다면 if err != nil 없이 try..catch if err != nil 하고 싶을 것입니다.

@robert-wallis: 이전 스레드에서 Swift의 가드 문을 언급했지만 페이지가 너무 커서 Github에서 기본적으로 더 이상 로드하지 않습니다. :-PI는 여전히 그것이 좋은 생각이라고 생각하며 일반적으로 긍정적/부정적인 예를 위해 다른 언어를 찾는 것을 지지합니다.

@pdk

부울 컨텍스트에서 nil-able 항목을 사용할 수 있도록 허용합니다. 여기서 nil은 false와 동일하고 non-nil은 true와 동일합니다.

나는 이것이 사람들이 if myflag { ... } 쓰지만 if *myflag { ... } 를 쓰는 것을 의미하는 플래그 패키지를 사용하여 많은 버그로 이어지는 것을 봅니다. 그리고 그것은 컴파일러에 의해 잡히지 않습니다.

try/catch는 여러 가지를 연속적으로 시도할 때 if/else보다 짧습니다. 이는 제어 흐름 문제 등으로 인해 모두가 나쁘다고 동의하는 것입니다.

FWIW, Swift의 try/catch는 적어도 어떤 문이 던질 수 있는지 모르는 시각적 문제를 해결합니다.

do {
    let dragon = try summonDefaultDragon() 
    try dragon.breathFire()
} catch DragonError.dragonIsMissing {
    // ...
} catch DragonError.halatosis {
    // ...
}

@robert-wallis, 예가 있습니다.

file, err := os.Open("fails.txt")
guard err return &FooError{"Couldn't foo fails.txt", err}

guard os.Remove("fails.txt") return &FooError{"Couldn't remove fails.txt", err}

처음 사용할 때에 guard , 그것은처럼 엄청 많이 보이는 if err != nil { return &FooError{"Couldn't foo fails.txt", err}} 그래서 나는 확실히 그 큰 승리의 경우 아니에요.

두 번째 사용에서는 err 가 어디에서 왔는지 즉시 명확하지 않습니다. os.Open 에서 반환된 내용인 것 같습니다. 귀하의 의도가 아니었을까요? 이게 더 정확할까요?

guard err = os.Remove("fails.txt") return &FooError{"Couldn't remove fails.txt", err}

어떤 경우에는 다음과 같이 보입니다 ...

if err = os.Remove("fails.txt"); err != nil { return &FooError{"Couldn't remove fails.txt", err}}

그러나 여전히 시각적 혼란이 적습니다. if err = , ; err != nil { - 비록 그것이 하나의 라이너라 할지라도 그러한 단순한 일에 대해 여전히 너무 많은 일이 진행되고 있습니다.

덜 복잡하다는 데 동의했습니다. 그러나 언어에 추가하는 것을 보증하기 위해 눈에 띄게 적은? 거기에 동의하는지 잘 모르겠습니다.

Java/C#/...에 있는 try-catch 블록의 가독성은 오류 처리에 의해 중단 없이 "행복한 경로" 시퀀스를 따를 수 있기 때문에 매우 좋다고 생각합니다. 단점은 기본적으로 숨겨진 goto 메커니즘이 있다는 것입니다.

Go에서는 "행복한 경로" 논리가 더 잘 보이도록 오류 처리기 뒤에 빈 줄을 삽입하기 시작합니다. 따라서 golang.org의 이 샘플에서 (9줄)

record := new(Record)
err := datastore.Get(c, key, record) 
if err != nil {
    return &appError{err, "Record not found", 404}
}
err := viewTemplate.Execute(w, record)
if err != nil {
    return &appError{err, "Can't display record", 500}
}

나는 종종 그렇게한다 (11 라인)

record := new(Record)

err := datastore.Get(c, key, record) 
if err != nil {
    return &appError{err, "Record not found", 404}
}

err := viewTemplate.Execute(w, record)
if err != nil {
    return &appError{err, "Can't display record", 500}
}

이제 제안으로 돌아가서 이미 이와 같은 것을 게시했기 때문에 좋을 것입니다(3줄).

record := new(Record)
err := datastore.Get(c, key, record) return? &appError{err, "Record not found", 404}
err := viewTemplate.Execute(w, record) return? &appError{err, "Can't display record", 500}

이제 나는 행복한 길을 분명히 봅니다. 내 눈은 여전히 ​​오른쪽에 오류 처리를 위한 코드가 있다는 것을 알고 있지만 정말로 필요할 때만 "눈으로 분석"하면 됩니다.

모든 사람에게 질문: 이 코드를 컴파일해야 합니까?

func foobar() error {
    return fmt.Errorf("Some error")
}
func main() {
    foobar()
}

IMHO 사용자는 다음과 같이 의도적으로 오류를 무시한다고 말해야 합니다.

func main() {
    _ := foobar()
}

@ianlancetaylor 원본 게시물의 3번 항목과 관련된 미니 경험 보고서를 추가하면 추가 컨텍스트 정보와 함께 오류를 반환합니다 .

Go용 flac 라이브러리 를 개발할 때 @davecheney pkg/errors 패키지(https://github.com/mewkiz/flac/issues/22)를 사용하여 오류에 컨텍스트 정보를 추가하고 싶었습니다. 더 구체적으로 말하면, 오류를 스택 추적 정보로 주석 처리하는 errors.WithStack 을 사용하여 반환된 오류를 래핑합니다.

오류에 주석이 달려 있으므로 이 추가 정보를 저장하기 위해 새로운 기본 유형을 생성해야 합니다. errors.WithStack의 경우 유형은 errors.withStack 입니다.

type withStack struct {
    error
    *stack
}

이제 원래 오류를 검색하기 위해 규칙은 errors.Cause 를 사용하는 io.EOF 에 대해 원래 오류를 비교할 수 있습니다.

그런 다음 라이브러리 사용자는 errors.Cause 를 사용하여 원래 오류를 확인하는 https://github.com/mewkiz/flac/blob/0884ed715ef801ce2ce0c262d1e674fdda6c3d94/cmd/flac2wav/flac2wav.go#L78 행을 따라 무언가를 작성할 수 있습니다. 값:

frame, err := stream.ParseNext()
if err != nil {
    if errors.Cause(err) == io.EOF {
        break
    }
    return errors.WithStack(err)
}

이것은 거의 모든 경우에 잘 작동합니다.

추가된 컨텍스트 정보를 위해 전체에 걸쳐 pkg/errors를 일관되게 사용하기 위해 오류 처리를 리팩토링할 때 다소 심각한 문제에 부딪쳤습니다. 제로 패딩을 검증하기 위해 우리는 단순히 읽기 바이트가 0인지 확인하고 그렇지 않으면 오류를 보고하는 io.Reader 를 가 실패하기 시작 했다는 것입니다.

문제는 zeros.Read 의해 반환된 오류의 기본 유형이 이제 io.EOF가 아니라 errors.withStack이라는 것입니다. 따라서 io.Copy 와 함께 해당 리더를 사용할 때 문제가 발생했습니다. io.EOF 구체적으로 확인하고 errors.Cause 를 사용하여 주석이 달린 오류를 "풀기"하는 방법을 모릅니다. 문맥 정보. 표준 라이브러리를 업데이트할 수 없으므로 주석 정보 없이 오류를 반환하는 것이 솔루션이었습니다(https://github.com/mewkiz/flac/commit/6805a34d854d57b12f72fd74304ac296fd0c07be).

구체적인 값을 반환하는 인터페이스에 대한 주석이 달린 정보를 잃는 것은 손실이지만, 함께 살 수 있습니다.

우리의 경험에서 얻은 교훈은 우리의 테스트 사례가 이것을 포착했기 때문에 운이 좋았다는 것입니다. zeros 유형은 여전히 io.Reader 인터페이스를 구현하므로 컴파일러는 오류를 생성하지 않았습니다. 또한 추가된 오류 주석은 기계 생성 재작성이므로 문제가 발생할 것이라고 생각하지 않았습니다. 오류에 컨텍스트 정보를 추가하기만 하면 정상 상태에서 프로그램 동작에 영향을 미치지 않아야 합니다.

그러나 그렇게 했으며 이러한 이유로 우리는 고려를 위해 경험 보고서를 제공하고자 합니다. 컨텍스트 정보 추가를 Go 2의 오류 처리에 통합하여 오류 비교(인터페이스 계약에서 사용됨)가 여전히 원활하게 유지되도록 하는 방법을 생각할 때.

친절한,
남자 이름

@mewmew , 오류 처리의 제어 흐름 측면에 대해 이 문제를 유지합시다. 흐름을 제어하는 ​​것과 거의 직교하기 때문에 오류를 래핑하고 래핑 해제하는 가장 좋은 방법은 다른 곳에서 논의해야합니다.

나는 당신의 코드베이스에 익숙하지 않고 당신이 그것이 자동화된 리팩토링이라고 말한 것을 알고 있습니다. 그런데 왜 EOF에 상황 정보를 포함해야 합니까? 유형 시스템에서 오류로 처리되지만 EOF는 실제 오류가 아니라 신호 값에 가깝습니다. 특히 io.Reader 구현에서는 대부분의 경우 예상 값입니다. io.EOF 가 아닌 경우에만 오류를 래핑하는 것이 더 낫지 않을까요?

예, 저는 우리가 사물을 있는 그대로 두는 것을 제안합니다. 나는 Go의 오류 시스템이 개발자들이 호출 스택에 오류를 퍼뜨리는 것을 방지하기 위해 의도적으로 이런 식으로 설계되었다는 인상을 받았습니다. 해당 오류는 발생한 위치에서 해결하고 할 수 없을 때 패닉을 사용하는 것이 더 적절한 때를 알기 위한 것입니다.

어쨌든 try-catch-throw가 기본적으로 panic() 및 recover()와 동일한 동작이 아닌가요?

한숨, 우리가 정말로 이 길을 가려고 한다면. 왜 우리는 다음과 같은 것을 할 수 없습니까?

_, ? := foo()
x?, err? := bar()

또는 아마도 다음과 같은 것

_, err := foo(); return err?
x, err := bar(); return x? || err?
x, y, err := baz(); return (x? && y?) || err?

어디? if var != nil{ return var }의 약칭 별칭이 됩니다.

메서드에 의해 충족되는 또 다른 특별한 내장 인터페이스를 정의할 수도 있습니다.

func ?() bool //looks funky but avoids breakage.

근본적으로 새롭고 향상된 조건부 연산자의 기본 동작을 재정의하는 데 사용할 수 있습니다.

@mortdeus

나는 동의한다고 생각한다.
문제가 행복한 경로를 제시하는 좋은 방법을 갖는 것이라면 IDE용 플러그인은 바로 가기를 사용하여 if err != nil { return [...] } 의 모든 인스턴스를 접거나 펼칠 수 있습니까?

지금은 모든 부분이 중요하다고 느낀다. err != nil 는 중요합니다. return ... 는 중요합니다.
쓰기가 좀 번거롭긴 하지만 써야 합니다. 그리고 정말 사람의 속도를 늦추나요? 시간이 걸리는 것은 오류를 작성하는 것이 아니라 오류와 반환할 내용을 생각하는 것입니다.

err 변수의 범위를 제한할 수 있는 제안에 더 관심이 있습니다.

내 조건부 아이디어는이 문제를 해결하는 가장 깔끔한 방법이라고 생각합니다. 이 기능을 Go에 포함할 만큼 충분히 가치 있게 만들 수 있는 몇 가지 다른 사항을 생각했습니다. 제 아이디어는 별도의 제안서에 작성하겠습니다.

이것이 어떻게 작동하는지 알 수 없습니다.

x, y, err := baz(); 반환( x? && y? ) || err?

어디? if var == nil{ return var }의 약칭 별칭이 됩니다.

x, y, err := baz(); 반환( if x == nil{ return x} && if y== nil{ return y} ) || if err == nil{ return err}

x, y, err := baz(); 리턴(x? && y?) || 잘못?

된다

x, y, err := baz();
if ((x != nil && y !=nil) || err !=nil)){
반환 x, y, 오류
}

x를 볼 때? && 요? || 잘못? "x와 y가 유효합니까? 오류는 어떻습니까?"라고 생각해야합니다.

그렇지 않으면 반환 기능이 실행되지 않습니다. 나는 방금 새로운 특별한 내장 인터페이스 유형으로 아이디어를 조금 더 발전시킨 이 아이디어에 대한 새로운 제안을 작성했습니다.

Go 버전 2에서 기본 오류 처리를 추가할 것을 제안합니다.

사용자가 오류를 처리하지 않으면 컴파일러는 nil이 아니면 err을 반환하므로 사용자가 다음과 같이 작성합니다.

func Func() error {
    func1()
    func2()
    return nil
}

func func1() error {
    ...
}

func func2() error {
    ...
}

컴파일 변환:

func Func() error {
    err := func1()
    if err != nil {
        return err
    }

    err = func2()
    if err != nil {
        return err
    }

    return nil
}

func func1() error {
    ...
}

func func2() error {
    ...
}

사용자가 오류를 처리하거나 _를 사용하여 무시하면 컴파일러는 아무 작업도 수행하지 않습니다.

_ = func1()

또는

err := func1()

여러 반환 값의 경우 비슷합니다.

func Func() (*YYY, error) {
    ch, x := func1()
    return yyy, nil
}

func func1() (chan int, *XXX, error) {
    ...
}

컴파일러는 다음과 같이 변환합니다.

func Func() (*YYY, error) {
    ch, x, err := func1()
    if err != nil {
        return nil, err
    }

    return yyy, nil
}

func func1() (chan int, *XXX, error) {
    ...
}

Func()의 서명이 오류를 반환하지 않고 오류를 반환하는 함수를 호출하면 컴파일러는 오류를 보고합니다. "Func()에서 오류를 처리하십시오."
그런 다음 사용자는 Func()에 오류를 기록할 수 있습니다.

사용자가 오류에 대한 정보를 래핑하려면 다음을 수행하십시오.

func Func() (*YYY, error) {
    ch, x := func1() ? Wrap(err, "xxxxx", ch, "abc", ...)
    return yyy, nil
}

또는

func Func() (*YYY, error) {
    ch, x := func1() ? errors.New("another error")
    return yyy, nil
}

이점은,

1. 프로그램은 오류가 발생한 지점에서 실패할 뿐이며 사용자는 오류를 묵시적으로 무시할 수 없습니다.
2. 코드 줄을 현저하게 줄일 수 있습니다.

Go는 여러 반환 값을 가질 수 있고 언어는 개발자가 무슨 일이 일어나고 있는지 명시적으로 인식하지 않고 기본적으로 반환 인수에 대한 기본값과 동일한 것을 할당해서는 안 되기 때문에 쉽지 않습니다.

나는 할당 구문에 오류 처리를 넣는 것이 "오류 처리가 반복적"인 문제의 근본을 해결하지 못한다고 생각합니다.

여러 줄의 코드 뒤에 if (err != nil) { return nil } (또는 이와 유사한 것)를 사용하는 것은 DRY(반복하지 않음) 원칙에 위배됩니다. 이것이 우리가 이것을 좋아하지 않는 이유라고 생각합니다.

try ... catch 에도 문제가 있습니다. 오류가 발생한 동일한 함수에서 명시적으로 오류를 처리할 필요가 없습니다. 이것이 우리가 try...catch 좋아하지 않는 주목할만한 이유라고 생각합니다.

나는 이것들이 상호 배타적이라고 믿지 않습니다. 우리는 일종의 가질 수 try...catch 없이 throws .

개인적으로 try...catch 에 대해 싫어하는 또 다른 점은 try 키워드의 임의적 필요성입니다. 작업 문법에 관한 한 범위 제한기 뒤에 catch 를 할 수 없는 이유는 없습니다. (누가 내가 이것에 대해 틀렸다면 그것을 불러주세요)

이것이 내가 제안하는 것입니다.

• ? 를 반환된 오류에 대한 자리 표시자로 사용합니다. 여기서 _ 는 이를 무시하는 데 사용됩니다.
• 아래 예에서와 같이 catch 대신 error? 사용하여 완전한 역호환성을 사용할 수 있습니다.

^ 이것이 이전 버전과 호환된다는 내 가정이 잘못된 경우 전화하십시오.

func example() {
    {
        // The following line will invoke the catch block
        data, ? := foopkg.buyIt()
        // The next two lines handle an error differently
        otherData, err := foopkg.useIt()
        if err != nil {
            // Here we eliminated deeper indentation
            otherData, ? = foopkg.breakIt()
        }
        if data == "" || otherData == "" {
        }
    } catch (err) {
        return errors.Label("fix it", err)
        // Aside: why not add Label() to the error package?
    }
}

이에 반대하는 주장을 생각했습니다. 이렇게 작성하면 catch 블록을 변경하면 더 깊은 범위의 코드에 의도하지 않은 영향을 미칠 수 있습니다. 이것은 try...catch 와 동일한 문제입니다.

단일 기능의 범위 내에서만 이 작업을 수행할 수 있다면 위험을 관리할 수 있다고 생각합니다. 아마도 많은 것을 변경하려고 할 때 오류 처리 코드 줄을 변경하는 것을 잊어버리는 현재의 위험과 같을 것입니다. 나는 이것을 코드 재사용의 결과와 DRY를 따르지 않은 결과 사이의 동일한 차이점으로 봅니다(즉, 그들이 말하는 것처럼 무료 점심 없음)

편집: 내 예에 대해 중요한 동작을 지정하는 것을 잊었습니다. ? 가 catch 없는 범위에서 사용되는 경우, 이것은 컴파일러 오류여야 한다고 생각합니다.

편집 2: 미친 생각: 아마도 catch 블록은 제어 흐름에 영향을 미치지 않을 것입니다... 말 그대로 catch { ... } 내부의 코드를 복사하여 오류가 발생한 후 행에 붙여넣는 것과 같습니다. ? ed(정확하지 않음 - 여전히 자체 범위가 있음). 우리 중 누구도 그것에 익숙하지 않기 때문에 이상하게 보입니다. 따라서 catch 이 방법으로 수행되면 확실히 키워드가 아니어야 하지만 그렇지 않으면... 왜 안 될까요?

@mewmew , 오류 처리의 제어 흐름 측면에 대해 이 문제를 유지합시다. 흐름을 제어하는 ​​것과 거의 직교하기 때문에 오류를 래핑하고 래핑 해제하는 가장 좋은 방법은 다른 곳에서 논의해야합니다.

좋아, 흐름을 제어하기 위해 이 스레드를 유지하자. 포인트 3 반환 오류 추가 컨텍스트 정보 의 구체적인 사용과 관련된 문제였기 때문에 단순히 추가했습니다.

@jba 오류에 대한 컨텍스트 정보의 래핑/언래핑과 관련된 문제를 특별히 알고 있습니까?

나는 당신의 코드베이스에 익숙하지 않고 당신이 그것이 자동화된 리팩토링이라고 말한 것을 알고 있습니다. 그런데 왜 EOF에 상황 정보를 포함해야 합니까? 유형 시스템에서 오류로 처리되지만 EOF는 실제 오류가 아니라 신호 값에 가깝습니다. 특히 io.Reader 구현에서는 대부분의 경우 예상 값입니다. io.EOF가 아닌 경우에만 오류를 래핑하는 것이 더 나은 수정이 아니었을까요?

@DeedleFake 조금 자세히 설명할 수 있지만 주제를 유지하기 위해 앞서 언급한 오류에 대한 컨텍스트 정보 래핑/언래핑 전용 문제에서 그렇게 할 것입니다.

모든 제안(내 제안 포함)을 읽으면 읽을수록 이동 중에 오류 처리에 실제로 문제가 있다고 생각하지 않습니다.

내가 원하는 것은 실수로 오류 반환 값을 무시하지 않고 최소한
_ := returnsError()

이러한 문제를 찾기 위한 도구가 있다는 것을 알고 있지만 언어의 첫 번째 수준 지원에서 일부 버그를 잡을 수 있습니다. 오류를 전혀 처리하지 않는 것은 이미 오류인 사용하지 않은 변수를 갖고 있는 것과 같습니다. 또한 모든 위치에서 처리해야 하기 때문에 함수에 오류 반환 유형을 도입할 때 리팩토링에 도움이 됩니다.

여기서 대부분의 사람들이 해결하려고 하는 주요 문제는 "타자하는 양" 또는 "줄의 수"인 것 같습니다. 줄 수를 줄이는 구문에는 동의하지만 대부분 gofmt 문제입니다. 인라인 "단일 라인 범위"를 허용하기만 하면 됩니다.

일부 입력을 저장하기 위한 또 다른 제안은 부울과 같은 암시적 nil 검사입니다.

err := returnsError()
if err { return err }

또는

if err := returnsError(); err { return err }

모든 포인터 유형의 원인에서 작동합니다.

내 생각에는 함수 호출 + 오류 처리를 한 줄로 줄이는 모든 것이 코드 가독성이 떨어지고 구문이 더 복잡해질 것이라는 것입니다.

덜 읽기 쉬운 코드와 더 복잡한 구문.

장황한 오류 처리 때문에 이미 가독성이 낮은 코드가 있습니다. 이미 언급한 스캐너 API 트릭을 추가하면 그 장황함을 숨길 수 있어 상황이 더욱 악화됩니다. 더 복잡한 구문을 추가하면 가독성에 도움이 될 수 있습니다. 그렇지 않으면 이 토론의 의미가 없습니다. 내 의견으로는 오류를 발생시키고 다른 모든 것에 대해 0 값을 반환하는 패턴은 언어 변경을 보증하기에 충분히 일반적입니다.

오류를 버블링하고 모든 항목에 대해 0 값을 반환하는 패턴

19642는 이것을 더 쉽게 만들 것입니다.

또한 경험 보고서에 대해 @mewmew 에게 감사드립니다. 특정 종류의 오류 처리 설계의 위험과 관련된 한 이 스레드와 확실히 관련이 있습니다. 나는 이것들을 더 보고 싶다.

내 아이디어를 잘 설명하지 못한 것 같아서 요점을 만들었습니다(그리고 방금 알아차린 많은 단점을 수정했습니다).

https://gist.github.com/KernelDeimos/384aabd36e1789efe8cbce3c17ffa390

이 요지에는 하나 이상의 아이디어가 있으므로 서로 별도로 논의할 수 있기를 바랍니다.

여기서 제안이 명시적으로 오류 처리에 대한 것이어야 한다는 생각을 잠시 제쳐두고 Go가 collect 문과 같은 것을 도입했다면 어떻게 될까요?

collect 문은 collect [IDENT] [BLOCK STMT] . 여기서 ident는 nil -able 유형의 범위 내 변수여야 합니다. collect 문 내에서 특수 변수 _! 를 수집 대상 변수의 별칭으로 사용할 수 있습니다. _! 는 _ 와 같이 대입 외에는 어디에도 사용할 수 없습니다. _! 가 할당될 때마다 암시적 nil 검사가 수행되고 _! 가 nil이 아니면 블록 실행이 중지되고 나머지 코드로 계속 진행됩니다.

이론적으로 이것은 다음과 같이 보일 것입니다.

func TryComplexOperation() (*Result, error) {
    var result *Result
    var err error

    collect err {
        intermediate1, _! := Step1()
        intermediate2, _! := Step2(intermediate1, "something")
        // assign to result from the outer scope
        result, _! = Step3(intermediate2, 12)
    }
    return result, err
}

에 해당하는

func TryComplexOperation() (*Result, error) {
    var result *Result
    var err error

    {
        var intermediate1 SomeType
        intermediate1, err = Step1()
        if err != nil { goto collectEnd }

        var intermediate2 SomeOtherType
        intermediate2, err = Step2(intermediate1, "something")
        if err != nil { goto collectEnd }

        result, err = Step3(intermediate2, 12)
        // if err != nil { goto collectEnd }, but since we're at the end already we can omit this
    }

collectEnd:
    return result, err
}

이와 같은 구문 기능을 사용하면 다음과 같은 몇 가지 멋진 기능을 사용할 수 있습니다.

// try several approaches for acquiring a value
func GetSomething() (s *Something) {
    collect s {
        _! = fetchOrNil1()
        _! = fetchOrNil2()
        _! = new(Something)
    }
    return s
}

새로운 구문 기능이 필요합니다.

1. 키워드 collect
2. special ident _! (나는 파서에서 이것을 가지고 놀았고, 다른 것을 깨뜨리지 않고 이 일치를 ident로 만드는 것은 어렵지 않다)