[Visual Studio] Fighting with Bugs and Exceptions
Lập trình bằng Visual Studio, tới một thời điểm nào đó ai cũng sẽ gặp bug và Exception. Đối với một số exception, Visual Studio sẽ bôi vàng đoạn code gây ra exception, nhưng đối với một số exception khác, Visual Studio lại nhảy hẳn ra ngoài. Vì sao vậy? Tại sao không cho tôi biết code chỗ nào bị lỗi.
Visual Studio 2015 có một cải tiến đáng giá giúp lập trình viên biết chính xác chỗ code nào bị exception, và một số cải tiến vô cùng đáng giá khác khi debug một đoạn code
1. Advanced Debugging
Tất cả mọi người đều biết, để debug một đoạn code, bạn thường đặt một break point. Khi code chạy tới đó, nó sẽ dừng ngay tại Breakpoint đó. The end. Hết phim. Tuy nhiên, nếu bạn đọc bài blog này: [Visual Studio] Performance, performance, performance (with the help of Visual Studio “PerfTips”), bạn sẽ thấy một công dụng nữa của Breakpoint dành cho việc đo đạc thời gian chạy một đoạn code. Ngoài ra, Breakpoint còn có một số công dụng khác nữa
1.1. Output Log with Breakpoint
Trong vòng lặp trên, bạn sẽ thấy có dòng “Debug.WriteLine” dùng để xuất một thông tin gì đó ra màn hình Output. Thông tin này sẽ giúp bạn biết code đã chạy tới dòng này, và xuất ra các giá trị mà bạn mong muốn.
Từ giờ, bạn không cần phải làm thủ công như vậy nữa.
Đưa chuột lại gần Breakpoint, một menu nhỏ xíu hiện ra, nhấn vào dấu răng cưa
Một cái cửa sổ hiện ra, chèn vào giữa đoạn code đặt breakpoint của bạn. Tick chọn ô Action. Bạn sẽ thấy tính năng “Log a message to output Windows”
Gõ vào trong ô đó những thứ bạn muốn xuất ra cửa sổ output. Biến thì để trong dấu ngoặc nhọn. Thế là xong
Khi chạy lại app, cửa sổ output sẽ là
Bạn thấy con số nằm trong ngoặc kép là vì nó là kiểu string, không phải int. Nên khi hiển thị, Visual Studio sẽ đưa nó vào trong ngoặc kép
Bây giờ, hãy so sánh một chút
Breakpoint “Action” | Debug.WriteLine() | |
---|---|---|
Lợi | Nhanh chóng, đơn giản Không thay đổi code Có thể chỉnh sửa khi ứng dụng đang chạy Có thể kết hợp với Condition của Breakpoint Có thể quản lý tập trung trong cửa sổ Debug |
Sử dụng linh hoạt Trực quan, dễ hiểu Có thể chèn nhiều dòng |
Bất lợi | Chỉ xuất ra được 1 dòng (mình chưa tìm được cách xuống dòng) | Phải thay đổi code Không thể chỉnh sửa khi app đang chạy Dùng Debug.WriteLineIf() để thêm điều kiện Muốn tìm phải dùng Ctrl + F để tìm kiếm phrase như thông thường Giảm hiệu suất (không đáng kể, và không ảnh hưởng khi Release) |
1.2. Condition Breakpoint
Tiếp tục tick chọn ô Condition, cửa sổ được mở rộng ra để lộ nhiều tùy chọn hơn cho bạn
Bạn có nhiều tùy chọn để quyết định xem là Visual Studio có dừng lại ở Breakpoint này hay không. Trong số đó có
Conditional Expression: Biểu thức điều kiện: Sẽ dừng ở breakpoint khi điều kiện đúng
Hit Count: Số lần chạy qua: Cứ mỗi lần chạy qua breakpint này, Visual Studio sẽ tính là một hit. Khi đạt tới số lượng hit nhất định do bạn đặt thì sẽ dừng.
Filter: Sẽ dừng ở Breakpoint khi một số điều kiện đặc biệt được thỏa mãn (ví dụ như MachineName, ProcessId, vân vân)
Đối với App Windows, bạn sẽ cần dùng 2 cái đầu tiên nhiều nhất
Giả sử mình muốn dừng lại ở lần chạy thứ 9, và xuất ra màn hình biến ở lần chạy này, thì thiết lập như sau:
2. The new Exception Settings
Đã bao giờ bạn gặp phải cái lỗi ở cái dòng lạ hoắc như vầy chưa?
DISABLE_XAML_BREAK_ON_UNHANDLED_EXCEPTION
Global::System.Diagnostics.Debugger.Break();
Cái này là gì
Hoặc lỗi như vầy
“An exception of type “Blah blah blah” occurred in Yourappname.exe but was not handled in user code”, và kèm theo đó là Visual Studio dừng ở một dòng lạ hoắc, và bạn biết chắc chắn là lỗi xảy ra ở chỗ khác, không phải dòng này.
Đó là lý do ta sẽ dùng Exception Setting để nhảy tới đúng chỗ code sinh ra lỗi
Bạn vào Debug > Windows > Exception Settings…
Copy tên của Exception, trong trường hợp trên là “System.Exception” và paste nó vào ô tìm kiếm. Tíck chọn kết quả hiện ra
Chạy lại app. Và bây giờ, Visual Studio sẽ nhảy tới đúng dòng bị lỗi
Quá tuyệt, phải không
Đón xem các bài blog tiếp theo về các tính năng cực kute của Visual Studio nhé.