Thông báo lỗi là lời chỉ đường, không phải lời mắng. Hãy đọc dòng mô tả lỗi trước, rồi trong chuỗi các bước gọi nhau được in ra, tìm dòng đầu tiên thuộc mã của chính bạn. Và khi có nhiều lỗi, lỗi đầu tiên thường là lỗi thật, những lỗi sau chỉ là hệ quả của nó.
Chào bạn, đây là Nhà Lập Trình. Mình từng dạy kèm vài bạn mới học và thấy một phản xạ chung: màn hình hiện một khối chữ đỏ, bạn ấy lập tức cuộn qua hoặc chép hết dán lên mạng hỏi. Không ai đọc nó. Tập này mình muốn thay đổi phản xạ đó, vì đọc thông báo lỗi đúng cách giải quyết được phần lớn lỗi mà không cần hỏi ai.
Vì sao người mới sợ thông báo lỗi?
Thông báo lỗi thường dài, toàn tiếng Anh, đầy tên tệp và số dòng lạ hoắc. Với người mới, nó trông như một bức tường chữ. Và nó mang màu đỏ, màu của sai, của bị phạt.
Cảm giác đó đến từ trường học. Ở trường, bài làm có lỗi nghĩa là bị trừ điểm. Trong lập trình, lỗi là chuyện hằng ngày, xảy ra hàng chục lần mỗi giờ với cả người giỏi nhất. Máy tính báo lỗi không phải để chê bạn, mà để giúp bạn.
Hãy thử nghĩ khác đi: thông báo lỗi là máy tính đang cố nói với bạn nó bị kẹt ở đâu và vì sao. Nó không nói được tiếng người, nhưng nó cố gắng hết sức. Việc của bạn là học ngôn ngữ của nó.
Và tin vui là ngôn ngữ đó khá có quy luật. Học cách đọc một lần, bạn đọc được hầu hết thông báo lỗi của cùng một ngôn ngữ.
Ba phần của một thông báo lỗi
Phần lớn thông báo lỗi có ba phần. Phần thứ nhất là loại lỗi: một cái tên ngắn cho biết đây là loại vấn đề gì, như không tìm thấy tệp, sai kiểu dữ liệu, truy cập vào thứ không tồn tại, chia cho không.
Phần thứ hai là mô tả: một câu giải thích cụ thể hơn. Không tìm thấy tệp nào, sai kiểu ở đâu, mong đợi một con số nhưng nhận được chữ. Đây thường là phần quý nhất, và cũng là phần người mới hay bỏ qua nhất.
Phần thứ ba là chuỗi các bước gọi nhau dẫn tới lỗi, người trong nghề hay gọi là dấu vết ngăn xếp. Nó liệt kê hàm nào gọi hàm nào, ở tệp nào, dòng số mấy, cho tới chỗ lỗi xảy ra. Đây là phần dài nhất và đáng sợ nhất.
Thứ tự đọc của mình là: loại lỗi và mô tả trước, dấu vết sau. Rất nhiều lần, chỉ riêng câu mô tả đã đủ để biết cần sửa gì.
Tìm dòng đầu tiên thuộc về bạn
Dấu vết ngăn xếp thường dài vì chương trình của bạn gọi vào thư viện, thư viện gọi vào thư viện khác, và lỗi có thể nổ ra sâu bên trong mã của người khác. Người mới nhìn thấy tên tệp của thư viện ở dòng trên cùng, tưởng thư viện bị lỗi.
Thực tế, thư viện được hàng nghìn người dùng hằng ngày hiếm khi là thủ phạm. Thủ phạm thường là cách bạn gọi nó: truyền sai tham số, gọi sai thứ tự, truyền dữ liệu rỗng.
Nên hãy dò trong dấu vết để tìm dòng đầu tiên thuộc về mã của chính bạn, tức là tệp trong thư mục dự án của bạn. Đó là chỗ bạn đã gọi vào thư viện. Mở dòng đó ra, xem bạn đã truyền gì vào.
Tuỳ ngôn ngữ, dấu vết có thể in từ trên xuống hay từ dưới lên, chỗ lỗi xảy ra có thể ở đầu hoặc ở cuối. Hãy tìm hiểu ngôn ngữ của bạn in theo chiều nào. Chỉ cần biết một lần là nhớ mãi.
Lỗi đầu tiên mới là lỗi thật
Khi trình biên dịch hay công cụ kiểm tra báo ra ba mươi lỗi cùng lúc, người mới hoảng loạn và bắt đầu sửa từ lỗi cuối cùng, hoặc lỗi trông dễ nhất. Đừng làm vậy.
Rất thường, chỉ có một lỗi thật ở đầu, ví dụ thiếu một dấu đóng ngoặc. Vì thiếu dấu đó, toàn bộ phần mã phía sau bị hiểu sai, và công cụ báo ra hai mươi chín lỗi khác, tất cả đều là hệ quả. Sửa lỗi đầu tiên, chạy lại, có khi hai mươi chín lỗi kia biến mất.
Điều tương tự xảy ra với lỗi khi chạy. Nhật ký có thể đầy lỗi, nhưng hãy tìm lỗi xảy ra sớm nhất về thời gian. Một kết nối cơ sở dữ liệu thất bại lúc tám giờ sáng sẽ kéo theo hàng trăm lỗi không đọc được dữ liệu sau đó. Sửa hàng trăm lỗi kia là vô ích.
Quy tắc đơn giản: sửa từ trên xuống, từ sớm đến muộn, và chạy lại sau mỗi lần sửa.
Khi thông báo lỗi thật sự khó hiểu
Không phải thông báo lỗi nào cũng rõ. Có cái mơ hồ, có cái sai lạc, có cái chỉ nói có lỗi xảy ra mà không nói gì thêm. Khi đó, hãy chép phần chính của thông báo, bỏ đi những phần riêng của máy bạn như đường dẫn, tên biến riêng, rồi tìm kiếm trên mạng. Khả năng rất cao ai đó đã gặp.
Khi đọc kết quả tìm kiếm, chú ý phiên bản. Một câu trả lời cho phiên bản cũ nhiều năm trước có thể không còn đúng.
Nếu vẫn không ra, hãy quay lại quy trình gỡ lỗi cơ bản: tái hiện, thu hẹp, quan sát. Thông báo lỗi chỉ là một manh mối, không phải manh mối duy nhất.
Và khi chính bạn viết mã báo lỗi cho người khác, hãy nhớ lại cảm giác đọc một thông báo khó hiểu. Viết thông báo nói rõ điều gì sai, sai với giá trị nào, và nếu được thì gợi ý cách sửa. Người đọc sau, có khi chính là bạn, sẽ cảm ơn.
Câu hỏi thường gặp
Dấu vết ngăn xếp là gì?
Là danh sách các hàm đang gọi nhau tại thời điểm lỗi xảy ra, kèm tên tệp và số dòng. Nó cho biết chương trình đã đi đường nào để tới chỗ lỗi.
Vì sao lỗi báo ở thư viện mà không phải ở mã của mình?
Vì lỗi nổ ra bên trong thư viện khi xử lý thứ bạn truyền vào. Hãy tìm dòng đầu tiên thuộc mã của bạn trong dấu vết để xem bạn đã gọi thư viện thế nào.
Có nên chép cả thông báo lỗi lên mạng để hỏi không?
Nên chép phần mô tả lỗi chính và đoạn mã liên quan, kèm những gì bạn đã thử. Bỏ đi mật khẩu, khoá bí mật, đường dẫn và thông tin riêng trước khi đăng.
Vì sao sửa một lỗi mà hàng chục lỗi khác cũng hết?
Vì các lỗi kia là hệ quả của lỗi đầu tiên. Ví dụ thiếu một dấu ngoặc làm công cụ hiểu sai toàn bộ phần mã phía sau và báo ra nhiều lỗi giả.
Viết thông báo lỗi cho người khác đọc thế nào cho tốt?
Nói rõ điều gì sai, giá trị nào gây ra, ở đâu, và gợi ý cách sửa nếu có. Tránh những câu chung chung như có lỗi xảy ra mà không kèm thông tin gì.
