Mengapa debugging lebih baik dalam IDE? [Tutup]

Saya telah menjadi pengembang perangkat lunak selama lebih dari dua puluh tahun, pemrograman dalam C, Perl, SQL, Java, PHP, JavaScript, dan baru-baru ini Python. Saya tidak pernah memiliki masalah yang tidak dapat saya debug menggunakan pemikiran yang cermat, dan printpernyataan debugging yang ditempatkan dengan baik .

Saya menghargai bahwa banyak orang mengatakan bahwa teknik saya primitif, dan menggunakan debugger nyata dalam IDE jauh lebih baik. Namun dari pengamatan saya, pengguna IDE tampaknya tidak melakukan debug lebih cepat atau lebih sukses daripada yang saya bisa, menggunakan pisau batu dan kulit beruang saya. Saya dengan tulus terbuka untuk mempelajari alat yang tepat, saya baru saja tidak pernah ditunjukkan keuntungan yang menarik untuk menggunakan pengeluh visual.

Selain itu, saya belum pernah membaca tutorial atau buku yang menunjukkan cara debug secara efektif menggunakan IDE, di luar dasar-dasar cara mengatur breakpoint dan menampilkan isi variabel.

Apa yang saya lewatkan? Apa yang membuat alat debugging IDE jauh lebih efektif daripada penggunaan printpernyataan diagnostik yang bijaksana ?

Bisakah Anda menyarankan sumber daya (tutorial, buku, screencasts) yang menunjukkan teknik debugging IDE yang lebih baik?

Jawaban manis! Terima kasih banyak untuk semua orang yang telah meluangkan waktu. Sangat mencerahkan. Saya memilih banyak, dan tidak memilih.

Beberapa poin penting:

• Debuggers dapat membantu saya melakukan inspeksi ad hoc atau perubahan variabel, kode, atau aspek lain dari lingkungan runtime, sedangkan debugging manual mengharuskan saya untuk berhenti, mengedit, dan menjalankan kembali aplikasi (mungkin memerlukan kompilasi ulang).
• Debugger dapat melampirkan ke proses yang berjalan atau menggunakan crash dump, sedangkan dengan debugging manual, "langkah-langkah untuk mereproduksi" cacat diperlukan.
• Debuggers dapat menampilkan struktur data yang kompleks, lingkungan multi-threaded, atau tumpukan runtime penuh dengan mudah dan dengan cara yang lebih mudah dibaca.
• Debuggers menawarkan banyak cara untuk mengurangi waktu dan pekerjaan berulang untuk melakukan hampir semua tugas debugging.
• Debugger visual dan debugger konsol sama-sama berguna, dan memiliki banyak fitur yang sama.
• Sebuah debugger visual yang diintegrasikan ke dalam IDE juga memberi Anda akses mudah ke pengeditan cerdas dan semua fitur lain dari IDE, dalam lingkungan pengembangan terintegrasi tunggal (karenanya namanya).

Beberapa contoh beberapa kemampuan yang akan diberikan oleh debugger IDE kepada Anda di atas jejak pesan dalam kode:

• Lihat tumpukan panggilan kapan saja, memberikan Anda konteks untuk frame tumpukan Anda saat ini.
• Langkah ke perpustakaan yang Anda tidak dapat mengkompilasi ulang untuk tujuan menambahkan jejak (dengan asumsi Anda memiliki akses ke simbol debug)
• Ubah nilai variabel saat program sedang berjalan
• Edit dan lanjutkan - kemampuan untuk mengubah kode saat sedang berjalan dan segera melihat hasil dari perubahan
• Mampu menonton variabel, melihat kapan mereka berubah
• Mampu melewati atau mengulangi bagian kode , untuk melihat bagaimana kode akan bekerja. Ini memungkinkan Anda menguji perubahan teoretis sebelum membuatnya.
• Periksa isi memori secara real-time
• Beri tahu Anda ketika ada pengecualian tertentu , bahkan jika itu ditangani oleh aplikasi.
• Breakpointing bersyarat ; menghentikan aplikasi hanya dalam keadaan luar biasa untuk memungkinkan Anda menganalisis tumpukan dan variabel.
• Lihat konteks utas dalam aplikasi multi-utas, yang mungkin sulit dicapai dengan pelacakan (karena jejak dari utas berbeda akan disisipkan dalam output).

