Kontrak yang sering digunakan untuk fungsi yang mengembalikan nilai kesalahan dari jenis antarmuka adalah bahwa penelepon tidak boleh tahu sebelumnya tentang keadaan nilai-nilai lain yang dikembalikan oleh panggilan ini tanpa terlebih dahulu memeriksa kesalahan.
Dalam kebanyakan kasus, nilai kesalahan yang dikembalikan oleh fungsi harus buram ke pemanggil. Yaitu, tes di mana kesalahannya nihil menunjukkan apakah panggilan berhasil atau gagal, dan hanya itu yang perlu Anda lakukan.
gambar dari sini
Sejumlah kecil kasus, biasanya terkait dengan interaksi dengan dunia luar, seperti aktivitas jaringan, mengharuskan penelepon untuk memeriksa sifat kesalahan untuk memutuskan apakah akan mengulangi operasi.
Persyaratan umum untuk pembuat paket adalah untuk mengembalikan kesalahan tipe publik yang diketahui sehingga pemanggil dapat menggunakan tipe menegaskan dan memeriksanya secara rinci. Saya percaya bahwa praktik ini mengarah ke sejumlah hasil yang tidak diinginkan:
- Jenis kesalahan terbuka meningkatkan "area kontak" dengan API paket.
- Implementasi baru seharusnya hanya mengembalikan tipe yang ditentukan dalam deklarasi antarmuka, bahkan jika mereka tidak cocok.
- Jenis kesalahan, setelah ditambahkan ke kode, tidak dapat diubah atau ditinggalkan tanpa merusak kompatibilitas, membuat API rapuh.
Konfirmasikan perilaku yang diharapkan, bukan tipe kesalahan
Jangan mengklaim bahwa nilai kesalahan adalah tipe tertentu, tetapi lebih baik mengklaim bahwa nilai menerapkan perilaku tertentu.
Kalimat ini konsisten dengan sifat antarmuka implisit Go, dan bukan [subtipe] dari sifat bahasa berbasis pewarisan. Pertimbangkan contoh ini:
func isTimeout(err error) bool { type timeout interface { Timeout() bool } te, ok := err.(timeout) return ok && te.Timeout() }
Penelepon dapat menggunakan isTimeout () untuk menentukan apakah kesalahan habis waktu dengan menerapkan antarmuka batas waktu, dan kemudian mengkonfirmasi apakah kesalahan telah habis waktu - semua tanpa mengetahui apa-apa tentang jenis atau sumber nilai kesalahan.
Metode ini memungkinkan untuk membungkus kesalahan, sebagai suatu peraturan, dengan perpustakaan yang menambahkan penjelasan ke jalur kesalahan; asalkan jenis kesalahan terbungkus juga menerapkan antarmuka kesalahan yang mereka bungkus.
Ini mungkin tampak seperti masalah yang tidak terpecahkan, tetapi dalam praktiknya ada beberapa metode antarmuka yang diterima secara umum, sehingga Timeout () bool dan Temporary () bool akan mencakup berbagai kasus penggunaan.
Kesimpulannya
Konfirmasikan perilaku yang diharapkan, bukan tipe kesalahan
Untuk penulis paket
Jika paket Anda menghasilkan kesalahan yang sifatnya sementara, pastikan Anda mengembalikan jenis kesalahan yang menerapkan metode antarmuka yang sesuai. Jika Anda membungkus nilai kesalahan output, pastikan pembungkus Anda mendukung antarmuka (s) dengan mana nilai kesalahan asli diimplementasikan.
Untuk pengguna paket
Jika Anda perlu memeriksa kesalahan, gunakan antarmuka untuk mengkonfirmasi perilaku yang diharapkan, bukan jenis kesalahan. Jangan tanya pembuat paket tentang tipe kesalahan terbuka; minta mereka untuk menyelaraskan tipenya dengan antarmuka umum dengan menentukan metode Timeout () atau Temporary (), yang sesuai.
Tentang penulis
Penulis artikel ini, Dave Cheney , adalah penulis banyak paket populer untuk Go, misalnya, https://github.com/pkg/errors dan https://github.com/davecheney/httpstat .
Dari penerjemah
Meskipun artikel aslinya bertanggal hingga akhir 2014, menurut saya artikel itu tidak kehilangan relevansinya. Pendekatan yang dijelaskan ditemukan dalam beberapa paket, sedangkan sisanya menggunakan pendekatan biasa untuk kesalahan.
Suntingan ke teks untuk meningkatkan kejelasan materi dipersilahkan!