Praktik Terbaik Untuk Membuat Pola Kode Kesalahan Untuk Proyek Perusahaan di C # [ditutup]

Saya sedang mengerjakan proyek perusahaan yang akan digunakan di banyak UKM dan Perusahaan.
Dukungan untuk proyek ini akan sulit dan saya ingin membuat pola pengkodean untuk kesalahan ( Seperti Kode status HTTP ). Ini akan memungkinkan orang meja bantuan untuk merujuk ke dokumen dan memecahkan masalah secepat mungkin.

Apa praktik terbaik dan rekomendasi untuk melakukan ini?
Bantuan apa pun untuk melakukan ini akan bermanfaat.

c# programming-practices error-handling enterprise-development

— Pooya
sumber

Ada terlalu banyak kemungkinan jawaban, atau jawaban yang bagus akan terlalu panjang untuk format ini. Harap tambahkan detail untuk mempersempit set jawaban atau untuk mengisolasi masalah yang dapat dijawab dalam beberapa paragraf. Dan apa yang sudah Anda coba sejauh ini.

— Ben McDougall

Tergantung pada bagaimana bisnis Anda terstruktur. Dalam C # kami selalu memberi pengguna kemungkinan untuk mengirimi kami StackTrace atau menyalin / menempelnya dari detail pesan kesalahan (kami tidak memiliki persyaratan keamanan yang ketat).

— Falcon

Jawaban:

Ada perbedaan antara kode kesalahan dan nilai pengembalian kesalahan. Kode kesalahan adalah untuk pengguna dan help desk. Nilai pengembalian kesalahan adalah teknik pengkodean untuk menunjukkan bahwa kode Anda mengalami kesalahan.

Seseorang dapat menerapkan kode kesalahan menggunakan nilai-nilai pengembalian kesalahan, tetapi saya akan menyarankan menentang itu. Pengecualian adalah cara modern untuk melaporkan kesalahan, dan tidak ada alasan mengapa mereka tidak boleh membawa kode kesalahan di dalamnya.

Ini adalah bagaimana saya mengaturnya (Perhatikan bahwa poin 2-6 adalah agnostik bahasa):

Gunakan jenis pengecualian khusus dengan ErrorCodeproperti tambahan . Tangkapan di loop utama akan melaporkan bidang ini dengan cara biasa (file log / error pop-up / error reply). Gunakan tipe pengecualian yang sama di semua kode Anda.
Jangan mulai dari 1 dan jangan gunakan angka nol di depan. Simpan semua kode kesalahan dengan panjang yang sama, sehingga kode kesalahan yang salah mudah dikenali. Mulai 1000 biasanya cukup baik. Mungkin menambahkan 'E' terkemuka untuk membuat mereka dapat diidentifikasi dengan jelas untuk pengguna (terutama berguna ketika meja dukungan harus menginstruksikan pengguna cara menemukan kode kesalahan).
Simpan daftar semua kode kesalahan, tetapi jangan lakukan ini di kode Anda . Simpan daftar pendek di halaman wiki untuk pengembang, yang dapat dengan mudah diedit ketika mereka membutuhkan kode baru. Help desk harus memiliki daftar terpisah di wiki mereka sendiri.
Jangan mencoba menegakkan struktur pada kode kesalahan. Akan selalu ada kesalahan yang sulit untuk diklasifikasi dan Anda tidak ingin berdiskusi berjam-jam apakah kesalahan harus dalam kelompok 45xx atau dalam kelompok 54xx. Bersikap pragmatis .
Tetapkan setiap lemparan dalam kode Anda kode yang terpisah. Meskipun Anda pikir itu penyebab yang sama, help desk mungkin perlu melakukan hal yang berbeda dalam kasus yang berbeda. Lebih mudah bagi mereka untuk memiliki "E1234: Lihat E1235" di wiki mereka, daripada membuat pengguna mengakui kesalahannya.
Pisahkan kode kesalahan jika help desk memintanya. if (...) throw new FooException(1234, ".."); else throw new FooException(1235, "..");Baris sederhana dalam kode Anda mungkin menghemat setengah jam untuk help desk.

Dan jangan pernah lupa bahwa tujuan kode kesalahan adalah untuk membuat hidup lebih mudah untuk help desk .

— Sjoerd
sumber

Saya belum pernah melakukan ini secara pribadi, tetapi seringkali Anda melihat "id korelasi" juga, panduan spesifik-contoh-kesalahan yang ditampilkan kepada pengguna dan juga dicatat. Dengan begitu, Anda dapat lebih mudah menemukan kesalahan yang terjadi di log, lebih mudah daripada dengan perkiraan waktu dan kode kesalahan.

