Gói Go có nên sử dụng log.Fatal và khi nào không?

Question

Tôi đã tránh sử dụng log.Fatal, nhưng gần đây tôi đã vô tình phát hiện ra những câu hỏi này; code-coverage và tests-using-log-fatal.

Một trong những ý kiến ​​từ những câu hỏi bảo hiểm 100 mã nói:

... Trong hầu hết các trường hợp log.Fatal nên chỉ được sử dụng trong các chức năng chính, hoặc init (hoặc có thể một số điều có nghĩa là để được gọi là chỉ trực tiếp từ họ)"

Nó đi tôi suy nghĩ, vì vậy tôi bắt đầu nhìn vào mã thư viện chuẩn được cung cấp với Go. có rất nhiều ví dụ về nơi kiểm tra mã trong thư viện tận dụng log.Fatal có vẻ ổn. một vài ví dụ bên ngoài của mã kiểm tra, chẳng hạn như trong net/http, hiển thị dưới đây:

// net/http/transport.go 
func (t *Transport) putIdleConn(pconn *persistConn) bool { 
    ... 
    for _, exist := range t.idleConn[key] { 
     if exist == pconn { 
      log.Fatalf("dup idle pconn %p in freelist", pconn) 
     } 
    } 
    ... 
} 

Nếu nó là thực hành tốt nhất để tránh sử dụng log.Fatal, tại sao là nó được sử dụng ở tất cả trong các thư viện chuẩn, tôi lại có thể ngờ chỉ trả lại một lỗi. Có vẻ như không công bằng đối với người sử dụng thư viện làm cho os.Exit được gọi và không cung cấp bất kỳ cơ hội nào cho ứng dụng để dọn dẹp.

Tôi có thể ngây thơ, do đó, câu hỏi của tôi như là một thực hành tốt hơn có vẻ là để gọi log.Panic mà có thể được phục hồi và ứng dụng ổn định dài chạy của tôi lý thuyết có thể có cơ hội tăng từ đống tro tàn.

Vì vậy, thực hành tốt nhất nên nói gì về Tìm hiểu khi nào nên đăng nhập.Tiếp nên được sử dụng?

Answer 1

Có thể chỉ là tôi, nhưng đây là cách tôi sử dụng log.Fatal. Theo các quy ước UNIX, một quá trình gặp lỗi sẽ thất bại càng sớm càng tốt với mã thoát khác không. Điều này dẫn tôi các nguyên tắc sau đây để sử dụng log.Fatal khi ...

1. ... một lỗi xảy ra trong bất kỳ func init() của tôi, như những xảy ra khi nhập khẩu được chế biến hoặc trước func chính được gọi là, tương ứng. Ngược lại, tôi chỉ làm những thứ không ảnh hưởng trực tiếp đến đơn vị công việc mà thư viện hay cmd phải làm. Ví dụ, tôi thiết lập đăng nhập và kiểm tra thời tiết, chúng tôi có một môi trường và thông số lành mạnh. Không cần phải chạy chính nếu chúng ta có cờ không hợp lệ, phải không? Và nếu chúng ta không thể đưa ra phản hồi đúng, chúng ta nên nói điều này sớm.
2. … một lỗi xảy ra mà tôi biết là không thể khôi phục. Giả sử chúng ta có một chương trình tạo ra một hình thu nhỏ của một tệp hình ảnh được đưa ra trên dòng lệnh. Nếu tệp này không tồn tại hoặc không thể đọc được vì không đủ quyền, không có lý do gì để tiếp tục và lỗi này không thể phục hồi được. Vì vậy, chúng tôi tuân thủ các quy ước và thất bại.
3. … một lỗi xảy ra trong quá trình có thể không thể hoàn nguyên. Đây là một định nghĩa mềm, tôi biết. Hãy để tôi minh họa điều đó. Giả sử chúng ta có triển khai thực hiện cp và bắt đầu sao chép thư mục không tương tác và đệ quy. Bây giờ, giả sử chúng ta gặp phải một tệp trong thư mục đích có cùng tên (nhưng nội dung khác nhau) như một tệp được sao chép ở đó. Vì chúng tôi không thể yêu cầu người dùng quyết định phải làm gì và chúng tôi không thể sao chép tệp này, chúng tôi gặp sự cố. Bởi vì người dùng sẽ giả định rằng các thư mục nguồn và đích là các bản sao chính xác khi chúng ta kết thúc với mã thoát zero, chúng ta không thể bỏ qua tệp đang được đề cập đến. Tuy nhiên, chúng tôi không thể chỉ ghi đè lên nó, vì điều này có khả năng phá hủy thông tin.Đây là một tình huống chúng tôi không thể phục hồi từ mỗi yêu cầu rõ ràng của người sử dụng, và vì vậy tôi muốn sử dụng log.Fatal để giải thích tình hình, theo đây tuân theo nguyên tắc thất bại càng sớm càng tốt.