Singkatnya, pernyataan cetak statis (umumnya) dan Anda harus mengkompilasi ulang untuk mendapatkan informasi tambahan jika pernyataan asli Anda tidak cukup detail. IDE menghapus penghalang statis ini, memberi Anda toolkit dinamis di ujung jari Anda.

Ketika saya pertama kali mulai coding, saya tidak bisa mengerti apa masalahnya dengan para debugger dan saya pikir saya bisa mencapai apa pun dengan pelacakan (memang, itu di unix dan debugger itu GDB). Tetapi begitu Anda belajar cara menggunakan debugger grafis dengan benar, Anda tidak ingin kembali mencetak pernyataan.

• Seorang debugger IDE memungkinkan Anda mengubah nilai-nilai variabel pada saat dijalankan.

• Seorang debugger IDE memungkinkan Anda melihat nilai variabel yang tidak Anda tahu ingin Anda lihat ketika eksekusi dimulai.

• Sebuah debugger IDE memungkinkan Anda melihat tumpukan panggilan dan memeriksa status fungsi yang melewati nilai aneh. (pikir fungsi ini dipanggil dari ratusan tempat, Anda tidak tahu dari mana nilai-nilai aneh ini berasal)

• Seorang debugger IDE memungkinkan Anda menghentikan eksekusi secara kondisional pada titik mana pun dalam kode, berdasarkan kondisi, bukan nomor baris.

• Seorang debugger IDE akan membiarkan Anda memeriksa keadaan program dalam kasus pengecualian yang tidak tertangani alih-alih hanya omong kosong.

Inilah satu hal yang Anda tidak dapat men-debug dengan pernyataan "cetak", yaitu ketika seorang pelanggan membawa Anda memori dump dan mengatakan "program Anda macet, dapatkah Anda memberi tahu saya alasannya?"

• Mencetak pernyataan melalui kode Anda mengurangi keterbacaan.
• Menambahkan dan menghapusnya hanya untuk keperluan debug saja memakan waktu
• Debuggers melacak tumpukan panggilan sehingga mudah untuk melihat di mana Anda berada
• Variabel dapat dimodifikasi dengan cepat
• Perintah adhoc dapat dieksekusi selama jeda dalam eksekusi untuk membantu mendiagnosis
• Dapat digunakan DALAM CONJUNCTION dengan pernyataan cetak: Debug.Write ("...")

Saya pikir debugging menggunakan pernyataan cetak adalah seni yang hilang, dan sangat penting untuk dipelajari setiap pengembang. Setelah Anda tahu cara melakukannya, kelas bug tertentu menjadi lebih mudah untuk di-debug dengan cara itu daripada melalui IDE. Programmer yang mengetahui teknik ini juga memiliki perasaan yang sangat baik tentang informasi apa yang berguna untuk dimasukkan ke dalam pesan log (belum lagi Anda benar-benar akan akhirnya membaca log) untuk keperluan non-debugging juga.

Yang mengatakan, Anda benar-benar harus tahu cara menggunakan debugger step-through, karena untuk kelas bug yang berbeda itu WAY lebih mudah. Saya akan menyerahkannya ke jawaban bagus lainnya yang sudah diposting untuk menjelaskan alasannya :)

Dari atas kepala saya:

1. Debugging objek yang kompleks - Debuggers memungkinkan Anda untuk masuk jauh ke jeroan objek. Jika objek Anda memiliki, katakanlah, array dari objek yang kompleks, pernyataan cetak hanya akan membuat Anda sejauh ini.
2. Kemampuan untuk melangkah melewati kode - Debuggers juga akan memungkinkan Anda untuk melewati kode yang tidak ingin Anda laksanakan. Benar, Anda bisa melakukan ini secara manual juga, tetapi lebih banyak kode yang harus Anda suntikkan.

Sebagai alternatif untuk men-debug dalam IDE, Anda dapat mencoba ekstensi Google Chrome ekstensi PHP yang bagus dengan pustaka php yang memungkinkan untuk:

• Lihat kesalahan & pengecualian di konsol JavaScript Chrome & di sembulan pemberitahuan.
• Buang semua variabel tipe.
• Jalankan kode PHP dari jarak jauh.
• Lindungi akses dengan kata sandi.
• Log konsol grup berdasarkan permintaan.
• Langsung ke file kesalahan: baris di editor teks Anda.
• Salin data kesalahan / debug ke clipboard (untuk penguji).

