Pengendalian Ralat Berpusatkan Pelanggan

Memahami dan Mengendalikan Ralat

Untuk mengendalikan ralat dengan berkesan, adalah penting untuk memahami jenis ralat yang boleh berlaku. Mari mulakan dengan mengkategorikan ralat yang mungkin anda hadapi.

Jenis Ralat dalam Persekitaran Pelanggan Web

Ralat Rangkaian

• Isu Sambungan: Masalah dengan mewujudkan sambungan ke pelayan.
• Tamat masa: Permintaan mengambil masa terlalu lama untuk menerima balasan.
• Ralat DNS: Isu dengan resolusi nama domain.
• Ralat HTTP: Ralat seperti 404 Not Found, 500 Internal Server Error, dll.

Ralat API Pelayan

• Respons Tidak Sah: Data yang tidak dijangka atau salah bentuk daripada pelayan.
• Ralat Pengesahan: Isu dengan pengesahan atau kebenaran pengguna.
• Penghadan Kadar: Sekatan kerana melebihi had penggunaan API.

Ralat Persekitaran Pelayar Pengguna

• Keserasian Penyemak Imbas: Isu yang timbul daripada perbezaan dalam cara penyemak imbas mengendalikan ciri tertentu.
• Ralat JavaScript: Ralat dalam kod JavaScript sisi pelanggan.
• Ralat Memuatkan Sumber: Masalah memuatkan sumber seperti imej, skrip atau helaian gaya.

Kesilapan Lain

• Ralat Sisi Pelanggan: Ralat yang berkaitan dengan peranti atau sistem pengendalian pengguna.
• Ralat UI/UX: Isu dengan antara muka pengguna atau pengalaman pengguna, seperti pautan rosak atau reka letak yang salah.

Pelbagai jenis ralat boleh berlaku. Walau bagaimanapun, ralat ini secara amnya boleh dikelaskan kepada dua kategori:

1. Ralat Yang Dijangka: Ralat di mana kejadian dan sifatnya diketahui lebih awal.
2. Ralat Tidak Dijangka: Ralat di mana kejadian dan sifatnya tidak diketahui terlebih dahulu.

Mari kategorikan ralat yang telah kita bincangkan ke dalam klasifikasi ini.

Adakah kesilapan itu boleh dijangka atau tidak?

Kesilapan yang Dijangka

Ralat yang diterima daripada API pelayan dengan kod status yang jelas boleh dipertimbangkan Ralat Jangkaan kerana ia boleh dijangka dan ditangani lebih awal.

Sebagai contoh, ralat seperti akses tanpa kebenaran (401) atau akses terlarang (403) boleh dikendalikan dengan sewajarnya berdasarkan situasi. Ia juga biasa untuk menentukan kod ralat yang lebih terperinci untuk setiap kod status untuk mengurus logik aplikasi sebagai tindak balas kepada ralat. Ini dirujuk sebagai Ralat Jangkaan.

Ralat Tidak Dijangka

Sebaliknya, ralat pelayan dalam julat 500 diklasifikasikan sebagai Ralat Tidak Dijangka kerana ia tidak dapat diramalkan. Situasi di mana pelayan tidak dapat bertindak balas atas sebarang sebab boleh berlaku pada bila-bila masa. Selain itu, ralat yang mungkin timbul disebabkan oleh persekitaran rangkaian pengguna atau persekitaran penyemak imbas sukar untuk diramal dan oleh itu diklasifikasikan sebagai Ralat Tidak Dijangka.

Pengguna dan Ralat

Ralat juga boleh dikelaskan berdasarkan interaksi dengan pengguna, bukan hanya persekitaran. Satu cara untuk mengkategorikan ralat adalah dengan mempertimbangkan sama ada pengguna boleh melakukan sesuatu tentang ralat tersebut. Berikut ialah kriteria untuk pengelasan ini:

1. Ralat yang boleh difahami dan diselesaikan oleh pengguna (Ralat yang membantu pengguna terus menggunakan aplikasi).
2. Ralat yang tidak dapat diselesaikan oleh pengguna (Ralat yang tidak memberikan bantuan kepada pengguna).

Kesilapan Boleh Selesaikan

Sebagai contoh, ralat pengesahan atau kebenaran termasuk dalam kategori ini. Pengguna yang tidak log masuk mungkin menghadapi ralat status 401. Dalam kes ini, anda boleh menyediakan skrin log masuk atau memaparkan mesej yang menunjukkan log masuk diperlukan.

Jika pengguna tidak mempunyai kebenaran untuk mengakses skrin tertentu, anda boleh membimbing mereka untuk meminta akses daripada pentadbir.

Tiada pembangun produk mengalu-alukan pengabaian pengguna. Adalah penting untuk memberikan panduan kepada pengguna yang menghadapi ralat untuk membantu mereka mengatasi situasi tersebut. Contohnya, menyediakan butang muat semula untuk ralat rangkaian sementara atau butang untuk menavigasi kembali ke skrin sebelumnya apabila mengakses halaman yang tidak wujud.

Kesilapan Tidak Boleh Selesaikan

