Apakah perpustakaan tugas async saya menelan pengecualian dengan tenang?

10

Saya baru saja belajar bahwa .NET 4.5 memperkenalkan perubahan pada bagaimana pengecualian di dalam Taskditangani. Yaitu, mereka diam-diam ditekan.

Alasan resmi mengapa ini dilakukan tampaknya adalah "kami ingin lebih ramah kepada pengembang yang tidak berpengalaman":

Di .NET 4.5, Tugas memiliki keunggulan yang jauh lebih besar daripada yang mereka lakukan di .NET 4, karena mereka dimasukkan ke bahasa C # dan Visual Basic sebagai bagian dari fitur async baru yang didukung oleh bahasa. Ini berlaku memindahkan Tugas dari domain pengembang berpengalaman ke ranah semua orang. Akibatnya, ini juga mengarah pada serangkaian pengorbanan baru tentang seberapa ketatnya penanganan pengecualian.

( sumber )

Saya telah belajar untuk mempercayai bahwa banyak keputusan dalam. Tetapi yang ini luput dari saya.

Jika saya mendesain pustaka tugas async saya sendiri, apa keuntungan dari menelan pengecualian yang dilihat para pengembang Kerangka yang tidak saya lihat?

.net

— Roman Starkov
sumber

4

+1. Pertanyaan yang bagus, mengingat fakta bahwa tidak menyebarkan pengecualian yang tidak dapat Anda tangani adalah praktik yang buruk meskipun mengesampingkan konteks yang tidak sinkron. Juga, argumen tentang pengembang yang tidak berpengalaman cukup lemah, IMHO. Apa yang akan lebih aneh bagi pemula daripada sepotong kode yang tidak hanya tidak berfungsi, tetapi juga tidak ada pengecualian sama sekali?

— Arseni Mourzenko

@MainMa Persis seperti pikiranku, tapi aku salah sebelumnya (ketika ternyata mereka memang punya alasan yang sangat bagus tapi tidak jelas), jadi kupikir aku akan bertanya.

— Roman Starkov

2

Wow, saya senang Anda memposting ini hanya karena ini adalah pertama kalinya saya mendengarnya; dan itu pasti melanggar POLA . Anda benar bahwa orang-orang itu benar-benar tahu apa yang mereka lakukan, jadi saya dengan tulus ingin tahu alasan apa yang mungkin ada di balik ini ... Bertanya-tanya apakah itu punya alasan yang lebih teknis berdasarkan penerapan Async dan bagaimana pengecualian akan menyebar sebagai bawah diteruskan ke coroutine ..

— Jimmy Hoffa

2

Untuk apa nilainya, dokumen yang Anda tautkan memberikan contoh kasus sebagai pembenaran:

Task op1 = FooAsync(); 
Task op2 = BarAsync(); 
await op1; 
await op2;
Dalam kode ini, pengembang meluncurkan dua operasi asinkron untuk berjalan secara paralel, dan kemudian secara asinkron menunggu masing-masing menggunakan fitur bahasa tunggu baru ... [C] lihat apa yang akan terjadi jika op1 dan op2 salah. Menunggu op1 akan menyebarkan pengecualian op1, dan karena itu op2 tidak akan pernah ditunggu. Akibatnya, pengecualian op2 tidak akan diamati, dan proses akhirnya akan macet.

Untuk membuatnya lebih mudah bagi pengembang untuk menulis kode asinkron berdasarkan Tugas, .NET 4.5 mengubah perilaku pengecualian default untuk pengecualian yang tidak teramati. Sementara pengecualian yang tidak diobservasi masih akan menyebabkan acara UnobservedTaskException dimunculkan (tidak melakukan hal itu akan menjadi perubahan yang melanggar), proses tidak akan crash secara default. Sebaliknya, pengecualian tersebut akan berakhir dimakan setelah acara dimunculkan, terlepas dari apakah seorang pawang mengamati pengecualian tersebut.

Saya tidak yakin dengan ini. Ini menghilangkan kemungkinan kesalahan yang tidak ambigu, tetapi sulit dilacak (crash program misterius yang mungkin terjadi lama setelah kesalahan aktual), tetapi menggantinya dengan kemungkinan kesalahan yang benar-benar hening - yang mungkin menjadi masalah yang sama sulitnya untuk dilacak nanti di dalam program Anda. Itu sepertinya pilihan yang meragukan bagi saya.

Perilaku ini dapat dikonfigurasi - tetapi tentu saja, 99% pengembang hanya akan menggunakan perilaku default, tidak pernah memikirkan masalah ini. Jadi apa yang mereka pilih sebagai standar adalah masalah besar.

Tapi Anda lakukan mendapatkan pengecualian normal untuk op1, kan? Jika itu tetap tidak tertangani, itu akan menurunkan proses, kan?

— Timwi

1

@Timwi, seperti yang saya mengerti, tidak ada op1pengecualian atau op2pengecualian yang akan menurunkan program. Keuntungannya adalah Anda memiliki kesempatan untuk mengamati keduanya. Tetapi jika tidak, keduanya akan tertelan. Tapi aku bisa saja salah.