— xdhmoore

Saya kira mungkin ada cara untuk memasukkan kode kesalahan dalam id korelasi sehingga dapat berfungsi sebagai kode kesalahan yang dapat dibaca manusia untuk help desk dan sebagai id contoh kesalahan untuk pengembang.

— xdhmoore

Pola saya sangat mirip. Tetapi alih-alih "E", saya menambahkan sedikit bagian-aplikasi. Kerangka kerja dokumentasi kami memiliki misalnya, Doc1234sementara Main-App dapat memiliki IrS1234. Jadi rekan kerja-pembantu saya cukup cepat dengan membantu pengguna saya.

— Matthias Burger

Pertama-tama Anda harus mengisolasi area di mana kesalahan mungkin terjadi, dan dapat dilihat pengguna. Kemudian Anda dapat mendokumentasikannya. Sesederhana itu.

Yah, sederhana dalam teori .. dalam praktiknya kesalahan dapat terjadi di seluruh tempat sialan, dan melaporkannya dapat mengubah kode yang bagus menjadi monster logging, pengecualian melempar dan menangani, dan meneruskan nilai kembali.

Saya akan merekomendasikan pendekatan 2 langkah. Pertama adalah mencatat, mencatat banyak dan banyak.

Kedua adalah menentukan komponen utama dan antarmuka mereka, dan untuk menentukan kasus kesalahan utama apa yang dapat ditemukan komponen-komponen ini. Anda kemudian dapat masuk dengan cara yang lebih terlihat ketika salah satu dari kesalahan ini (bagaimana Anda menangani kesalahan secara internal terserah Anda. - pengecualian atau kode kesalahan tidak ada bedanya di sini). Seorang pengguna biasanya akan melihat kesalahan dan pergi ke log untuk informasi lebih rinci.

Pendekatan yang sama digunakan untuk server web dan contoh kode kesalahan http Anda. Jika pengguna melihat 404, dan melaporkannya untuk mendukung, mereka akan mencari di log untuk rincian apa yang sedang terjadi, halaman mana yang dikunjungi, kapan, dan akan mengumpulkan informasi lain yang mereka dapat dari mana pun masuk akal , berada di DB, jaringan atau aplikasi.

— gbjbaanb
sumber

Saya akan pergi untuk pengecualian khusus dengan nama deskriptif dan pesan yang jelas dan membuangnya. Jauh lebih mudah untuk menggunakan infrastruktur pengecualian bahasa yang ada daripada membangun dukungan untuk melewati kode kesalahan dan menafsirkannya.

— Stefan Billiet
sumber

Saya akan menghargai orang yang menurunkan jawaban ini dari 1 menjadi 0 untuk setidaknya memberikan alasan ...

— Stefan Billiet

bukan saya downvoting (bukan itu penting, lupakan saja), tapi saya pikir ada dukungan yang ada untuk nilai kembali dalam bahasa juga.

— gbjbaanb

Itu penting bagi saya; jika saya salah, saya ingin tahu sehingga saya bisa belajar :-p Bagaimana maksud Anda, dukungan yang ada untuk nilai kembali? Tidakkah Anda harus menulis plumbing untuk membedakan nilai pengembalian normal dari kode kesalahan? Menerjemahkan pengecualian ke kode kesalahan pada batas suatu sistem adalah satu hal, tetapi menyulapnya di dalam sistem Anda adalah sesuatu yang umumnya tidak disarankan. Saya percaya The Pragmatic Programmer menyebutkan hal semacam ini.

— Stefan Billiet

pengecualian bukanlah mekanisme yang baik dalam setiap kasus, tetapi jika Anda memutuskan untuk menggunakan kesalahan, Anda bisa menambahkan param ke setiap panggilan, atau membuat panggilan penting semua mengembalikan kode. Putuskan di muka untuk melakukan itu, dan Anda adalah emas. Secara pragmatis, Anda berakhir dengan campuran dua kode kesalahan yang kembali pada batas (sehingga Anda tidak dikunci ke dalam satu bahasa) dan menggunakan pengecualian secara internal.

— gbjbaanb

Saya tidak memilih Anda (tenang saja, kalau tidak semua orang harus mengulang ini :). Jika Anda pernah bekerja atau menelepon di meja layanan, jauh lebih mudah untuk berkomunikasi dengan nomor pendek daripada pesan kesalahan. Pesan kesalahan dijamin akan berubah ketika itu disampaikan secara lisan.

— Codism