Không app nào sống sót sau lần tiếp xúc thực tế với user. Khi người dùng bắt đầu dùng, họ sẽ gặp lỗi.
Vì vậy, production app thường có cách track và report error. Bạn có thể đơn giản với exception_notification hoặc webapp như Honeybadger, Raygun.
Nhưng sớm muộn, bạn thấy cùng vài exception lặp lại. Có thể web service phụ thuộc không ổn. Hoặc user typo email, message không đi. Exception nên exceptional, nên unexpected. Nhưng lỗi bất ngờ như nào nếu thấy nó ba mươi lần một ngày?
Có cách giải quyết tốt hơn report và ignore. Hầu hết noisy exception rơi vào vài category cơ bản. Với mỗi category, dùng pattern cắt noise, làm user hạnh phúc hơn.
Mạng bị sập!
Ít app làm việc đơn độc. Phần lớn giao tiếp app khác. Nhưng khi geolocation API down hoặc ec2 hiccup, bạn không muốn bị spam ngàn exception không làm gì được.
Khi deal với service không tin cậy, thử pattern Circuit Breaker, từ Release It của Michael Nygard:
Ý tưởng cơ bản circuit breaker rất đơn giản. Bạn wrap function call được bảo vệ trong object circuit breaker, monitor failure. Khi failure đạt ngưỡng, breaker trip, mọi call sau trả error ngay, không gọi protected function.
Vậy, khi service down, bạn tự động ngừng kết nối. Chạy tiếp không có chức năng đó. Có thể self-healing, app tự check service lại sau thời gian.
Circuit breaker pattern thiết kế ngăn cascading failure, nhưng cũng dùng để limit exception notification. Với pattern này, chỉ cần notify khi trip và khi fail recover. Biến ngàn exception thành vài cái. Nếu vẫn nhiều, config breaker chỉ report sau vài retry fail liên tiếp. (Hoặc tìm service tin cậy hơn!)
Dùng pattern này tốn công, nhưng cũng làm trải nghiệm user tốt hơn. Thay vì hard error page, user thấy message tính năng này không hoạt động, thử lại sau. Thông tin tốt hơn, đúng lúc.
Rốt ra gmaaaail.com không phải ý bạn
Loại exception thường thấy khác từ bad user data.
Ví dụ, ai typo email khi signup. Nói "justinweiss@gmaill.com", nhưng ý "justinweiss@gmail.com". Thứ nhất theoretically valid email, nhưng mail gửi bounce. Bạn được notify bounce bởi email provider.
Những notification chỉ là noise.
Thay vào đó, lấy hai phía. Ngăn bad data upfront, và disable feature + notify user nếu fail sau.
Với email, tôi dùng mailcheck-js gem spellcheck "gmail.com", "yahoo.com" khi user mới đăng ký:
{% img img-responsive /images/posts/email-spellcheck.gif 477 451 Ooh, fancy. %}
Rồi, nếu email vẫn bounce sau, tắt email cho user đó.
Khi tắt feature cho ai, cũng phải báo cho họ biết disable và cách fix. Banner top site thường tốt. Tipo "Chúng tôi không gửi được email gần đây, đã tắt gửi email cho bạn. Click đây cập nhật email, chúng tôi bật ngay."
Bạn có data tốt hơn, và email user không bay vào hư vô. Tốt hơn error bạn bỏ qua.
404 và RoutingError
Bạn có thể muốn biết broken link hoặc asset trên site. Nhưng chúng không thuộc exception tracker.
Với những "half-expected errors" này, gom lại xử lý một lần. Không cần notify realtime. Bạn muốn pull, không phải push.
RoutingError và 404 xử lý bằng Google Webmaster Tools, show page Google biết ném 404. Hoặc chạy link-checker check link site trong pre-release process.
Exception nên actionable
Email exception nên hiếm. Quá nhiều noise error tracker làm bạn miss real problem.
Nếu bạn bị annoyed hơn embarrassed về exception thấy, bạn có noise problem. Dùng pattern đây cắt noise, cải thiện trải nghiệm user cùng lúc.
Tôi nói vài category noisy exception thường thấy. Nhưng chắc chưa thấy hết. Exception nào làm bạn khổ nhất? Chúng fit category này, hay định nghĩa category mới? Bạn ngăn chúng phiền bạn hàng trăm lần/ngày như thế nào?