Apa masalah pengembang dengan pesan kesalahan bermanfaat? [Tutup]

29

Terus mengejutkan saya bahwa, di zaman sekarang ini, produk-produk yang telah bertahun-tahun digunakan di bawah ikat pinggang mereka, dibangun oleh tim profesional, masih sampai hari ini - gagal memberikan pesan kesalahan yang bermanfaat kepada pengguna. Dalam beberapa kasus, penambahan sedikit informasi tambahan dapat menghemat waktu pengguna.

Program yang menghasilkan kesalahan, membuatnya karena suatu alasan. Ia memiliki segalanya untuk menginformasikan pengguna sebanyak mungkin, mengapa sesuatu gagal. Namun tampaknya memberikan informasi untuk membantu pengguna adalah prioritas rendah. Saya pikir ini adalah kegagalan besar.

Salah satu contohnya adalah dari SQL Server. Ketika Anda mencoba dan mengembalikan database yang sedang digunakan, itu benar tidak akan membiarkan Anda. SQL Server tahu proses dan aplikasi apa yang mengaksesnya. Mengapa tidak bisa memasukkan informasi tentang proses yang menggunakan database? Saya tahu tidak semua orang memberikan Applicatio_Nameatribut pada string koneksi mereka, tetapi bahkan petunjuk tentang mesin tersebut dapat membantu.

Kandidat lain, juga SQL Server (dan mySQL) adalah string or binary data would be truncatedpesan kesalahan yang indah dan setara. Banyak waktu, teliti pernyataan SQL yang dihasilkan dan tabel menunjukkan kolom mana yang menjadi biang keladinya. Ini tidak selalu terjadi, dan jika mesin database mengambil kesalahan, mengapa itu tidak bisa menyelamatkan kita saat itu dan hanya memberi tahu kita kolom terkutuk itu? Pada contoh ini, Anda dapat berargumen bahwa mungkin ada hit kinerja untuk memeriksanya dan bahwa ini akan menghalangi penulis. Baik, saya akan membelinya. Bagaimana, setelah mesin basis data tahu ada kesalahan, ia melakukan perbandingan cepat setelah fakta, antara nilai-nilai yang akan disimpan, versus panjang kolom. Kemudian tampilkan itu ke pengguna.

ASP.NET, Table Adapters juga bersalah. Kueri dapat dieksekusi dan satu dapat diberikan pesan kesalahan yang mengatakan bahwa suatu kendala di suatu tempat dilanggar. Terima kasih untuk itu. Saatnya membandingkan model data saya dengan basis data, karena pengembang terlalu malas untuk memberikan bahkan nomor baris, atau contoh data. (Sebagai catatan, saya tidak akan pernah menggunakan metode akses data ini karena pilihan , itu hanya proyek yang saya warisi!).

Setiap kali saya melemparkan pengecualian dari kode C # atau C ++ saya, saya memberikan semua yang saya miliki kepada pengguna. Keputusan telah dibuat untuk membuangnya, sehingga semakin banyak informasi yang dapat saya berikan, semakin baik. Mengapa fungsi saya membuang pengecualian? Apa yang diteruskan, dan apa yang diharapkan? Hanya perlu waktu sedikit lebih lama bagi saya untuk memasukkan sesuatu yang bermakna ke dalam tubuh pesan pengecualian. Sial, itu tidak membantu saya sementara saya berkembang, karena saya tahu kode saya melempar hal-hal yang bermakna.

Orang dapat berpendapat bahwa pesan pengecualian yang rumit tidak boleh ditampilkan kepada pengguna. Sementara saya tidak setuju dengan itu, itu adalah argumen yang dapat dengan mudah diredakan dengan memiliki tingkat verbositas yang berbeda tergantung pada build Anda. Bahkan kemudian, para pengguna ASP.NET dan SQL Server bukan pengguna tipikal Anda, dan akan lebih suka sesuatu yang penuh dengan informasi verbal dan lezat karena mereka dapat melacak masalah mereka lebih cepat.

Mengapa para pengembang berpikir tidak apa-apa, di zaman sekarang ini, untuk menyediakan jumlah minimum informasi ketika terjadi kesalahan?

Ini 2011 orang, datang pada .

design exceptions error-messages

— Jus Moo
sumber

11

Wow, itu kata-kata kasar.

— George Marian

3

