Panic Recovery and Middleware Chains

Panic'dan tiklanish va middleware zanjirlari

Agar handler'ingizda kutilmagan panic yuz bersa (masalan, nil pointer'ga murojaat), butun server qulab tushmasligi kerak — faqat o'sha bitta so'rov muvaffaqiyatsiz bo'lishi kerak. Yechim — recovery middleware: defer va recover() yordamida panic'ni ushlab qolib, uni HTTP xato javobiga aylantiradigan maxsus middleware.

example.go

func RecoverMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        defer func() {
            if err := recover(); err != nil {
                w.WriteHeader(http.StatusInternalServerError)
                fmt.Fprintf(w, "recovered: %v", err)
            }
        }()
        next.ServeHTTP(w, r)
    })
}

Bu — Race Detection va Data Races darsidagi defer/recover g'oyasining HTTP kontekstidagi qo'llanilishi. Middleware'larni zanjirlash ham mumkin — bir nechta middleware'ni ichma-ich chaqirib: LoggingMiddleware(RecoverMiddleware(handler)). Bu holda so'rov avval logging orqali, keyin recovery orqali, va nihoyat asl handler'ga o'tadi — har bir qatlam o'zining bitta ishini bajaradi.

>_ Exercise

Berilgan LoggingMiddlewaredan foydalanib, RecoverMiddleware(next http.Handler) http.Handler funksiyasini yozing — u next.ServeHTTPni chaqirishdan oldin defer/recover() o'rnatadi; panic bo'lsa, http.StatusInternalServerError (500) va "recovered: <xabar>" javobini yozadi. mainda doim panic qiladigan handler'ni LoggingMiddleware(RecoverMiddleware(...)) bilan zanjirlab sinang.

Stuck? Reveal a hint to help you.

Hints (0/4)

Key Takeaway

Key Takeaway:

defer/recover() middleware ichida qo'llanilganda, bitta so'rovdagi panic butun serverni yiqitmaydi — faqat o'sha so'rov xato javobi bilan tugaydi. Middleware'larni ichma-ich chaqirib zanjirlash, har birini alohida, kichik va sinaladigan qilib saqlaydi.

NEXT UP

Testing HTTP Handlers

OUTPUT

$ go run main.go
Kodingizni ishga tushiring