[Hyperledger Fabric v1.0] 4. OPREATION GUIDE(운영가이드): Error handling(오류 처리)

해당 글은 Hyperledger Fabric 페이지의 게시글을 번역 및 정리한 자료입니다.

원본 사이트 : http://hyperledger-fabric.readthedocs.io/en/release/error-handling.html

 Error handling(오류 처리)

General Overview(일반 개요)

패브릭 오류 처리 프레임 워크는 패브릭 저장소에서 자료공유오류가 아래에 있습니다. Go에서 제공하는 표준 오류 유형 대신 사용할 새로운 유형의 오류 CallStackError를 정의합니다.

CallStackError는 다음으로 구성됩니다.

• Component code - 오류를 생성하는 코드의 일반 영역 이름입니다. 구성 요소 코드는 세 개의 대문자로 구성되어야합니다. 수와 특수 문자는 허용되지 않습니다. 구성 요소 코드 세트는 common / errors / codes.go에 정의되어 있습니다.

• Reason code -- 오류가 발생한 이유를 식별하는 데 도움이되는 짧은 코드입니다. 이유 코드는 세 개의 숫자 값으로 구성되어야합니다. 문자와 특수 문자는 사용할 수 없습니다. 일련의 이유 코드는 common / error / codes.go에 정의되어 있습니다.

• Error code - 콜론으로 구분 된 구성 요소 코드 및 원인 코드입니다 (예 : MSP : 404

• Error message - 오류를 설명하는 텍스트 이는 fmt.Errorf()과 Errors.New()에 제공된 입력과 동일합니다. 오류가 현재 오류에 랩핑 된 경우 메시지가 추가됩니다.

• Callstack - 오류가 생성 될 때 호출 스택입니다. 오류가 현재 오류에 랩핑 된 경우 오류 메시지 및 콜 스택이 추가되어 랩핑 된 오류의 컨텍스트를 유지합니다.

CallStackError 인터페이스는 다음과 같은 기능을 제공합니다.

• Error () - callstack이 추가 된 오류 메시지를 반환합니다.

• Message () - 오류 메시지를 반환합니다 (콜 스택이 추가되지 않음).

• GetComponentCode () - 3 문자 구성 요소 코드를 반환합니다.

• GetReasonCode () - 3 자리 이유 코드를 반환합니다.

• GetErrorCode () - "component : reason"오류 코드를 반환합니다.

• GetStack () - 콜 스택 만 반환합니다.

• WrapError (error) - 제공된 오류를 CallStackError로 랩핑합니다.

Usage Instructions(사용 지침)

fmt.Errorf() or Errors.new()에 대한 모든 호출 대신 새로운 오류 처리 프레임 워크를 사용해야합니다. 이 프레임 워크를 사용하면 오류 메시지에 추가 할 호출 스택을 생성하는 옵션과 함께 확인할 오류 코드가 제공됩니다.

프레임 워크를 사용하는 것은 간단하며 코드를 쉽게 조정할 수 있습니다.

먼저 github.com/hyperledger/fabric/common/errors를이 프레임 워크를 사용하는 파일로 가져와야합니다.

core / chaincode / chaincode_support.go에서 다음을 예로 들어 보겠습니다.

err = fmt.Errorf("Error starting container: %s", err)

이 오류의 경우 오류에 대한 생성자를 호출하고 구성 요소 코드, 이유 코드 및 오류 메시지를 전달합니다. 마지막에는 오류 자체를 전달하면서 WrapError () 함수를 호출합니다.

fmt.Errorf("Error starting container: %s", err)

호출하면, 아래와 같이 나옵니다.

errors.ErrorWithCallstack("CHA", "505", "Error starting container").WrapError(err)

아무런 문제없이 그대로 메시지를 남길 수도 있습니다.

errors.ErrorWithCallstack("CHA", "505", "Error starting container: %s", err)

이 방법을 사용하면 이전 오류의 오류 메시지를 새 오류로 형식화 할 수 있지만 포장 된 오류가 CallStackError 인 경우에는 호출 스택을 인쇄 할 수 없습니다.

오류를 래핑하는 동안 오류 이외의 매개 변수에 대한 명령의 서식을 지정하는 시나리오를 강조 표시하는 두 번째 예는 다음과 같습니다.

fmt.Errorf("failed to get deployment payload %s - %s", canName, err)

호출하면, 아래와 같이 나옵니다.

errors.ErrorWithCallstack("CHA", "506", "Failed to get deployment payload %s", canName).WrapError(err)

Displaying error messages(오류 메시지 표시)

프레임 워크를 사용하여 오류를 만든 후에 오류 메시지를 표시하는 것은 다음과 같이 간단합니다.

logger.Errorf(err)

또는

fmt.Println(err)

또는

fmt.Printf("%s\n", err)

peer / common / common.go의 예 :

errors.ErrorWithCallstack("PER", "404", "Error trying to connect to local peer").WrapError(err)

오류 메시지가 표시됩니다.

PER:404 - Error trying to connect to local peer
Caused by: grpc: timed out when dialing

노트

• 콜 스택은 간결함을 위해 이 예에서는 표시되지 않았습니다.

 General guidelines for error handling in Fabric(Fabric의 오류 처리에 대한 일반 지침)

• 최선을 다하고있는 일이라면 오류를 기록하고 무시해야합니다.

• 사용자 요청을 처리하는 중이면 오류를 기록하고이를 반환해야합니다.
• 패브릭의 다른 곳에서 오류가 발생하면 오류를 감싸는 지 여부를 선택할 수 있습니다. 일반적으로 오류를 래핑하지 않고 그대로 반환하는 것이 가장 좋습니다. 그러나 유틸리티 함수가 호출되는 특정 경우에 오류를 새로운 구성 요소 및 이유 코드로 래핑하면 최종 사용자가 호출 스택을 검사하지 않고 오류가 실제로 발생한 위치를 파악하는 데 도움이됩니다.
• 패닉은 내부 오류 코드를 던지거나 복구 프로세스를 시작하여 같은 계층에서 처리해야하며 다른 패키지로 전파 할 수 없어야합니다.