@ George, dapatkah Anda memberi tahu bahwa saya baru saja menghabiskan waktu yang lama melacak sesuatu yang benar-benar bisa diselesaikan dengan lebih cepat karena kesalahan yang tepat? :)

— Moo-Juice

4

Saya menyarankan napas dalam-dalam, mungkin beberapa yoga & meditasi. :) (Konon, saya tahu persis bagaimana perasaan Anda.)

— George Marian

2

+1 - "string atau data biner akan terpotong" selalu membuatku gila!

— k25

22

Meskipun ada banyak contoh pesan kesalahan buruk yang seharusnya tidak terjadi, Anda harus ingat bahwa tidak selalu mungkin untuk memberikan informasi yang ingin Anda lihat.

Ada juga kekhawatiran tentang mengekspos terlalu banyak informasi, yang dapat menyebabkan pengembang melakukan kesalahan dengan hati-hati. (Saya berjanji kepada Anda bahwa permainan kata-kata tidak dimaksudkan, tetapi saya tidak menghapusnya sekarang karena saya sudah menyadarinya.)

Terkadang, ada juga fakta bahwa pesan kesalahan yang kompleks tidak berguna bagi pengguna akhir. Berpihak pada informasi yang berlebihan tidak selalu merupakan pendekatan yang baik untuk pesan kesalahan. (Itu mungkin lebih baik disimpan untuk logging.)

— George Marian
sumber

+1 Saya bahkan tidak memikirkan aspek kelebihan informasi.

— Ryan Hayes

