Bắt đầu kỹ thuật xử lý lỗi [đã đóng]

Tôi chỉ mới bắt đầu với cờ vây. Mã của tôi bắt đầu có rất nhiều điều này:

   if err != nil {
      //handle err
   }

hoặc cái này

  if err := rows.Scan(&some_column); err != nil {
      //handle err
  }

Có một số thành ngữ / chiến lược / phương pháp hay nhất để kiểm tra và xử lý lỗi trong cờ vây không?

CHỈNH SỬA để làm rõ: Tôi không khoe khoang hay gợi ý rằng đội cờ vây nên nghĩ ra thứ gì đó tốt hơn. Tôi đang hỏi liệu tôi có đang làm đúng hay không hay tôi đã bỏ lỡ một số kỹ thuật mà cộng đồng đã đưa ra. Cảm ơn tất cả.

Mã của bạn là thành ngữ và theo ý kiến ​​của tôi, đó là phương pháp hay nhất hiện có. Chắc chắn một số sẽ không đồng ý, nhưng tôi cho rằng đây là phong cách được thấy ở khắp các thư viện tiêu chuẩn ở Golang . Nói cách khác, các tác giả Go viết xử lý lỗi theo cách này.

Sáu tháng sau khi câu hỏi này được hỏi, Rob Pike đã viết một bài blog có tiêu đề Lỗi là Giá trị .

Trong đó, ông lập luận rằng bạn không cần phải lập trình theo cách mà OP đã trình bày, và đề cập đến một số nơi trong thư viện tiêu chuẩn, nơi họ sử dụng một mẫu khác.

Tất nhiên, một câu lệnh phổ biến liên quan đến giá trị lỗi là để kiểm tra xem nó có phải là giá trị không, nhưng có vô số điều khác mà người ta có thể làm với giá trị lỗi và việc áp dụng một số trong những thứ đó có thể làm cho chương trình của bạn tốt hơn, loại bỏ phần lớn bảng soạn sẵn điều đó phát sinh nếu mọi lỗi được kiểm tra bằng câu lệnh if thuộc lòng.

...

Sử dụng ngôn ngữ để đơn giản hóa việc xử lý lỗi của bạn.

Nhưng hãy nhớ rằng: Dù bạn làm gì, hãy luôn kiểm tra lỗi của bạn!

Đó là một bài đọc hay.

Tôi sẽ đồng ý với câu trả lời của jnml rằng cả hai đều là mã thành ngữ và thêm những điều sau:

Ví dụ đầu tiên của bạn:

if err != nil {
      //handle err
}

thành ngữ hơn khi xử lý nhiều hơn một giá trị trả về. ví dụ:

val, err := someFunc()
if err != nil {
      //handle err
}
//do stuff with val

Ví dụ thứ hai của bạn là cách viết tắt hay khi chỉ xử lý errgiá trị. Điều này áp dụng nếu hàm chỉ trả về một errorhoặc nếu bạn cố tình bỏ qua các giá trị được trả về khác với error. Ví dụ, điều này đôi khi được sử dụng với các hàm Readervà Writertrả về một intsố byte được viết (đôi khi là thông tin không cần thiết) và error:

if _, err := f.Read(file); err != nil {
      //handle err
}
//do stuff with f

Dạng thứ hai được coi là sử dụng câu lệnh khởi tạo if .

Vì vậy, liên quan đến các phương pháp hay nhất, theo như tôi biết (ngoại trừ việc sử dụng gói "lỗi" để tạo lỗi mới khi bạn cần), bạn đã đề cập đến khá nhiều thứ bạn cần biết về lỗi abut trong Go!

EDIT: Nếu bạn tìm thấy bạn thực sự không thể sống mà không có ngoại lệ, bạn có thể bắt chước họ defer, panic&recover .

Tôi đã tạo một thư viện để xử lý lỗi được sắp xếp hợp lý và chuyển qua một hàng đợi các hàm Go.

Bạn có thể tìm thấy nó ở đây: https://github.com/go-on/queue

Nó có một biến thể cú pháp nhỏ gọn và dài dòng. Đây là một ví dụ cho cú pháp ngắn gọn:

import "github.com/go-on/queue/q"

func SaveUser(w http.ResponseWriter, rq *http.Request) {
    u := &User{}
    err := q.Q(                      
        ioutil.ReadAll, rq.Body,  // read json (returns json and error)
    )(
        // q.V pipes the json from the previous function call
        json.Unmarshal, q.V, u,   // unmarshal json from above  (returns error)
    )(
        u.Validate,               // validate the user (returns error)
    )(
        u.Save,                   // save the user (returns error)
    )(
        ok, w,                    // send the "ok" message (returns no error)
    ).Run()

    if err != nil {
       switch err {
         case *json.SyntaxError:
           ...
       }
    }
}

Xin lưu ý rằng có một chút chi phí hiệu suất, vì nó sử dụng phản xạ.

Ngoài ra, đây không phải là mã cờ vây thành ngữ, vì vậy bạn sẽ muốn sử dụng nó trong các dự án của riêng mình hoặc nếu nhóm của bạn đồng ý sử dụng nó.