Saya belum mengembangkan selama hampir 20 tahun, tetapi saya menemukan bahwa dengan menggunakan IDE / debugger saya dapat:

• lihat semua hal yang mungkin tidak terpikirkan oleh saya dalam pernyataan cetak
• langkah melalui kode untuk melihat apakah itu cocok dengan jalur yang saya pikir akan diambil
• atur variabel ke nilai tertentu untuk membuat kode mengambil cabang tertentu

Salah satu alasan untuk menggunakan IDE mungkin karena IDE modern mendukung lebih dari sekadar breakpoint. Misalnya, Visual Studio menawarkan fitur debugging canggih berikut:

• mendefinisikan breakpoint bersyarat (break hanya jika suatu kondisi terpenuhi, atau hanya pada waktu ke-n pernyataan di breakpoint dieksekusi)
• istirahat pada pengecualian yang tidak tertangani atau setiap kali eksesepsi (spesifik) akan dilemparkan
• ubah variabel saat debugging
• mengulangi sepotong kode dengan mengatur baris berikutnya yang akan dieksekusi
• dll.

Juga, saat menggunakan debugger, Anda tidak perlu menghapus semua pernyataan cetak setelah Anda selesai debugging.

Satu hal yang saya terkejut saya belum melihat jawaban lain adalah bahwa 2 metode debugging tidak saling eksklusif .

printfdebugging dapat bekerja dengan sangat baik bahkan jika Anda menggunakan debugger standar (apakah berbasis IDE atau tidak). Terutama dengan kerangka logging sehingga Anda dapat meninggalkan semua atau sebagian besar dalam produk yang dirilis untuk membantu mendiagnosis masalah pelanggan.

Seperti yang dicatat di hampir semua jawaban lain di sini, hal bagus utama tentang debugger standar adalah memungkinkan Anda untuk lebih mudah memeriksa (dan berpotensi mengubah) perincian status program. Anda tidak harus tahu di muka apa yang ingin Anda lihat - semuanya tersedia di ujung jari Anda (kurang lebih).

Dalam pengalaman saya, cetakan sederhana memiliki satu keuntungan besar yang sepertinya tidak ada yang menyebutkan.

Masalah dengan debugger IDE adalah bahwa semuanya terjadi secara real time. Anda menghentikan program pada waktu tertentu, lalu Anda melangkah melalui langkah satu per satu dan tidak mungkin untuk kembali jika Anda tiba-tiba ingin melihat apa yang terjadi sebelumnya. Ini sepenuhnya bertentangan dengan cara kerja otak kita. Otak mengumpulkan informasi, dan secara bertahap membentuk suatu pendapat. Mungkin perlu untuk mengulangi peristiwa beberapa kali dalam melakukannya, tetapi begitu Anda telah melewati titik tertentu, Anda tidak bisa kembali.

Berbeda dengan ini, serangkaian cetakan / logging terpilih memberi Anda "proyeksi spasial dari peristiwa temporal". Ini memberi Anda cerita lengkap tentang apa yang terjadi, dan Anda dapat kembali dan keempat beberapa kali dengan sangat mudah hanya dengan menggulir ke atas dan ke bawah. Mudah untuk menjawab pertanyaan seperti "apakah A terjadi sebelum B terjadi". Itu dapat membuat Anda melihat pola yang bahkan Anda cari.

Jadi menurut pengalaman saya. IDE dan debugger adalah alat yang luar biasa untuk memecahkan masalah sederhana ketika ada sesuatu dalam satu panggilan-stack yang salah, dan menjelajahi kondisi mesin saat ini pada crash tertentu.

Namun, ketika kita mendekati masalah yang lebih sulit di mana perubahan negara secara bertahap terlibat. Di mana misalnya satu algoritma merusak struktur data, yang pada gilirannya menyebabkan kegagalan algoritma. Atau jika kita ingin menjawab pertanyaan seperti "seberapa sering hal ini terjadi", "apakah hal-hal terjadi dalam urutan dan dengan cara yang saya bayangkan terjadi". dll. Kemudian teknik logging / printout "kuno" memiliki keuntungan yang jelas.