Saya menjelaskan dalam posting saya bahwa saya bisa mengerti mengapa beberapa orang merasa bahwa verbositas kepada pengguna akhir mungkin tidak berguna bagi mereka. Tetapi apakah Anda mengatakan bahwa pengguna akhir API (ag ASP.NET's adapter), atau mesin database (SQL-Server) tidak ingin kesalahan verbose? Sesuatu yang akan menyelamatkan kita berpotensi kehilangan waktu? Omong-omong, aku suka permainan kata-kata :)

— Moo-Juice

1

@ George, juga berkenaan dengan informasi yang berlebihan dan bermanfaat bagi pengguna akhir, sekali lagi saya bisa melihat kasus untuk tidak melempar jejak stack-on penuh ke pengguna pengolah kata, jangan sampai mereka memiliki momen coklat-celana dan berpikir mereka telah menghapus internet. Namun, Anda telah memberikan alternatif yang sangat baik dengan informasi kompleks dalam file log. Yang perlu dilakukan pesan sekarang adalah menambahkan For further information, see log20111701.txt. Ini akan menjadi langkah ke arah yang benar.

— Moo-Juice

2

@Moo Pada akhirnya, yang saya katakan adalah mudah dikritik. (Saya tahu, saya sering melakukannya.) Namun, saya mencoba untuk mengingat bahwa tidak selalu mudah untuk mengatakan berapa banyak informasi yang harus Anda sertakan dalam pesan kesalahan. Ada banyak waktu ketika saya harus kembali dan menampilkan informasi yang lebih rinci daripada yang saya perkirakan saat melakukan debugging. Juga, ada banyak waktu ketika pesan kesalahan tidak berguna seperti yang saya perkirakan saat membuatnya.

— George Marian

1

@ mo Inti dari masalahnya adalah tidak selalu jelas seberapa banyak informasi berguna. Contoh yang Anda berikan tampak agak jelas. Namun, tidak mudah untuk memperluas ke kasus umum.

— George Marian

21

Pengembang bukan orang yang tepat untuk menulis pesan kesalahan.

Mereka melihat aplikasi dari sudut yang salah. Mereka sangat menyadari apa yang salah di dalam kode, tetapi sering tidak mendekati perangkat lunak dari sudut pandang mencoba mencapai sesuatu. Akibatnya, informasi apa yang penting bagi pengembang belum tentu informasi penting bagi pengguna.

— David Thornley
sumber

+1 Untuk banyak jenis Kerangka / API kesalahan, bagian dari masalah adalah pengembang perpustakaan tidak dapat mengetahui konteksnya. Yang mengatakan, OP tampaknya sebagian besar prihatin dengan "ada sesuatu yang salah tetapi saya tidak akan memberi tahu Anda di mana meskipun saya tahu" jenis pesan kesalahan. Saya kira itu keamanan, kan?

— MIA

8

Pandangan amal:

Pengembang bekerja erat dengan kode dan berjuang untuk memahami seseorang yang tidak memiliki pemahaman mereka bekerja dengannya. Akibatnya mereka berpikir pesan kesalahan baik-baik saja, mereka hanya tidak memiliki kerangka referensi yang baik untuk menilai mereka.
Pesan kesalahan cerdas sebenarnya sulit dilakukan. Tidak hanya menulisnya tetapi Anda harus memikirkan semua yang mungkin salah, menilai kemungkinan dan memberikan informasi yang berguna (yang hampir pasti bervariasi berdasarkan konteksnya) kembali kepada orang yang membaca pesan untuk memungkinkan mereka memperbaikinya.
Untuk sebagian besar aplikasi, sulit untuk membuat kasus yang baik untuk saat ini untuk melakukan hal seperti ini dan pengembang berikutnya akan sangat suka karena kesalahan tidak sering terjadi. Selain itu, jika Anda memiliki waktu ekstra itu, bukankah seharusnya Anda habiskan untuk menghentikan kesalahan daripada melaporkannya?

Tampilan yang tidak bisa ditiru:

Pesan kesalahan dan penanganan kesalahan membosankan, ada hal-hal yang jauh lebih menarik untuk dikerjakan dan bos saya mendukung saya tentang hal berikutnya. Saya mengerti kode ini, saya akan baik-baik saja, orang berikutnya akan menyelesaikannya pada akhirnya dan saya akan keluar dari sini pada saat itu jadi itu bukan masalah saya.

Kenyataannya mungkin di suatu tempat di tengah, meskipun pengalaman saya sebenarnya mengatakan itu jauh lebih tua daripada yang kemudian - pada dasarnya itu sebenarnya cukup sulit dan membutuhkan upaya yang cukup banyak untuk menangani sesuatu yang mungkin tidak akan terjadi.

— Jon Hopkins
sumber

Saya mengerti dari mana Anda berasal dalam banyak kasus pengguna akhir. Namun, kasus-kasus yang saya jelaskan dalam posting asli saya dapat sering terjadi saat menulis kode terhadap database. Berkenaan dengan aplikasi pengguna akhir seperti pengolah kata atau permainan komputer, kesalahan umumnya tidak boleh terjadi kecuali sesuatu yang buruk terjadi, dan bahkan kemudian kesalahan itu mungkin tidak berarti apa-apa bagi pengguna akhir ( Process Handle Raped By Spawned Injector, Quitting SYstem..... pengguna: "wtf apa yang saya lakukan?`). Tetapi dalam kasus SQL Server / ASP.NET, saya pikir lebih banyak upaya dapat dilakukan :)

— Moo-Juice

@ Moo-Juice - Saya pikir itu turun ke seluruh hal "pesan kesalahan itu sulit". Di bawah tenda apa yang sebenarnya dilemparkan ke database setelah pengoptimal telah melakukan itu hanya memiliki kemiripan yang lewat dengan apa yang Anda lemparkan padanya. Mengidentifikasi kesalahan adalah satu hal, menelusuri kembali apa yang terjadi pada apa yang Anda lewati adalah hal yang sama sekali lain dan sama sekali tidak sepele.

— Jon Hopkins

beberapa kasus mungkin tidak sepele. Saya sedikit kode sederhana di suatu tempat yang menangkap string/binary datakesalahan yang menarik semua informasi kolom dari tabel tersebut, memeriksa nilai-nilai masa lalu dan menunjukkan kolom mana yang akan dilanggar. Ini sepele. Mungkin saya terlalu banyak menggerutu karena contoh-contoh kasus saya sepele, tetapi saya benar-benar mengerti bahwa ini tidak selalu terjadi. Bagaimana kita menghentikan suntikan yang muncul dari proses pemerkosaan mungkin sulit :)

— Moo-Juice

6

Sayangnya, pesan kesalahan yang lebih bermanfaat menghabiskan waktu pengembang, yang sama dengan uang perusahaan. Produk cukup mahal untuk dibangun. Ya, itu akan luar biasa untuk memiliki pesan kesalahan yang lebih bermanfaat, dan saya setuju bahwa harus ada yang lebih bermanfaat termasuk. Namun, itu hanya fakta kehidupan bahwa ketika Anda berada di bawah tenggat waktu, dan uang ada di telepon, Anda harus memotong sesuatu. "Pesan kesalahan yang lebih cantik" seperti yang mungkin dilihat oleh manajer, kemungkinan akan menjadi hal pertama yang dilakukan.

— Ryan Hayes
sumber

Ah, ya, poin bagus. Yang selalu ada menyangkut biaya.

— George Marian

Saya dapat mengakui perspektif biaya (dan sialnya, itu tidak berarti saya harus menyukainya ). Saya tidak bisa bicara dari sudut pandang pengembang SQL Server atau ASP.NET, tapi aku tahu bahwa itu tidak mengambil bahwa banyak usaha ekstra untuk memberikan nama kolom. Saya akui bahwa, untuk contoh sederhana saya, mungkin diselesaikan dalam satu jam. Lalu ada 1000 kesalahan lain yang mungkin dihasilkan. Tapi mereka setidaknya bisa mulai dengan yang umum :)