Walau bagaimanapun, terdapat kes di mana memaklumkan pengguna tentang situasi ralat tidak membantu sama sekali. Contohnya, jika kod tersebut termasuk komponen yang tidak berfungsi pada peranti atau penyemak imbas berspesifikasi rendah, pengguna tidak boleh berbuat apa-apa mengenainya. (Mungkin mesej yang mencadangkan penggunaan penyemak imbas yang berbeza?)

Kedua-dua kes, 1 dan 2, melibatkan penyediaan mesej. Perbezaannya ialah kes 1 termasuk beberapa tindakan atau panduan yang menggesa pengguna untuk mengambil langkah.

Adakah ralat yang dihadapi sesuatu yang pengguna boleh selesaikan sendiri atau tidak?

Cara Mengendalikan Ralat

Jadi, bagaimanakah kita harus menangani ralat yang berlaku? Apakah jenis antara muka yang perlu disediakan oleh aplikasi kepada pengguna apabila ralat berlaku? Mari kita terokai cara menangani pelbagai jenis ralat berdasarkan ciri-cirinya.

Ralat yang tidak dapat diramalkan tetapi boleh diselesaikan

Contoh biasa ialah ralat rangkaian. Ini boleh berlaku pada bila-bila masa bergantung pada persekitaran rangkaian pengguna. Penyelesaian paling mudah ialah memaklumkan pengguna bahawa ia adalah 'ralat sementara' dan memberikan panduan untuk mencuba semula tindakan sebelumnya.

Julat ralat

Untuk ralat ini, adalah penting untuk memastikan bahawa aplikasi secara keseluruhan tidak terjejas. Sebagai contoh, jika aplikasi memanggil 10 API pada satu skrin, gagal tidak seharusnya mencetuskan mesej ralat merentas keseluruhan aplikasi dan memerlukan percubaan semula semua panggilan.

Sebaliknya, fokus pada memulihkan hanya kawasan yang gagal.

Ralat yang tidak dapat diramal dan tidak dapat diselesaikan

Ini adalah ralat yang sukar dijangka dan tidak mempunyai penyelesaian yang jelas. Ralat sedemikian harus diminimumkan semasa pembangunan, dan perlu ada rancangan untuk mengendalikannya apabila ia berlaku. Memandangkan pengguna tidak dapat menyelesaikan sendiri ralat ini, menyediakan cara mudah untuk menghubungi sokongan pelanggan mungkin diperlukan.

Pemantauan

Ralat di luar kawalan pembangun harus dipantau menggunakan alatan seperti Sentry. Ralat ini perlu diperbaiki untuk mengelakkan pengguna daripada menghadapinya. Selain itu, pastikan terdapat mekanisme untuk pengguna kembali ke aplikasi jika mereka menghadapi ralat sedemikian.

Ralat yang boleh diramal tetapi tidak boleh diselesaikan

Ini adalah ralat yang diketahui yang tiada penyelesaian tersedia untuk pengguna. Jika pengguna tidak dapat menyelesaikannya sendiri, ini menunjukkan peluang yang terlepas untuk pengendalian ralat. Jika pengguna sengaja melakukan tindakan yang tidak normal, ini boleh menjadi tanda kelemahan keselamatan.

Ralat Berkaitan Keselamatan

Ralat ini berlaku apabila terdapat niat jahat untuk mengeksploitasi aplikasi. Ia biasanya berpunca daripada kelemahan keselamatan dan harus dicegah semasa pembangunan. Adalah penting untuk menangani kebimbangan asas keselamatan seperti CORS dan XSS dan bekerjasama dengan pasukan keselamatan untuk membina aplikasi selamat.

Ralat Boleh Diramal dan Boleh Selesaikan

Ralat ini biasanya sebahagian daripada logik perniagaan yang sudah diketahui oleh pembangun:

• 401 Ralat Tanpa Kebenaran: Memerlukan log masuk.
• Ralat 404 Tidak Ditemui: Mengakses halaman yang salah.
• Ralat logik perniagaan lain: Ditakrifkan oleh logik aplikasi.

Dalam kes ini, berikan panduan yang sesuai dalam aplikasi atau buat halaman berasingan untuk mengarahkan pengguna.

Kepentingan Bimbingan

Pengguna harus memahami dengan jelas perkara yang perlu dilakukan seterusnya selepas menemui mesej ralat. Ini membantu mengurangkan kekerapan ralat dan menghalang pengabaian pengguna. Oleh itu, di samping mesej ralat, adalah penting untuk menyertakan seruan untuk bertindak.

Sebagai contoh, jika terdapat ralat pengesahan medan, fokus pada medan tempat ralat itu berlaku. Jika pengguna menavigasi ke halaman yang tidak wujud, sediakan butang untuk kembali ke skrin sebelumnya.

Kesimpulan

Kami meneroka pengendalian ralat. Mari kita urus ralat dengan cekap dengan menggunakan pelbagai alatan dan teknologi seperti alat pemantauan ralat dan React's ErrorBoundary, yang boleh menangkap ralat dalam skop yang terhad.

Atas ialah kandungan terperinci Pengendalian Ralat Berpusatkan Pelanggan. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!