[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é.