Saya benar-benar terkejut bahwa mereka merasa begitu penting untuk membiarkan Anda "mengamati" keduanya. Jika Anda ingin "mengamati" mereka, Anda menangkap mereka dan melaporkan kejadiannya melalui hasil tugas! ... Setuju dengan alasan Anda, +1

— Roman Starkov

2

TL; DR - Tidak , Anda tidak boleh mengabaikan pengecualian dengan tenang.

Mari kita lihat asumsi.

Imanmu yang buta

Saya telah belajar untuk mempercayai bahwa banyak keputusan dalam. Tetapi yang ini luput dari saya.

MS memiliki beberapa staf yang sangat cerdas, tidak diragukan lagi. Mereka juga memiliki sejumlah manajer dan eksekutif yang ... tidak tahu apa-apa, dan yang secara konsisten membuat keputusan buruk. Seperti halnya kita ingin mempercayai dongeng ilmuwan cerdas yang secara teknis mendorong pengembangan produk, kenyataannya jauh lebih suram.

Maksud saya adalah, jika naluri Anda memberi tahu Anda ada sesuatu yang salah maka ada peluang bagus (dan preseden masa lalu) bahwa itu salah.

Bahwa ini adalah masalah teknis

Cara menangani pengecualian dalam hal ini adalah keputusan faktor manusia, bukan keputusan teknis. Secara longgar, pengecualian adalah kesalahan. Presentasi kesalahan, bahkan jika diformat dengan buruk, memberikan informasi penting kepada pengguna akhir. Yaitu, ada yang salah.

Pertimbangkan percakapan hipotetis antara dan pengguna akhir dan pengembang ini.

Pengguna: Aplikasi rusak.
Dev: Apa yang rusak?
Pengguna: Saya tidak tahu, saya mengklik tombol dan tidak ada yang terjadi.
Dev: Apa yang Anda maksud dengan tidak ada yang terjadi?
Pengguna: Lihat, saya klik, saya menunggu, dan saya menunggu, dan saya menunggu, dan tidak ada ... itu jelas rusak.

Pengembang kami yang malang, untungnya hipotetis sekarang harus mencari tahu apa yang salah dalam rantai peristiwa. Dimana itu?
Pemberitahuan pengendali acara -> Rutin untuk menangani acara -> Metode yang dipicu oleh penangan -> permulaan panggilan asinkron -> 7 lapisan jaringan OSI -> transmisi fisik -> buat cadangan 7 lapisan jaringan OSI -> layanan penerima -> metode yang dipanggil oleh layanan -> ... -> balasan balasan yang dikirim oleh layanan -> .... -> tanda terima asynch -> pemrosesan balasan asynch -> ...

Dan harap dicatat bahwa saya telah membahas beberapa kemungkinan jalur kesalahan di sana.

Setelah membahas beberapa asumsi yang mendasarinya, saya pikir menjadi lebih jelas mengapa dengan diam-diam menekan pengecualian adalah ide yang buruk. Pengecualian dan pesan kesalahan yang terkait adalah indikator utama bagi pengguna bahwa ada kesalahan. Bahkan jika pesan itu tidak berarti bagi pengguna akhir, informasi yang disematkan dapat bermanfaat bagi Pengembang dalam memahami apa yang salah. Jika mereka beruntung, pesan itu bahkan akan mengarah ke solusi.

Saya pikir bagian dari masalah di sini adalah bahwa pengecualian yang ditangani secara tidak benar akan merusak aplikasi Anda. Dengan menekan pengecualian, aplikasi tidak akan macet. Ada beberapa validitas untuk ini karena titik async adalah untuk memungkinkan aplikasi untuk tetap berfungsi saat data sedang diambil. Ini bukan ekstensi logis untuk mengatakan bahwa jika Anda bisa tetap beroperasi sambil menunggu hasil maka kegagalan dalam pengambilan seharusnya tidak membuat aplikasi crash juga - panggilan async secara implisit dinyatakan sebagai tidak cukup penting untuk mengakhiri aplikasi.

Jadi ini solusi, tapi itu menyelesaikan masalah yang salah. Tidak perlu banyak upaya untuk menyediakan pembungkus untuk penanganan pengecualian agar aplikasi tetap berjalan. Pengecualian ditangkap, pesan kesalahan dilemparkan ke layar atau dicatat, dan aplikasi diizinkan untuk terus berjalan. Menekan pengecualian itu menyiratkan bahwa mengabaikan kesalahan akan menjadi A-OK dan bahwa pengujian Anda akan memastikan pengecualian tidak pernah lolos ke lapangan.

Jadi penilaian akhir saya adalah bahwa ini adalah upaya setengah matang untuk menyelesaikan masalah yang dibuat dengan mendorong orang menjadi model asinkron ketika mereka tidak siap untuk mengubah pemikiran mereka ke pendekatan itu.