Saya sentiasa menjadi peminat tegar kedua-dua Rust dan GoLang. Pendekatan mereka terhadap pengaturcaraan, terutamanya dalam pengendalian ralat, telah bergema dengan saya sepanjang kerjaya saya. Selepas mendedikasikan lebih daripada empat tahun untuk pembangunan GoLang, saya baru-baru ini beralih kepada projek di mana saya memfaktorkan semula kod PHP legasi kepada versi yang lebih baharu dan lebih mantap. Peralihan ini sangat menarik dan mencabar, terutamanya apabila menyesuaikan diri dengan mekanisme pengendalian ralat tradisional PHP.
Setelah membiasakan diri dengan konsep "kesilapan sebagai nilai" Go, beralih kembali kepada bahasa yang bergantung pada paradigma try-catch konvensional telah menjadi pelarasan yang ketara. Idea untuk mengharapkan perkara yang tidak dijangka melalui pengecualian terasa berlawanan dengan intuitif. Dalam GoLang, ralat dianggap sebagai nilai pulangan eksplisit yang boleh dihasilkan oleh fungsi, memerlukan pembangun mengendalikannya secara langsung. Kejelasan ini menggalakkan kejelasan dan menggalakkan pemeriksaan ralat menyeluruh pada setiap panggilan fungsi.
Sebaliknya, pengendalian ralat berasaskan pengecualian kadangkala boleh menyebabkan kes kelebihan yang diabaikan. Anda boleh memanggil fungsi yang mengeluarkan pengecualian dan hanya menemui pengawasan dalam pengeluaran apabila aplikasi menyebabkan senario ranap yang perlu dielakkan oleh setiap pembangun.
Untuk menangani cabaran ini, saya memutuskan untuk memperkenalkan jenis Hasil yang diilhamkan oleh Rust dalam kaedah pengawal PHP saya. Pendekatan Rust terhadap pengendalian ralat, sama seperti Go, menekankan pemulangan hasil yang secara eksplisit menunjukkan kejayaan atau kegagalan. Dengan melaksanakan jenis Hasil dalam PHP, saya berhasrat untuk membawa tahap eksplisit dan keselamatan ini kepada projek semasa saya.
Sebagai contoh, dalam titik akhir pendaftaran pengguna, saya membungkus pengesah Laravel untuk mengembalikan Keputusan yang mengandungi sama ada nilai yang sah atau ralat. Pengubahsuaian ini membolehkan saya mengendalikan kegagalan pengesahan secara eksplisit, membolehkan aplikasi mengembalikan kod status 422 Entiti Tidak Dapat Diproses apabila sesuai. Ini bukan sahaja menjadikan pengendalian ralat lebih telus, tetapi ia juga meningkatkan kebolehpercayaan API dengan memastikan semua kemungkinan ralat diambil kira dan diurus dengan betul.
Berikut ialah beberapa faedah utama yang saya perhatikan daripada pendekatan ini:
Untuk memberikan gambaran yang lebih jelas tentang metodologi ini, saya telah menyediakan tiga contoh kod untuk menyerlahkan kontras dan persamaan antara bahasa dan mempamerkan cara penggunaan corak tertentu boleh membawa kepada kod yang lebih mantap dan boleh diselenggara.
Saya ingin tahu pendapat anda tentang pendekatan ini. Adakah anda fikir menggabungkan konsep daripada satu bahasa ke bahasa lain bermanfaat dalam jangka masa panjang?
Jangan ragu untuk berkongsi pengalaman anda atau bertanya sebarang soalan.
Atas ialah kandungan terperinci Result