Tentu kalian mungkin sudah cukup familiar dengan cara membuat error code, namun sebenarnya, apa sih itu error code handling?
Error handling bisa dibilang adalah sebuah antisipasi, deteksi, dan resolusi dari sebuah pemrograman. Kemungkinan-kemungkinan kode yang menghasilkan error harus ditangani sehingga error tidak menyebabkan tertutupnya sebuah program melainkan memberikan informasi error tersebut kepada user melalui media seperti response atau log file. Pada website allocateam, kita melakukan handling error code dengan memberikan response pada user dari backend, dengan informasi berupa masalah yang terjadi dan kode error.
Ternyata, walau implementasi dasar dari error handling cukup sederhana, implementasi pembuatan error code yang mencakup semua kemungkinan (termasuk kemungkinan buruk) pada skala pengembangan software sangat sulit dan membosankan. Bukan karena banyak error code yang harus dibuat, namun karena membuat kode yang error-free merupakan suatu hal yang sulit.
Perspektif:
Allocateam membuat banyak sekali error code handling hingga berusaha membuat error code sendiri agar dapat memberikan pengguna umpan balik yang lebih baik dengan error code yang telah dibuat sedemikian menyesuaikan aplikasi. Namun, apakah penting untuk membuat error code sendiri dan memikirkan seluruh kemungkinan error yang akan terjadi pada suatu program? Bagi kami ya, bagi beberapa orang ya, namun terdapat referensi menarik dari Joel Spolsky, CEO dari Stack Overflow dan Raymond Chen, pengembang dari Microsoft.
Joel Spolsky
Joel tidak menyukai melakukan pemrograman menggunakan exception (hal yang allocateam lakukan). Prinsip dia adalah:
1. Tidak pernah melempar exception secara manual.
2. Selalu tangkap exception yang diberikan library dan tangani langsung secepatnya.
Mengapa? Dia bilang bahwa exception lebih buruk daripada goto (dikatakan buruk sejak 1960an karena tingkah lakunya yang dapat melompat-lompati baris kode) karena:
Mereka tidak terlihat pada source code. Jika melihat dari sebuah blok kode, termasuk fungsi yang mungkin melemparkan exception, tidak ada cara untuk melihat exception mana yang akan dilempar dan darimana. Ini berarti bahkan kode yang telah diinspeksi sedemikian rupa tetap tidak dapat memperlihatkan potensi-potensi dari terjadinya bug.
Mereka membuat terlalu banyak kemungkinan exit point dari sebuah fungsi. Untuk membuat kode yang bedar, kita harus memikirkan semua kemungkinan dari alur kode yang melewati fungsi yang telah dibuat. Setiap kali fungsi dipanggil dan berkemungkinan melemparkan exception dan tidak ditangkap langsung ditempatnya akan berpotensi menciptakan bug yang tidak terduga dari fungsi yang terhenti secara absurd, meninggalkan data pada state yang tidak konsisten atau jalur kode lain yang tidak terpikirkan.
Walau demikian, Joel memberikan alternatif yang menurutnya lebih baik, yaitu, membuat fungsi mengembalikan error value ketika hal buruk terjadi, dan menghadapinya secara eksplisit, tidak peduli walaupun serumit apapun. Menurutnya, kebanyakan pemrogram C/C++/Java tertarik untuk melemparkan exception hanya karena sintaks pemrograman tersebut tidak memiliki cara yang ringkas untuk memanggil fungsi yang mengembalikan banyak kembalian, jadi cukup sulit untuk menulis fungsi yang mengembalikan return value atau mengembalikan error. Pada C/C++/Java, satu cara yang dapat dilakukan untuk menangani error adalah dengan menggunakan return value yang sebenarnya untuk mengembalikan status hasil dan jika terdapat hal lain yang ingin dikembalikan, maka gunakan parameter OUT untuk melakukan itu. Hal tersebut sangat disayangkan karena efek sampingnya adalah ketidakmungkinan untuk melakukan nest function calls, sehingga result = f(g(x)) harus menjadi:
T tmp;
if (ERROR == g(x, tmp))
errorhandling;
if (ERROR == f(tmp, result))
errorhandling;
Hal tersebut sangat jelek dan mengganggu, namun lebih baik daripada membuat goto ajaib yang tidak terduga muncul di kode kita pada tempat-tempat yang juga tidak terduga.
Raymond Chen
Pada artikelnya, dia mereferensikan code snippet dari sebuah buku dimana sang pembuat melakukan klaim bahwa kode yang dia berikan adalah "clean and more elegant" namun Chen berkata bahwa kode tersebut bukan hanya bersih dan elegan, tetapi juga salah (yup salah).
Chen berkata bahwa kita bisa saja membuat exception-based programming, namun dia memperingatkan bahwa itu sangatlah sulit. Namun, dengan kata lain, walau sulit, tidak berarti hal tersebut tidak dapat dikerjakan.
Sangat mudah untuk membuat bad code, bagaimanapun error model yang dipilih.
Sulit untuk membuat kode yang error-code-based karena kita harus memikirkan aksi dari semua kemungkinan error yang akan terjadi.
Sangatlah sulit untuk membuat kode yang exception-based karena kita harus melakukan pengecekan pada setiap baris kode (setiap baris ekspresi) dan memikirkan tentang bagaimana sebuah exception mungkin dilemparkan dan bagaimana kita bereaksi dengan hal itu. Terutama pada pemrograman Python atau C# dimana exception dapat dilemparkan kapan saja.
Poin yang ingin disampaikan oleh Chen adalah, bukan berarti exception itu buruk, namun membuat exception sangatlah sulit dan dia menganggap dirinya tidak cukup cerdas untuk menanganinya (dan bahkan seorang penulis, yang berusaha mengajarkan cara memprogram dengan exception).
Nah teman-teman, diatas merupakan beberapa pendapat dari orang-orang yang cukup terkenal yang kontra terhadap exception-based programming. Joel mengatakan exception itu buruk, sedangkan Chen tidak merekomendasikannya karena sulit. Cukup menarik bukan? Ternyata pada skala industri, exception yang kita pelajari pada awal semester, tidak semudah yang dibayangkan. Sampai jumpa lagi di pembahasan literatur menarik lainnya ya!
Jangan lupa untuk membaca lebih lengkap blog mereka:
0 komentar:
Post a Comment