Một "chiến lược" để xử lý lỗi trong golang và các ngôn ngữ khác là liên tục đề xuất lỗi lên ngăn xếp cuộc gọi cho đến khi bạn đủ cao trong ngăn xếp cuộc gọi để xử lý lỗi đó. Nếu bạn đã cố gắng xử lý lỗi đó quá sớm, thì rất có thể bạn sẽ phải lặp lại mã. Nếu bạn xử lý quá muộn, thì bạn sẽ phá vỡ một thứ gì đó trong mã của mình. Golang làm cho quá trình này trở nên siêu dễ dàng vì nó giúp bạn siêu rõ ràng cho dù bạn đang xử lý một lỗi tại một vị trí nhất định hay đang lan truyền nó.

Nếu bạn định bỏ qua lỗi, một dấu _ đơn giản sẽ tiết lộ sự thật này rất rõ ràng. Nếu bạn đang xử lý nó, thì chính xác trường hợp lỗi mà bạn đang xử lý sẽ rõ ràng vì bạn sẽ kiểm tra nó trong câu lệnh if.

Giống như mọi người đã nói ở trên, một sai số thực sự chỉ là một giá trị bình thường. Điều này đối xử với nó như vậy.

Các vị thần cờ vây đã xuất bản một "bản thiết kế nháp" để xử lý lỗi trong cờ vây 2. Nó nhằm mục đích thay đổi thành ngữ lỗi:

Tổng quan và Thiết kế

Họ muốn phản hồi từ người dùng!

Wiki phản hồi

Tóm lại, nó trông giống như:

func f() error {
   handle err { fmt.Println(err); return err }
   check mayFail()
   check canFail()
}

CẬP NHẬT: Thiết kế dự thảo đã nhận được rất nhiều lời chỉ trích, vì vậy tôi đã soạn thảo Yêu cầu cần xem xét đối với Xử lý lỗi Go 2 với một menu các khả năng cho giải pháp cuối cùng.

Hầu hết trong ngành đều tuân theo các quy tắc tiêu chuẩn được đề cập trong tài liệu golang Xử lý lỗi và Bắt đầu . Và nó cũng giúp tạo tài liệu cho dự án.

Dưới đây là hướng dẫn của tôi về việc giảm xử lý lỗi đối với Go, ví dụ là khi nhận các tham số URL HTTP:

(Mẫu thiết kế bắt nguồn từ https://blog.golang.org/errors-are-values )

type HTTPAdapter struct {
    Error *common.AppError
}

func (adapter *HTTPAdapter) ReadUUID(r *http.Request, param string, possibleError int) uuid.UUID {
    requestUUID := uuid.Parse(mux.Vars(r)[param])
    if requestUUID == nil { 
        adapter.Error = common.NewAppError(fmt.Errorf("parameter %v is not valid", param),
            possibleError, http.StatusBadRequest)
    }
    return requestUUID
}

gọi nó cho nhiều tham số có thể sẽ như sau:

    adapter := &httphelper.HTTPAdapter{}
    viewingID := adapter.ReadUUID(r, "viewingID", common.ErrorWhenReadingViewingID)
    messageID := adapter.ReadUUID(r, "messageID", common.ErrorWhenReadingMessadeID)
    if adapter.Error != nil {
        return nil, adapter.Error
    }

Đây không phải là một viên đạn bạc, nhược điểm là nếu bạn mắc nhiều lỗi, bạn chỉ có thể nhận được lỗi cuối cùng.

Nhưng trong trường hợp này, nó tương đối lặp lại và rủi ro thấp, do đó tôi chỉ có thể nhận được lỗi cuối cùng có thể xảy ra.

Bạn có thể xóa mã xử lý lỗi của mình cho các lỗi tương tự (vì lỗi là giá trị mà bạn phải cẩn thận ở đây) và viết một hàm mà bạn gọi với lỗi được chuyển vào để xử lý lỗi. Bạn sẽ không phải viết "if err! = Nil {}" mọi lúc. Một lần nữa, điều này sẽ chỉ dẫn đến việc làm sạch mã, nhưng tôi không nghĩ đó là cách làm việc ngu ngốc.

Một lần nữa, chỉ vì bạn có thể không có nghĩa là bạn nên làm .

goerr cho phép xử lý lỗi với các hàm

package main

import "github.com/goerr/goerr"
import "fmt"

func ok(err error) {
    if err != nil {
        goerr.Return(err)
        // returns the error from do_somethingN() to main()
        // sequence() is terminated
    }
}

func sequence() error {
    ok(do_something1())
    ok(do_something2())
    ok(do_something3())

    return nil /// 1,2,3 succeeded
}
func do_something1() error { return nil }
func do_something2() error { return fmt.Errorf("2") }
func do_something3() error {
    fmt.Println("DOING 3")
    return nil
}

func main() {
    err_do_something := goerr.OR1(sequence)

    // handle errors

    fmt.Println(err_do_something)
}

Nếu bạn muốn kiểm soát chính xác các lỗi, đây có thể không phải là giải pháp, nhưng đối với tôi, hầu hết thời gian, bất kỳ lỗi nào đều là một nút chặn hiển thị.

Vì vậy, tôi sử dụng các hàm để thay thế.

func Err(err error) {
    if err!=nil {
        fmt.Println("Oops", err)
        os.Exit(1)
    }
}

fi, err := os.Open("mmm.txt")
Err(err)