— Moo-Juice

tentu saja saya tidak tahu internal SQL server - tetapi secara umum, lebih sering Anda tidak memiliki informasi tersebut pada saat situasi kesalahan terdeteksi. Formulasi seperti "string atau data biner" cukup jelas menunjukkan kepada Anda bahwa di situs kesalahan, bahkan tidak jelas apakah nilai terpotong adalah string atau angka ...

— Ichthyo

Pada tingkat tertentu, ini mungkin valid, tetapi masalah yang sama bahkan muncul di skrip perl sederhana di mana hanya menambahkan $! untuk pesan kesalahan akan sangat membantu. Lebih murah (dalam hal waktu pengembang) untuk menulis 'die "$ path: $!"' Daripada menulis 'die "yang sama sekali tidak berguna,' Tidak dapat membuka $ path" '

— William Pursell

6

Saya setuju bahwa pesan kesalahan harus sespesifik mungkin.

Salah satu alasan untuk pesan kesalahan umum mungkin adalah penggunaan kode kesalahan. Saat menggunakan pengecualian, Anda bebas untuk lulus semua yang Anda butuhkan dalam pesan kesalahan. Menggunakan kode kembali tidak ada ruang untuk menyandikan nama kolom. Mungkin kesalahan ditangani oleh fungsi generik yang tidak tahu konteksnya dan hanya menerjemahkan kode kesalahan ke string.

— ThomasW
sumber

itu bahkan lebih buruk: ketika Anda dapat memicu kesalahan pada titik yang sangat spesifik, untuk menangani kesalahan Anda terpaksa memasukkan beberapa kemungkinan ke dalam kelas situasi, dan menanganinya dengan satu pemulihan tunggal. Tindakan generalisasi ini seringkali memaksa Anda untuk membuang lebih banyak informasi konteks tambahan yang langka.

— Ichthyo

btw ... mekanisme ini mengarah ke seluruh kelas pesan kesalahan lucu - di sepanjang baris "Kesalahan serius -567 di Modul dwarf678: Tidak ada kesalahan terdeteksi"

— Ichthyo

4

Terkadang terlalu banyak informasi dapat menjadi risiko keamanan; Anda tidak tahu siapa yang membaca pesan kesalahan
Kadang-kadang operasi yang melempar pengecualian sangat kompleks sehingga tidak mungkin untuk mendapatkan pesan yang bermakna tanpa dampak negatif terhadap kecepatan / kompleksitas kode

— StuperUser
sumber

Saya menjawab poin pertama Anda yang memungkinkan untuk perubahan verbosity ke pengecualian yang dilemparkan dalam kode Anda. Poin kedua Anda diperdebatkan mengingat pada saat ini, telah terjadi kesalahan dan kecepatan tidak lagi menjadi faktor penentu (imho). Dan jika menghasilkan pesan kesalahan verbose memerlukan dampak kinerja SEBELUM melemparkan pengecualian maka saya setuju. Pindahkan kode itu ke SETELAH pengecualian telah dibuang. Saya tidak melihat salah satu dari poin ini sebagai argumen yang valid terhadap pesan kesalahan yang tepat :)

— Moo-Juice

Benar, saya kira Anda dapat mencari informasi begitu sesuatu terjadi daripada melacak apa yang mungkin Anda butuhkan. Meskipun, jika Anda berada di loop bersarang menangkap indeks / indeks mungkin bermasalah.

— StuperUser

-1 untuk poin pertama yang tidak saya setujui, +1 untuk poin kedua.

— Jon Hopkins

1