Hal terbaik adalah menggunakan teknik mana pun ketika itu paling cocok, misalnya menggunakan penebangan / cetakan untuk mendapatkan beberapa bug, dan berhenti sejenak di breakpoint di mana kita perlu menjelajahi keadaan saat ini lebih detail.

Ada juga pendekatan hybrid. Misalnya, ketika Anda melakukan console.log (objek) Anda mendapatkan widget struktur data dalam log yang dapat Anda kembangkan dan jelajahi lebih detail. Ini sering kali merupakan keuntungan yang jelas dibandingkan dengan log teks "mati".

Karena debugging aplikasi multi-threaded dengan pernyataan cetak akan membuat Anda pisang. Ya, Anda masih bisa melakukannya dengan pernyataan cetak tetapi Anda akan membutuhkan banyak dari itu dan mengurai cetakan berurutan dari pernyataan untuk meniru eksekusi multi-berulir akan membutuhkan waktu yang lama.

Otak manusia hanya satu-threaded sayangnya.

Karena Anda meminta pointer ke buku ... Sejauh debugging Windows berjalan, John Robbins memiliki beberapa edisi buku bagus tentang debugging Windows:

Aplikasi debug untuk Microsoft .NET dan Microsoft Windows

Perhatikan bahwa edisi terbaru ( Debugging Microsoft .NET 2.0 Applications ) adalah .NET saja, jadi Anda mungkin menginginkan yang lebih lama (seperti di tautan pertama) jika Anda ingin debugging kode asli (mencakup .NET dan asli).

Saya pribadi merasa jawabannya sesederhana "A debugger / IDE terintegrasi memberi Anda banyak informasi yang berbeda dengan cepat tanpa perlu menekan perintah. Informasi tersebut cenderung ada di depan Anda tanpa Anda belum memberi tahu apa yang harus dilakukan. menunjukkanmu.

The kemudahan di mana informasi yang dapat diambil adalah apa yang membuat mereka lebih baik daripada hanya debugging baris perintah, atau "printf" debugging.

Keuntungan debugger dibandingkan printf ( perhatikan bukan debugger IDE tetapi debugger apa pun )

1. Dapat mengatur titik pandang. Ini adalah salah satu cara favorit saya untuk menemukan kerusakan memori

2. Dapat men-debug biner yang tidak dapat Anda kompilasi ulang saat ini

3. Dapat men-debug biner yang membutuhkan waktu lama untuk dikompilasi ulang

4. Dapat mengubah variabel dengan cepat

5. Dapat memanggil fungsi dengan cepat

6. Tidak memiliki masalah ketika statemen debug tidak dimatikan dan karenanya masalah waktu tidak dapat di-debug secara akurat

7. Debugger membantu dengan dump inti, mencetak pernyataan, jangan '

Inilah yang paling saya gunakan pada windows debugging VS.NET:

• Panggil tumpukan, yang juga merupakan cara terbaik untuk mengetahui kode orang lain
• Warga & Jam Tangan.
• Jendela langsung, yang pada dasarnya adalah konsol C # dan juga memungkinkan saya mengubah konten variabel, menginisialisasi barang, dll.
• Kemampuan untuk melewati garis, mengatur pernyataan berikutnya untuk dieksekusi di tempat lain.
• Kemampuan untuk mengarahkan kursor ke variabel dan memiliki tool-tip yang menunjukkan kepada saya nilai-nilai mereka.

Singkatnya, ini memberi saya pandangan 360 derajat dari status kode eksekusi saya, bukan hanya jendela kecil.

Tidak pernah menemukan buku yang mengajarkan hal semacam ini, tetapi sekali lagi, tampaknya cukup sederhana, itu cukup banyak WYSIWYG.

• Seorang debugger dapat melampirkan ke proses yang sedang berjalan

• Seringkali lebih mudah untuk men-debug kode berulir dari debugger

Dengan debugger IDE, Anda dapat melihat nilai-nilai SEMUA variabel dalam lingkup saat ini (sepanjang tumpukan panggilan) setiap kali Anda menghentikan eksekusi.

Laporan cetak dapat menjadi besar tetapi membuang begitu banyak informasi ke layar di setiap tempat tertentu dapat menghasilkan seluruh banyak laporan cetak.

Juga, banyak debugger IDE memungkinkan Anda mengetik dan mengevaluasi metode, dan mengevaluasi anggota saat Anda dihentikan, yang selanjutnya menambah jumlah pernyataan cetak yang harus Anda lakukan.

