首頁猿問將外部錯誤映射到 golang...

將外部錯誤映射到 golang 中的域錯誤

Go

Qyouu 2023-04-17 16:03:08

我有一個稱為ComputeService實現(xiàn)特定域邏輯的服務類型。服務本身取決于調(diào)用的接口的實現(xiàn)，Computer該接口具有方法Computer.Compute(args...) (value, error)。如圖所示，Compute它本身可能會返回某些錯誤。ComputeService需要使用正確的域錯誤代碼從一組域錯誤中發(fā)送適當?shù)腻e誤，以便可以完成翻譯，并且客戶端也可以適當?shù)靥幚礤e誤。我的問題是，Computer實現(xiàn)應該將它們的失敗包裝在域錯誤中還是應該ComputeService這樣做。如果ComputeService是這樣做的人，那么它將必須知道Computer接口的不同實現(xiàn)返回的不同錯誤，在我看來這打破了抽象。兩種方式如下所示：package arithmetictype Computer struct {}func (ac Computer) Compute(args ....) (value, error) { // errors is a domain-errors package defined in compute service project return errors.NewDivideByZero()}或者package computetype Service struct {}func (svc Service) Process(args...) error { computer := findComputerImplementation(args...) val, err := computer.Compute(args...) if err != nil { if err == arith.ErrDivideByZero { // converting an arithmetic computer implementation // specific error to domain error return errors.NewDivideByZero() } else if err == algebra.ErrInvalidCoEfficient { // converting an algebraic computer implementation // specific error to domain error return errors.NewBadInput() } // some new implementation was used and we have no idea // what errors it could be returning. so we have to send // a internal server error equivalent here return errors.NewInternalError() }}

查看完整描述

2 回答

千巷貓影

TA貢獻1829條經(jīng)驗獲得超7個贊

的實現(xiàn)者Computer應該用域錯誤來響應，因為它們是最接近操作的錯誤并且最能確定錯誤是什么。就像你說的，擁有這種邏輯打破 ComputeService了抽象。如果您需要將代碼從特定Computer錯誤映射到域錯誤，請創(chuàng)建將主要邏輯與該錯誤包裝代碼分開的包裝器結(jié)構(gòu)。

要保留內(nèi)部錯誤上下文，只需將原始錯誤嵌入到域錯誤中并創(chuàng)建IsSpecificDomainError幫助程序。

type MyDomainError struct {

Err error

}

func NewMyDomainErr(err error) error {

return &MyDomainError{err}

}

func IsMyDomainError(e error) bool {

_, ok := err.(*MyDomainError)

return ok

}

反對回復 2023-04-17

波斯汪

TA貢獻1811條經(jīng)驗獲得超4個贊

要保留內(nèi)部錯誤上下文，只需將原始錯誤嵌入到域錯誤中

我想我們都同意這strings.Contains(err.Error(), "not found")是脆弱的代碼。
我希望我們也同意我們更愿意看到像errors.Is(err, os.ErrNotExist).
但要點是，在許多情況下，包的未來發(fā)展必須避免調(diào)用者依賴特定的錯誤結(jié)果來滿足errors.Is(err, os.ErrNotExist)，即使這是導致今天結(jié)果的根本原因。
這就像查看未導出的字段或比較錯誤文本 - 這是一個可能會改變的細節(jié)。
雖然strings.Contains看起來很脆弱，但errors.Is看起來并不脆弱，也不應被視為脆弱。
如果我們要避免它變得脆弱，那么我們需要為包提供一種方法來報告詳細信息，而無需讓客戶對其進行測試。這種方式是無法解包的錯誤。

err.As():

var pe *os.PathError

if errors.As(err, &pe) {

? ? ?use(pe)

}

％在：

func inner() error { return errors.New("inner error") }

func outer() error { return fmt.Errorf("outer error: %w", inner()) }

fmt.Fprintf("%+v", outer())

// outer error:

//? ? ?/path/to/file.go:123

//? ?- inner error:

//? ? ?/path/to/file.go:122

Go 1.13 的當前狀態(tài)：

只是說明我認為團隊提供的折衷解決方案：

fmt.Errorf目前被廣泛用于包裝錯誤并返回一個新的（不透明的）錯誤（因為您無法訪問底層錯誤）。
'?%w' 現(xiàn)在可用于顯式選擇返回可解包的錯誤。
errors 被設計為沒有依賴關系的基礎包，因此每個包都可以依賴它。
團隊同意在存在廣泛分歧的領域下注，并希望發(fā)布足夠多的內(nèi)容（errors.Is，errors.As，對大多數(shù)人包裝錯誤的方式的擴展），以便人們可以實現(xiàn)目標。
泛型還沒有出現(xiàn)，我們不知道它什么時候會出現(xiàn)：關于泛型的激烈討論將使這個關于“錯誤 2 值”的問題看起來像兒戲。
errors.Is并且errors.As干凈簡潔，足以長時間舒適。

大多數(shù)有爭議的事情都被推遲到 1.14。