@jon Kontras pesan kesalahan umum untuk kesalahan masuk versus pesan kesalahan lebih spesifik yang benar-benar memberi tahu Anda apa yang salah. mis. "Kami tidak dapat menemukan kombinasi nama pengguna / kata sandi" vs "Anda memasukkan kata sandi yang salah." / "Nama pengguna itu tidak ada." Saya sepertinya mengingat kerentanan dalam ASP.NET di mana pesan kesalahan sebenarnya berguna dalam memecahkan kunci enkripsi.

— George Marian

@ George - Saya setuju dengan contoh itu tetapi saya tidak berpikir itu tersebar luas. Setelah Anda diberikan akses ke aplikasi, tingkat risiko tertentu menghilang karena Anda dapat menganggap orang tersebut (a) berwenang dan (b) bisa mendapatkan sebagian besar dari apa yang dibutuhkan dari aplikasi yang sebenarnya.

— Jon Hopkins

3

Sebagai pemberitahuan umum, Anda harus mempertimbangkan bahwa setiap kesalahan atau situasi luar biasa adalah - persis itu: luar biasa. Ini memotong prosedur yang direncanakan dan dirancang. Ini tidak sesuai dengan cara hal-hal yang direncanakan untuk bekerja. Jika ini bukan masalahnya, maka tidak perlu ada jaminan dengan pembatalan kesalahan.

Kami programmer dilatih untuk melindungi diri dari prosedur yang direncanakan ini. Dengan demikian, kami secara rutin menyertakan beberapa pemeriksaan kewarasan untuk memverifikasi asumsi kami. Ketika cek kewarasan ini gagal, kita hanya tahu bahwa rencana itu entah bagaimana gagal ...

Permintaan Anda - mungkin terlihat seperti akal sehat dari sudut pandang pengguna - tidak mungkin dipenuhi, jika Anda mempertimbangkan kenyataan bagaimana sistem seperti itu bekerja. Anda meminta pernyataan tertib dengan informasi yang terorganisir dengan baik dan sesuai ditambahkan. Selain itu, Anda bahkan meminta agar presentasi ini terjadi dengan cara yang sesuai dengan aplikasi umum / desain penanganan. Jelas informasi ini ada di suatu tempat di sistem. Jelas itu bahkan ada di sana secara teratur dan terorganisir dengan baik (mari kita berharap begitu). TETAPI pada titik kesalahan terjadi, tidak ada yang pernah berencana untuk membuat informasi ini tersedia. Kesalahan selalu merupakan hilangnya sebagian kontrol.Kehilangan kendali ini dapat terjadi pada berbagai tingkatan. Bisa jadi sistem berperilaku saat runtime berbeda dari yang direncanakan. Tetapi bisa juga bahwa implementasi aktual ternyata jauh lebih sulit dan berbeda dalam rincian yang direncanakan, dan tidak ada ketentuan yang digerakkan untuk menangani situasi ini dengan memuaskan. Ini juga merupakan kehilangan sebagian kontrol.

Untuk mengaitkan ini dengan contoh konkret yang Anda berikan: Jika, pada titik kesalahan, nama dan jenis kolom tabel akan diketahui, dan selain panjang ruang yang dibutuhkan, maka tidak akan ada alasan untuk meningkatkan kesalahan, bukan? Kami hanya bisa memperbaiki situasi dan melanjutkan sesuai rencana. Kenyataan bahwa kita dipaksa untuk membuat kesalahan menunjukkan kepada kita bahwa segala sesuatunya tersesat. Fakta bahwa informasi ini tidak ada adalah pengecualian .

Apa yang saya tulis di sini mungkin tampak jelas dan masuk akal. Namun dalam kenyataannya sangat sulit untuk dipahami. Kami terus berusaha memahaminya dengan menerapkan kategori moral - seperti harus ada pelakunya, harus ada orang malas yang buruk yang tidak peduli pada pengguna yang buruk, harus ada pengusaha serakah yang melakukan cara perhitungan murah. Semua ini benar-benar tidak penting

Kemungkinan kehilangan kendali berasal dari fakta bahwa kami melakukan sesuatu dengan cara yang terencana dan teratur .

— Ichthyo
sumber