Saya merasa bahwa para penentang lebih baik untuk beberapa bahasa daripada yang lain namun ...

Pendapat umum saya adalah bahwa debugger IDE benar-benar, luar biasa indah untuk bahasa yang dikelola seperti Java atau C #, cukup berguna untuk C ++, dan tidak terlalu berguna untuk bahasa scripting seperti Python (tapi bisa jadi saya hanya belum mencoba yang baik debugger untuk bahasa skrip apa pun).

Saya sangat suka debugger di IntelliJ IDEA ketika saya melakukan pengembangan Java. Saya hanya menggunakan pernyataan cetak ketika saya menggunakan Python.

Seperti seseorang berkata di atas: Debugger! = IDE.

gdb dan (kembali pada hari itu) TurboDebugger (berdiri sendiri) berfungsi dengan baik untuk bahasa yang mereka dukung [ed], terima kasih. (atau teknologi yang bahkan lebih tua: Clipper debugger yang ditautkan ke xBase dapat dieksekusi sendiri) - tidak ada yang memerlukan IDE

Juga, meskipun coding C / ++ lebih jarang, pernyataan printf terkadang menutupi bug yang Anda coba temukan! (masalah inisialisasi dalam vars otomatis pada stack, misalnya, atau alokasi / penyelarasan memori)

Akhirnya, seperti yang dinyatakan orang lain, Anda dapat menggunakan keduanya. Beberapa masalah waktu nyata hampir memerlukan cetakan, atau setidaknya "* video_dbg = (is_good? '+': '-') yang bijaksana; suatu tempat ke dalam memori video. Umur saya menunjukkan, ini di bawah DOS :-)

TMTOWTDI

Selain banyak dari apa yang dikatakan poster-poster lain, saya sangat suka melangkah melalui satu baris pada satu waktu bersama dengan komputer, karena itu memaksa saya untuk memikirkan satu baris pada suatu waktu. Seringkali saya akan menangkap bug tanpa melihat nilai variabel hanya karena saya terpaksa melihatnya ketika saya mengklik tombol 'baris berikutnya'. Namun, saya pikir jawaban saya tidak akan membantu Anda, Bill, karena Anda mungkin sudah memiliki keterampilan ini.

Sejauh sumber belajar berjalan, saya belum pernah menggunakan - saya hanya menjelajahi semua menu dan opsi.

Apakah ini bahkan pertanyaan nyata dari programmer sejati?

Siapa pun yang menghabiskan waktu 5 menit untuk debugging dengan pernyataan cetak dan debugging dengan IDE - itu akan TERJADI padanya tanpa bertanya!

Saya telah menggunakan cetakan dan IDE untuk debugging dan saya lebih suka debug menggunakan IDE. Satu-satunya waktu bagi saya ketika itu tidak berhasil adalah dalam situasi kritis waktu (seperti men-debug game online) di mana Anda membuang kode dengan pernyataan cetak dan kemudian melihat file log setelah salah. Kemudian jika Anda masih tidak bisa mengetahuinya, tambahkan lebih banyak cetakan dan ulangi.

Hanya ingin menyebutkan fitur yang berguna dari konsol debugger vs printf dan vs debugger di IDE.

Anda dapat melampirkan ke aplikasi jarak jauh (jelas, dikompilasi dalam mode DEBUG) dan memeriksa statusnya membuang output debugger ke file menggunakan teeutilitas POSIX . Dibandingkan dengan printf, Anda dapat memilih tempat mengeluarkan status dalam waktu berjalan.

Ini sangat membantu saya ketika saya sedang debugging aplikasi Adobe Flash yang digunakan dalam lingkungan yang agresif . Anda hanya perlu mendefinisikan beberapa tindakan yang mencetak status yang diperlukan di setiap breakpoint, mulai dengan debugger konsol fdb | tee output.log, dan berjalan melalui beberapa breakpoints. Setelah itu Anda dapat mencetak log dan menganalisis informasi dengan membandingkan keadaan secara menyeluruh di breakpoint yang berbeda.

Sayangnya, fitur ini [masuk ke file] jarang tersedia di debugger GUI, membuat pengembang membandingkan keadaan objek di kepala mereka.

Ngomong-ngomong, pendapat saya adalah bahwa seseorang harus merencanakan di mana dan apa yang harus di-debug sebelum menatap debugger.

