Penanganan Kesalahan (RPC)
Dalam RPC sinkron, klien melakukan panggilan jarak jauh yang kembali dengan kode keberhasilan atau kegagalan. RPC asinkron memberikan lebih banyak peluang bagi panggilan untuk gagal, dan kegagalan ini ditangani secara berbeda, tergantung di mana dan kapan terjadinya. Tabel berikut ini menjelaskan cara panggilan bisa gagal, dan bagaimana panggilan ditangani.
Pembersihan Sisi Klien
| Gejala kegagalan | Pembersihan |
|---|---|
| Klien menangkap pengecualian ketika memanggil prosedur jarak jauh. | Tidak ada panggilan API RPC yang diperlukan. Semua status RPC telah dibersihkan. |
| Klien menerima pemberitahuan lengkap panggilan, tetapi ketika memanggil RpcAsyncCompleteCall, ia menerima kode kesalahan. | Tidak ada panggilan API RPC yang diperlukan. Semua status RPC telah dibersihkan. |
| Masalah klien non-abortif atau pembatalan abortif. | Klien harus menunggu pemberitahuan, dan memanggil RpcAsyncCompleteCall saat pemberitahuan tiba. |
Dalam pembersihan sisi server, konsep kunci adalah titik hand-off. Selama pemrosesan sisi server panggilan asinkron, beberapa pemrosesan biasanya dilakukan pada utas yang menerima panggilan (juga dikenal sebagai utas dispatcher ), dan kemudian, secara opsional, utas dispatcher menempatkan status yang cukup ke dalam blok memori dan memberi sinyal utas lain (juga dikenal sebagai utas pekerja ) untuk terus memproses panggilan. Momen di mana utas dispatcher berhasil menandakan bahwa utas pekerja disebut titik hand-off.
Pembersihan Sisi Server
| Terjadi kesalahan | Pembersihan |
|---|---|
| Sebelum titik hand-off. | Lempar pengecualian. Tidak diperlukan panggilan ke RpcAsyncCompleteCall. |
| Setelah titik hand-off. | Panggil RpcAsyncAbortCall atau, jika kesalahan tidak fatal dan hasilnya masih dapat dikembalikan ke klien, RpcAsyncCompleteCall. Jika panggilan fungsi RpcAsyncCompleteCall gagal, runtime RPC membebaskan parameter. Pengguna tidak boleh mengakses parameter tersebut. Utas dispatcher tidak boleh melakukan pemrosesan substansial yang mungkin gagal setelah titik lepas tangan, karena tidak lagi dapat membatalkan panggilan dengan aman. Secara khusus, itu tidak boleh melemparkan pengecualian setelah titik lepas tangan, atau server mungkin crash. |
Kasus Penanganan Kesalahan Khusus untuk Pipa
Ada kasus khusus untuk penanganan kesalahan saat menggunakan pipa. Daftar berikut menjelaskan sumber kegagalan, dan cara menangani kesalahan.
| Sumber kegagalan | Bagaimana ditangani |
|---|---|
| Panggilan klien mendorong dan panggilan gagal. | Tidak ada panggilan API RPC yang diperlukan. Semua status RPC telah dibersihkan. |
| Panggilan klien RpcAsyncCompleteCall sebelum di pipa dikosongkan. | Panggilan gagal dengan kode kesalahan pengisian pipa yang sesuai. |
| Panggilan klien menarik dan panggilan gagal. | Tidak ada panggilan API RPC yang diperlukan. Semua status RPC telah dibersihkan. |
| Panggilan klien atau server mendorong atau menarik dalam urutan yang salah. | Run-time mengembalikan status kesalahan pengisian pipa. |
| Panggilan server mendorong atau menarik dan panggilan gagal. | Push mengembalikan kode kegagalan. Tidak diperlukan panggilan ke RpcAsyncCompleteCall. |
| Panggilan server RpcAsyncCompleteCall sebelum pipa dikosongkan. | Panggilan pipa mengembalikan status kesalahan pengisian pipa. |
| Setelah pengiriman, operasi penerimaan gagal. | Lain kali server memanggil tarik untuk menerima data pipa, kesalahan dikembalikan. |