Saya harus tidak setuju. Ia tahu ada sesuatu yang salah (tidak dapat melakukan operasi). Mengetahui bahwa ada sesuatu yang salah menunjukkan pengetahuan mengapa itu salah. String ini terlalu besar untuk kolom itu (atau kolom dalam tabel itu). Itu bisa memberitahu saya, tanpa banyak pekerjaan. Ini adalah mesin database perusahaan. Itu tahu . Tetapi itu tidak menyampaikan informasi itu. Mengingat bahwa programmer dapat menulis permintaan untuk menjalankan setelah fakta untuk mengetahui menunjukkan mesin database dapat melakukan hal yang sama. Ini bukan aspek rahasia yang tidak terdokumentasi. Hanya pesan kesalahan jelek :)

— Moo-Juice

heh ... Anda harus mendasarkan argumen Anda pada logika, bukan pada pemikiran yang bijak. Sejak kapan komputer tahu apa - apa? Ini bukan bioskop Hollywood. Suatu program adalah pengaturan yang kaku dan telah diatur sebelumnya, dan ketika asumsi Anda rusak, Anda kehilangan kendali. Apakah ini sangat sulit untuk dipahami? Komputer tidak mengerti programnya, jadi dia tidak bisa mengerti ketika itu salah. Hampir pernah, ketika beberapa pemeriksaan konsistensi memicu, eksekusi telah diproses oleh ribuan pernyataan dan tidak ada yang tahu data apa yang sudah rusak. Yang bisa Anda lakukan adalah membatasi kerusakan

— Ichthyo

2

Saya bekerja sebagai insinyur pendukung untuk perusahaan perangkat lunak dan seringkali kita melihat pesan kesalahan yang baru bagi kami. Seringkali ketika saya merujuk ini kembali ke tim pengembangan kami, mereka harus mencari pesan di sumber aplikasi.

Menurut saya, bahkan jika itu tidak disajikan kepada pengguna, akan banyak waktu yang aman bagi kami jika tim pengembang akan menambahkan catatan ke indeks pesan kesalahan atau basis data setiap kali mereka menambahkan yang baru itu akan membuatnya jauh lebih cepat bagi kita untuk menemukan penyebab masalah pelanggan dan menghemat waktu mereka juga ...

— glenatron
sumber

1

maaf, itu tidak praktis. Siapa yang akan bertanggung jawab untuk mengelola indeks dokumen itu, untuk menjaganya agar tetap akurat. Karena setiap dokumentasi tertulis terpisah dari kode, kode itu akan kedaluwarsa dan mulai mendapatkan sumber untuk kesalahan baru begitu kode itu ditulis.

— Ichthyo

Sebaliknya, itulah jenis yang dapat diambil skrip dari kode sumber, jika setiap kesalahan memiliki angka unik, dan deskripsi masing-masing juga dalam kode baik dalam bentuk komentar (diformat khusus) atau sebagai tali. Jadi dokumen akan dibuat secara otomatis dengan setiap build. Pesan yang diekstrak kemudian bisa menjadi sedikit lebih rinci daripada apa pun yang Anda ingin dilihat oleh pengguna akhir. Bukan ide yang buruk!

— Jeanne Pindar

Anda tidak memerlukan skrip untuk itu - banyak sistem runtime dapat mencatat nomor baris atau info serupa. Sayangnya ini tidak membantu dengan masalah aslinya, karena dengan cara ini kami hanya tahu di mana pengecualian terdeteksi tetapi kami tidak tahu apa yang salah . Mengetahui yang terakhir disebut debugging - dalam praktiknya ini adalah tugas yang lebih atau kurang membosankan yang dilakukan oleh manusia.

— Ichthyo

Saya dengan @Jeanne - cukup sederhana untuk dimasukkan ke dalam kode atau memiliki indeks pusat dalam kode dengan kode kesalahan dan interpretasinya. Setelah tahu di mana pengecualian terdeteksi yang mungkin cukup untuk memberi tahu Anda bahwa ada masalah dengan lingkungan di suatu tempat daripada sesuatu dalam kode yang perlu mengejar.

— glenatron

2

Masalah yang Anda lihat sebenarnya adalah salah satu efek samping dari enkapsulasi dan penyembunyian informasi yang tepat.

Sistem modern sangat rumit. Ada sedikit kemungkinan bahwa pengembang rata-rata mampu memegang, di kepalanya, model mental dari seluruh sistem dari UI ke biner mentah saat dia sedang mengkode tugas tertentu.

