Banyak project Laravel terlihat baik-baik saja sampai mulai menerima data yang tidak terduga atau integrasi pihak ketiga tiba-tiba gagal. Saat itu, cara kita menangani error akan jauh lebih penting daripada sekadar menampilkan pesan generik.
Logging yang tepat bukan berarti membanjiri file log dengan semua hal. Yang dibutuhkan adalah konteks yang cukup untuk menjawab apa yang gagal, di mana, dan apa dampaknya bagi pengguna.
Kelompokkan error berdasarkan sumber masalah
Saya biasanya mulai dengan mengelompokkan error berdasarkan sumbernya: validasi, business rule, external service, atau bug internal. Dengan pemetaan ini, keputusan respons API maupun tampilan error page jadi lebih konsisten.
Laravel sudah memberi fondasi kuat lewat exception handler. Tinggal pastikan kita tidak langsung melempar semua error ke user tanpa konteks yang bisa mereka pahami.
Empat sumber error yang paling sering muncul
- Error input user.
- Error dari aturan bisnis aplikasi.
- Error dari service eksternal seperti payment atau email.
- Error internal karena bug yang memang harus diperbaiki.
Bangun log yang bisa ditindaklanjuti
Log yang baik selalu punya identitas request atau resource yang sedang diproses. Dengan begitu, saat ada laporan gagal submit atau sinkronisasi tidak berjalan, kita bisa menelusuri jejaknya tanpa menebak-nebak.
Saya menghindari log yang berisi data sensitif mentah. Cukup simpan ID, state, dan ringkasan error yang aman untuk lingkungan produksi.
Pisahkan UX error dari detail teknis
Untuk pengguna akhir, pesan yang singkat dan manusiawi jauh lebih berguna dibanding stack trace atau istilah teknis. Beri tahu bahwa proses gagal, apa yang bisa dicoba ulang, dan kapan mereka perlu menghubungi tim.
Di sisi developer, detail tetap tersedia di log atau monitoring. Pola ini membuat aplikasi tetap profesional sambil tetap mudah di-debug.
Pesan untuk user harus menenangkan. Detail untuk developer harus menjelaskan.