Menjinakkan error di VBA: menangkap dan menangani kesalahan dengan On Error GoTo dan On Error Resume Next, membaca Err Number dan Description, serta debugging sistematis memakai breakpoint Debug.Print watch dan Step Into

Di episode-episode sebelumnya kita sesekali melihat On Error Resume Next dan label Selesai. Episode ini membedah semuanya secara sistematis: error handling dan debugging — dua keterampilan yang membedakan kode yang "biasanya jalan" dari kode yang bisa diandalkan.
Mengapa ini penting? Karena error VBA tidak menghibur. Tanpa penanganan, macro yang gagal meninggalkan kotak dialog merah yang tidak jelas, atau lebih buruk — melanjutkan dengan data yang salah. Dengan error handling yang baik, pengguna mendapat pesan yang jelas; dengan debugging yang baik, kalian menemukan penyebabnya dalam hitungan menit.
| Jenis | Terjadi Saat | Contoh |
|---|---|---|
| Compile error | VBA memeriksa kode sebelum jalan | Option Explicit melarang variabel tak terdeklarasi |
| Runtime error | Baris dieksekusi | Bagi dengan nol, Range tidak ditemukan |
| Logic error | Kode jalan tapi hasil salah | Nilai terbalik, loop salah hitung |
Error handling menangani runtime error. Compile dan logic error ditangani lewat debugging.
Cara paling andal menangani runtime error:
Sub ProsesData()
On Error GoTo Gagal
' ... logika utama ...
Range("A1").Value = 100 / 0 ' pemicu error
Exit Sub
Gagal:
MsgBox "Terjadi kesalahan: " & Err.Description, vbCritical
End SubAlurnya:
On Error GoTo Gagal — instruksikan VBA: jika ada error, lompat ke label Gagal.Exit Sub memastikan kode tidak masuk ke blok handler.Gagal: dan membaca Err.Description.Perhatikan Exit Sub sebelum Gagal: — tanpa itu, kode normal akan "jatuh" ke handler dan menampilkan pesan palsu.
Saat error terjadi, VBA mengisi objek Err:
| Properti | Arti |
|---|---|
Err.Number | Kode numerik error (mis. 11 = bagi nol) |
Err.Description | Deskripsi teks (mis. Division by zero) |
Err.Source | Objek/aplikasi yang memicu |
Gagal:
MsgBox "Error " & Err.Number & vbCrLf & _
Err.Description & vbCrLf & _
"di prosedur ProsesData", vbCriticalGabungan Err.Number dan Err.Description membuat laporan bug dari pengguna jauh lebih berguna.
On Error Resume Next memerintahkan VBA melanjutkan ke baris berikutnya saat error — berguna untuk operasi yang boleh gagal, tapi berbahaya jika dipakai tanpa sadar:
On Error Resume Next
Range("A1").SpecialCells(xlCellTypeBlanks).Delete
On Error GoTo 0Di episode 9 kita memakai pola ini: SpecialCells(xlCellTypeBlanks) melempar error bila tidak ada sel kosong — dan itu bukan kegagalan, melainkan kondisi normal. On Error GoTo 0 mematikan mode resume setelahnya.
Warning
On Error Resume Next menyembunyikan semua error — termasuk yang tidak kalian duga. Jangan membiarkannya aktif di seluruh prosedur. Batasi sekecil mungkin, lalu kembalikan dengan On Error GoTo 0. Kode yang diselubungi Resume Next adalah mimpi buruk saat dicari bug-nya.
Kita bisa memberi respons berbeda per Err.Number:
Sub BukaFile()
On Error GoTo Gagal
Workbooks.Open "C:\data\tidak-ada.xlsx"
Exit Sub
Gagal:
If Err.Number = 1004 Then
MsgBox "File tidak ditemukan. Periksa path.", vbExclamation
Else
MsgBox "Error tak terduga: " & Err.Description, vbCritical
End If
End SubErr.Number = 1004 adalah error umum "Application-defined or object-defined error" di Excel — sering muncul saat path/file tidak ditemukan.
Setelah error handling, debugging adalah cara menemukan di mana dan mengapa.
Klik di gutter kiri Code window (atau tekan F9) untuk memasang breakpoint — lingkaran merah. Saat macro dijalankan, eksekusi berhenti di baris itu dan kalian bisa memeriksa keadaan.
| Perintah | Pintasan | Fungsi |
|---|---|---|
| Step Into | F8 | Eksekusi baris per baris, masuk ke prosedur yang dipanggil |
| Step Over | Shift+F8 | Eksekusi satu prosedur sekaligus, tidak masuk ke dalamnya |
| Run to Cursor | Ctrl+F8 | Lompat langsung ke baris tempat kursor |
| Reset | Ctrl+Shift+F8 | Hentikan debugging sepenuhnya |
Debug.Print mengirim nilai ke Immediate window (Ctrl+G) tanpa mengganggu pengguna:
Sub CekLoop()
Dim i As Long
For i = 1 To 10
Debug.Print "i = " & i
Next i
End SubSaat debugging, setiap iterasi terlihat langsung — pola ideal untuk memverifikasi loop yang mencurigakan.
Alt+F9): memantau ekspresi tertentu — misalnya data(r, 1) — dan berhenti saat nilainya berubah atau memenuhi kondisi.Pernyataan Stop di dalam kode bertindak seperti breakpoint — berguna untuk jeda bersyarat:
If r > 1000 Then StopF8 melangkah baris demi baris, amati Locals window.Debug.Print untuk variabel penting.Reset setelah selesai.| Kesalahan | Dampak |
|---|---|
On Error Resume Next mengaburkan semua error | Bug tersembunyi |
Lupa Exit Sub sebelum label handler | Handler jalan walau tanpa error |
Tidak memeriksa Err.Number | Semua error diberi respons yang sama |
Stop tertinggal di kode produksi | Macro berhenti di tengah jalan di mesin user |
| Me-reset debugging tanpa tahu variabel | Kehilangan jejak nilai yang dicari |
Pada episode 15 ini, kalian telah menjinakkan error dan menguasai debugging.
Inti yang harus dibawa pulang:
On Error GoTo, On Error Resume Next, objek Err.Exit Sub sebelum blok handler; batasi Resume Next sekecil mungkin.Stop = breakpoint bersyarat dari dalam kode; jangan tinggalkan di produksi.Di episode 16 selanjutnya kita membahas macro security & Trust Center — pengaturan macro di Trust Center, digital signature, trusted locations, serta format file .xlsm/.docm/.pptm vs .xlsx dan peran add-in .xlam. Sampai jumpa di episode 16!