Jadi, ketika seorang pengembang sedang duduk dan mengkodekan, katakanlah, bit yang mengembalikan file database, model mentalnya dipenuhi sepenuhnya dengan bit yang mengelilingi tindakan memulihkan file database. Dia perlu (dan saya kira, saya belum menulis kode ini) membaca file, memeriksa properti, membaca versi, membuat cadangan data yang ada, memilih strategi gabungan / menimpa, dll. Kemungkinan besar, jika ada bahkan sebuah passing pertimbangan ke UI, itu dalam string kesalahan yang ia tulis dalam penangan pengecualian. Sesuatu seperti:

catch (IOException error)
{
//File is in use
throw new GenericExceptionParsedByTheUIThread("File is in use.");
}

Dalam contoh ini, informasi bermanfaat yang Anda tanyakan dalam hal proses yang mungkin menggunakan file, atau bahkan utas lainnya dalam DB, sepenuhnya berada di luar ruang lingkup (secara programatik). Mungkin ada ratusan kelas yang menangani file DB; mengimpor ke kelas-kelas informasi tentang setiap proses lain menggunakan file, atau fungsi untuk mengakses sistem file dan melihat proses lain yang berjalan (dengan asumsi proses-proses tersebut bahkan pada mesin INI) akan menghasilkan apa yang dikenal sebagai abstraksi bocor ; ada biaya langsung dalam produktivitas.

Jadi begitulah kesalahan semacam ini dapat bertahan di zaman modern. Jelas, mereka semua BISA diperbaiki; tetapi dalam banyak kasus, ada banyak overhead yang terlibat daripada yang diperkirakan (dalam kasus ini misalnya, Anda mungkin harus memiliki fungsi ini melintasi enumerasi koneksi jaringan dan berbagi untuk melihat apakah mesin jarak jauh menggunakan file database ini untuk beberapa alasan) dan biayanya jauh dari sepele.

— GWLlosa
sumber

@ GWLlosa, ini adalah jawaban yang bagus dan saya belum mempertimbangkannya. Yang mengatakan (dan saya tidak bisa memberikan contoh kode lengkap di sini), ketika saya mendapatkan IOException itu, sebelum saya melemparkan saya GenericException, saya bisa 1) Tanyakan ProcessesSubsistem untuk daftar proses. 2) Tanyakan setiap proses, basis data apa yang mereka gunakan. 3) Cocokkan proses dengan database yang ditugaskan ke yang saya coba timpa, 4) melemparkan DatabaseInUse(dbName, processName, applicationNamepengecualian. :)

— Moo-Juice

1

Tentu saja mungkin; tetapi kode untuk mencocokkan DB dengan proses (terutama melalui jaringan) mungkin rumit / lambat / rawan kesalahan itu sendiri, yang dapat mengakibatkan beberapa frustrasi tambahan ("Saya hanya mencoba mengembalikan lokal (* #% ^! % file !!!! MENGAPA SAYA PEDULI BAHWA SAHAM JARINGAN TIDAK DAPAT DIAKSES! ??!?! ")

— GWLlosa

1

@ Moo-Juice: apa yang Anda usulkan terdengar sangat naif. Dalam lingkungan multithreaded besar seperti basis data Anda tidak bisa hanya menjangkau beberapa layanan global untuk mendapatkan daftar "semua xyz". Bahkan untuk berbicara dengan beberapa layanan lain di utas lain, Anda memerlukan kunci, yang dapat menyebabkan kebuntuan seluruh sistem menjadi lebih buruk, dapat merusak data lain atau setidaknya itu dapat menyebabkan kesalahan tambahan, yang perlu Anda tangani juga ....

— Ichthyo

1

Contoh itu memang sangat instruktif: Biasanya dalam penangan tangkapan seperti itu, Anda bahkan tidak bisa memastikan bagian mana di blok percobaan gagal (biasanya ada beberapa bagian yang dapat menyebabkan IOException). Selain itu, sangat mungkin bahwa di lokasi itu Anda tidak dapat memberi tahu nama file, jangan sampai Anda tahu tabel logis mana yang sesuai dengan file ini.

— Ichthyo