Nah hal lain adalah bahwa jika Anda bergabung dengan proyek lama baru dan tidak ada yang benar-benar tahu bagaimana kode melakukan apa yang dilakukannya, maka Anda tidak dapat men-debug dengan menggemakan variabel / objek / ... b / c Anda tidak tahu kode apa itu dieksekusi sama sekali.

Di pekerjaan saya, saya menghadapi situasi semacam itu dan visual XDebuging membantu saya mendapatkan ide tentang apa yang sedang terjadi dan di mana, sama sekali.

salam Hormat

Raffael

Selain banyak hal yang telah disebutkan, salah satu keuntungan terpenting dari debugger dibandingkan printf adalah menggunakan pernyataan printf mengasumsikan bahwa Anda tahu di mana fungsi bug tersebut berada. Dalam banyak kasus Anda tidak, jadi Anda harus membuat beberapa tebakan dan menambahkan pernyataan cetak ke banyak fungsi lain untuk melokalisasikannya. Bug mungkin ada dalam kode kerangka kerja atau di suatu tempat yang jauh dari tempat Anda pikir itu. Dalam debugger, jauh lebih mudah untuk mengatur breakpoint untuk memeriksa keadaan di berbagai area kode dan pada titik waktu yang berbeda.

Juga, debugger yang layak akan membiarkan Anda melakukan debugging gaya printf dengan melampirkan kondisi dan tindakan ke breakpoint, sehingga Anda masih mempertahankan manfaat debugging printf, tetapi tanpa memodifikasi kode.

Debugging dalam IDE sangat berharga dalam lingkungan di mana log kesalahan dan akses shell tidak tersedia, seperti host bersama. Jika demikian, IDE dengan debugger jarak jauh adalah satu-satunya alat yang memungkinkan Anda untuk melakukan hal-hal sederhana seperti tampilan stderratau stdout.

Masalah dengan menggunakan pernyataan cetak adalah membuat kode Anda berantakan. IE, Anda memiliki fungsi dengan 10 bagian untuk itu dan Anda tahu itu crash di suatu tempat, tetapi Anda tidak yakin di mana. Jadi, Anda menambahkan 10 pernyataan cetak tambahan untuk menunjukkan di mana bug itu berada. Setelah Anda menemukan dan menyelesaikan bug Anda, sekarang Anda harus membersihkan dengan menghapus semua pernyataan cetak itu. Mungkin Anda akan melakukannya. Mungkin Anda akan lupa dan itu akan berakhir dalam produksi dan konsol pengguna Anda akan penuh dengan cetakan debug.

Wauw, apakah saya suka pertanyaan ini. Saya tidak pernah berani berpose ...

Tampaknya orang hanya memiliki cara kerja yang berbeda. Bagi saya yang paling berhasil adalah:

• Memiliki model pikiran yang solid dari kode saya, termasuk manajemen memori
• Menggunakan instrumentasi (seperti pernyataan cetak) untuk mengikuti apa yang terjadi.

Saya telah mendapatkan pemrograman hidup saya selama lebih dari 40 tahun sekarang, bekerja di aplikasi teknis dan ilmiah non-sepele dalam C ++ dan Python setiap hari, dan saya memiliki pengalaman pribadi bahwa seorang debugger tidak sedikit membantu saya.

Saya tidak mengatakan itu bagus. Saya tidak mengatakan itu buruk. Saya hanya ingin membagikannya.

Bukan hanya debugging. Sebuah IDE membantu Anda membangun perangkat lunak yang lebih baik dengan lebih cepat dalam banyak cara:

• alat refactoring
• intellisense untuk membuat api lebih mudah ditemukan, atau mengingatkan ejaan / kasus yang tepat dari barang yang sudah dikenal (tidak banyak digunakan jika Anda telah menggunakan sistem yang sama selama 15 tahun, tapi itu jarang terjadi)
• menghemat pengetikan dengan nama variabel dan kelas pelengkapan otomatis
• temukan beberapa jenis kesalahan bahkan sebelum Anda mulai mengkompilasi
• Secara otomatis beralih ke deklarasi / definisi variabel / metode / kelas, meskipun tidak dalam file atau folder yang sama.
• Hentikan pengecualian yang tidak ditangani dan ditangani

Saya bisa melanjutkan.