@ Ichthyo, jangan tersinggung tapi saya tidak berpikir itu naif sama sekali. Saya tidak meminta mesin database untuk mengunci sistem untuk memberi tahu saya proses apa yang masih memiliki pegangan untuk database. Saya tidak memintanya untuk menghentikan seluruh perusahaan. Jika perlu memberi saya jawaban sederhana, itu menunjukkan cacat desain mendasar dari server database di tempat pertama. Ingat, itu seharusnya dirancang untuk memberikan informasi terkait kembali dengan cara tercepat yang mungkin. Untuk mengajukan pertanyaan "siapa?" benar-benar tidak semanif yang Anda nyatakan :)

— Moo-Juice

2

Favorit saya adalah (kembali pada akhir 70-an) kompiler Univac Fortran IV, ketika membaca non-digit, dengan setia diumumkan

Penafsiran data yang tidak berarti dicoba

— nyengir
sumber

+1, benar-benar fantastis! Ini adalah jenis kesalahan yang membuat Anda hanya ingin menyerah dan pergi dan memelihara ayam di Fiji.

— Moo-Juice

memang, pesan kesalahan ini 100% akurat - jika Anda menginginkan pesan yang lebih ramah dengan lebih banyak conetxt, Anda perlu membuat beberapa dugaan dan heuristik; dengan cara ini Anda menambahkan kemungkinan pesan kesalahan yang menyesatkan ..

— Ichthyo

0

Saya percaya sebagian besar pesan kesalahan sebenarnya programmer (self) berorientasi kode dimuliakan debugging / pernyataan printf.

Menulis pesan kesalahan berorientasi pengguna berarti mengetahui siapa pengguna Anda, dan mengantisipasi apa yang ingin mereka ketahui. Sementara di tengah penulisan kode, pengembang lebih cenderung untuk menulis pesan kesalahan yang berguna bagi diri mereka sendiri, baik untuk debugging kode yang mereka tulis saat ini, atau berguna untuk Kasus Penggunaan yang diketahui atau mendominasi.

Beralih dari menulis kode ke mendesain bagian tekstual dari antarmuka pengguna (atau pengalaman pengguna) adalah saklar konteks. Dalam aplikasi besar, seperti aplikasi multibahasa yang bisa berarti itu diserahkan kepada orang atau tim yang berbeda (UI, terjemahan) daripada sepenuhnya ditangani oleh pengembang, jadi kecuali pengembang hati-hati menjelaskan konteks pesan, rincian penting dapat mudah hilang.

Tentu saja, memeriksa dan memverifikasi penanganan kesalahan sering dianggap sebagai prioritas rendah, selama kesalahan & pengecualian ditangani (yaitu tertangkap), tidak banyak penekanan diberikan padanya. Ini adalah tempat basis kode untuk pengembang atau QA yang tidak mendapat penghargaan secara mental, karena kondisi kesalahan sering memiliki konotasi negatif (mis. Kesalahan atau kegagalan) yang terkait dengannya.

— mctylr
sumber

0

Saya pikir alasannya adalah bahwa pelaporan kesalahan / penanganan selalu dilakukan setelah pemikiran . Bahkan ketika mereka tidak sepenuhnya setelah berpikir, mereka sebagian besar warga negara kelas dua dalam desain keseluruhan.

Perangkat lunak modern biasanya terdiri dari banyak lapisan. Ketika logika pelaporan kesalahan Anda disusun dengan terburu-buru tanpa terlalu banyak berpikir, seringkali sulit untuk mengumpulkan semua informasi yang diperlukan untuk menyajikan pesan kesalahan yang berguna.

Misalnya, kesalahan ditangkap di back-end, tetapi perlu beberapa informasi dari lapisan yang lebih tinggi untuk menyusun pesan kesalahan yang komprehensif. Sebagian besar pesan kesalahan yang baik memerlukan informasi dari hampir semua lapisan (untuk memberi kami pandangan komprehensif tentang apa yang terjadi dalam sistem). Pesan kesalahan yang ideal akan terlihat seperti "OK, kami pertama menerima string, kemudian melewati parser yang memberi sesuatu yang lucu, Anda mungkin ingin melihat di sana. Lagi pula, benda itu diteruskan ke bawah ..."

Melakukannya akan sering memerlukan kopling yang tidak perlu jika mekanisme pelaporan kesalahan bukan warga negara kelas satu selama fase desain. Saya kira kebanyakan orang hanya menemukan bahwa terlalu banyak pekerjaan yang harus dilakukan untuk sesuatu yang tidak terlihat mengesankan (yang suka mengatakan "Lihat? Program saya macet, dan pesan kesalahannya berguna!").

— kizzx2
sumber