Tại sao các lập trình viên mới dường như bỏ qua các thông báo lỗi trình biên dịch / thông báo ngoại lệ thời gian chạy? [đóng cửa]

Tôi nghĩ rằng tất cả chúng ta đã thấy điều này. Người mới bắt đầu đặt câu hỏi về Stack Overflow theo phác thảo cơ bản ...

Tôi đang cố gắng thực hiện (mô tả rất mơ hồ về mục tiêu) nhưng nó không hoạt động / Tôi gặp lỗi / ngoại lệ. Hãy giúp tôi!

Có phải thật kỳ lạ khi rất nhiều người trong số họ dường như cho rằng không cần thiết phải dán thông báo lỗi không?

Tôi tự hỏi tâm lý của việc này là gì. Điều gì về thông báo lỗi khiến mọi người ban đầu cho rằng chúng vô dụng và không đáng để ý đến?

Câu trả lời tôi đang tìm kiếm không phải là họ, họ không hiểu thông báo lỗi. Điều đó không giải thích tại sao họ không xem xét việc nói cho bất kỳ ai khác có thể hiểu nó.

Tôi nghĩ lý do thực sự là người dùng máy tính bình thường, ngay cả khi họ nên tiếp tục trở thành lập trình viên, có điều kiện để tin rằng họ không thể làm gì về lỗi. Hãy suy nghĩ về nó. Các loại không lập trình viên làm gì khi gặp thông báo lỗi khó hiểu *? Họ có thể đọc nó, nhưng chín lần trong số mười họ sẽ đơn giản bỏ qua nó và thử lại. Chỉ khi nó liên tục thất bại, họ sẽ tìm kiếm nó.

Do đó, khi bắt đầu tìm hiểu cách lập trình, mọi người không nhận ra ngay rằng lỗi họ gặp phải chứa thông tin hữu ích về cách sửa lỗi; và phải, mặc dù các lỗi trình biên dịch có thể không thể đọc được ngay cả với chuyên gia được đào tạo (tôi đang nhìn vào bạn, lập trình siêu mẫu mẫu C ++), ít nhất là chúng cung cấp một điểm bắt đầu chung và một khi bạn đã gặp lỗi tương tự một vài lần , bạn sẽ luôn biết những gì bạn đã làm để gây ra nó.

* Thành thật mà nói, hầu hết các thông báo lỗi đều tìm đến Joe Average như "Lỗi X2412: Không thể thiết lập dongledash liên kết frobnicatory: vui lòng xác minh cài đặt bandersnatch hoặc liên hệ với quản trị viên hệ thống của bạn."

Tôi nghĩ rằng nếu đó là một người mới bắt đầu thực sự thì rất có thể họ không biết có một thông báo lỗi nào cả. Họ chỉ biết nó không chạy và có lỗi. Ví dụ trong Visual studio họ có thể không thấy phần đó của màn hình.

Về cơ bản họ không biết phần nào của thông tin họ có sẵn là hữu ích để tìm ra vấn đề là gì. Nếu họ đã làm thì sẽ có cơ hội tốt hơn họ có thể tự sửa nó và không hỏi về nó ngay từ đầu.

Tôi nghĩ rằng đặt câu hỏi và xử lý sự cố là một kỹ năng cần phải học và đối với các nhà phát triển chuyên nghiệp, đó là một kỹ năng quan trọng mà đơn giản là không được dạy thường xuyên.

Giống như mã bạn viết khi bạn mới bắt đầu vào nghề này sẽ rất kinh khủng so với mã bạn viết ngày hôm nay, những câu hỏi bạn hỏi sẽ rất tệ so với cách bạn hỏi họ ngày hôm nay.

Khi bạn bắt đầu, thật dễ bị choáng ngợp bởi tất cả thông tin mà bạn đang học và khi mọi thứ không có kế hoạch, thật khó để biết thông tin nào có liên quan và thông tin nào không. Đây là một phần lớn lý do tại sao người mới bắt đầu không thể tự giải quyết vấn đề!

Điều này áp dụng nhiều hơn trên IRC so với các trang web trực tuyến như Stack Overflow, điều này hiếm hơn nhiều.

Tôi nghĩ lý do đằng sau đó là mọi người cảm thấy tốt hơn nếu họ biết rằng một người đặc biệt quan tâm đến vấn đề của họ và sẵn sàng giúp đỡ họ. Vì vậy, họ bắt đầu bằng cách nói rằng họ có vấn đề, nhưng họ không đi sâu vào chi tiết cho đến khi có ai đó hỏi họ, vì họ sợ rằng nếu không họ sẽ không nhận được câu trả lời nào.

Đôi khi (không phải trong trường hợp lỗi trình biên dịch) hành vi này thực sự có ý nghĩa. Nếu tôi gặp vấn đề phức tạp lớn, tôi sẽ đảm bảo có ai đó lắng nghe trước khi viết một lời giải thích dài mà không ai sẽ đọc.

Bởi vì lỗi / ngoại lệ của trình biên dịch yêu cầu bạn biết bạn đang làm gì sai để sửa nó. Chúng dành cho các lập trình viên bỏ qua công cụ, không dành cho những người không hiểu chúng.

Chúng cũng không phải lúc nào cũng rõ ràng nhất. Một lỗi như "không mong muốn nếu" không trực quan. "Nhưng nếu nên ở đó" là câu trả lời của một người mới. Một lập trình viên có kinh nghiệm hơn biết rằng điều đó có nghĩa anh ấy quên mất dấu chấm phẩy trên preceeding dòng.

Tôi không nghĩ đó chỉ là người mới. Tôi có những đồng nghiệp có nhiều năm kinh nghiệm, những người dường như chỉ nhìn vào số dòng khi họ gặp lỗi trình biên dịch, sau đó cố gắng tự tìm ra phần còn lại (thường bằng cách thử voodoo như "hãy thêm dấu ngoặc đơn" hoặc "hãy phá vỡ điều này thành hai tuyên bố ").

Sự nghi ngờ của tôi là điều này xuất phát từ việc không thực sự hiểu sâu về các quy tắc của ngôn ngữ, do đó mô tả chung về lỗi này không có nhiều ý nghĩa. expression must be a modifiable lvaluecó vẻ như thông tin khá vô dụng nếu bạn thực sự không biết giá trị là gì.

Điều gì về thông báo lỗi khiến mọi người ban đầu cho rằng chúng vô dụng và không đáng để ý đến?

Đối với tôi, đó là một thanh niên chứa đầy phần mềm Windows 95 bị lỗi với các thông báo lỗi hoàn toàn không thể xuyên thủng, thường kết thúc với khoảng 150 dòng hexadecimals.

Tôi sống lại trải nghiệm tương tự mỗi khi tôi nhận được một dấu vết ngăn xếp Java khó hiểu sẽ chứa 40 dòng lỗi trình biên dịch và lỗi Hibernate và ẩn rất rõ trong số đó là tham chiếu thực tế về lỗi trong ứng dụng của tôi.

Lý do mọi người bỏ qua các thông báo lỗi và dấu vết ngăn xếp thường là các thông báo lỗi và dấu vết ngăn xếp phức tạp không tương xứng so với mức độ phức tạp của vấn đề. Không có lý do gì để tuôn ra 150 dòng tào lao qua màn hình của tôi khi tôi bỏ lỡ một dấu chấm phẩy.

Tôi đang giảng dạy một số khóa học về Linux cho Junior Sysadins và Lập trình với PHP và Mysql. Phần lớn sinh viên trên PHP biết có lỗi vì họ thấy thông báo xấu xí trên màn hình. Nhưng dường như họ không thể đọc nó. Thông thường tôi đi đến màn hình của họ khi họ nói với tôi điều gì đó không hoạt động, tôi đọc lỗi trên màn hình, bảo họ đọc nó, nhấn mạnh vào tập tin và dòng ghi chú về lỗi và bảo họ nhìn vào đó. Họ sửa lỗi, nhưng khi một lỗi khác xuất hiện, quy trình tương tự được áp dụng ... thở dài ...

Đối với khóa học Linux, đôi khi họ thậm chí không nhận thấy lỗi. Họ nhập một số lệnh, một số dòng xuất hiện trên màn hình và tiếp tục với lệnh tiếp theo. Khi một số lệnh sau đó cuối cùng chúng nhận thấy có gì đó không hoạt động và giơ tay, tôi đến, cuộn lên bàn điều khiển và chỉ ra một lệnh đã thoát với lỗi do tham số xấu hoặc bất cứ điều gì. Khuôn mặt của họ: bất ngờ. Vì vậy, phần dễ dàng cho các sinh viên linux của tôi là làm cho họ chú ý khi xảy ra lỗi, sử dụng một số sửa đổi của dấu nhắc bash để làm cho nó khác đi khi xuất hiện lỗi, như lỗi này . Bây giờ, hãy để họ đọc thông báo lỗi khi họ thấy nó, đó là một trận chiến khác (giống như với các sinh viên PHP) ...

Tôi tin rằng họ chỉ không quen nghĩ về mã lỗi và đến khi họ đến nơi họ nên đưa cho họ, họ đã cảm thấy như họ đã giải thích đầy đủ vấn đề, và do đó thậm chí ít dừng lại và suy nghĩ về việc liệu họ nên cung cấp thêm thông tin.

Đặt câu hỏi liên quan đến một vài giai đoạn và chúng được sắp xếp hợp lý nhất theo thứ tự này:

1. bạn cần mô tả những gì bạn đang làm
2. bạn cần mô tả cách bạn đã làm điều đó
3. bạn cần mô tả những gì đã xảy ra khi nó thất bại (hoặc nó thất bại như thế nào)
4. bạn cần đưa ra báo cáo tử thi

Báo cáo khám nghiệm tử thi là nơi thông báo lỗi sẽ ở cuối và nó ở cuối. Vào thời điểm những người mới đến thời điểm này, họ đang ở cuối thử thách tinh thần để giải thích vấn đề của họ và có nhiều khả năng bỏ lỡ điều gì đó (đối với một người mới, có vấn đề quá tải thông tin). Hơn nữa, tại thời điểm này, họ đã cảm thấy như họ đã mô tả tất cả các khía cạnh của vấn đề và họ có những thói quen trong quá khứ khiến họ không nhớ về các mã lỗi: sau tất cả, các lĩnh vực khác của cuộc sống không có mã lỗi, vì vậy họ không quen nghĩ về họ

Nó cũng có thể là ngay cả khi họ nhớ về các mã lỗi, họ dường như quá khó hiểu để sử dụng thực tế. Chỉ cần lỗi 034982 là gì? Điều này thực sự có ý nghĩa gì với bất cứ ai? Và nó có thực sự thêm một cái gì đó vào mô tả chi tiết về những gì tôi đã làm, cách tôi đang làm và làm thế nào nó thất bại? Chắc chắn thông tin này là viết tắt của chính nó.

Bởi vì đối với hầu hết các ngôn ngữ, hầu hết các thông báo trình biên dịch / thời gian chạy không có ý nghĩa gì. (Đặc biệt là C ++ và Java, tôi đang xem xét bạn!) Nhận được các lỗi đúng có xu hướng khá thấp trong danh sách ưu tiên của nhà thiết kế ngôn ngữ. Làm cho mọi thứ hoạt động tốt để làm việc đúng thường là một ưu tiên lớn hơn và rất nhiều thời gian họ không bận tâm với việc đánh bóng các chi tiết nhỏ.

Đó là một trong những lý do tại sao tôi thích làm việc ở Delphi. Toàn bộ ngôn ngữ đầy chú ý đến các chi tiết nhỏ, bao gồm các lỗi. Trình biên dịch tin nhắn có ý nghĩa. Thông báo lỗi thời gian chạy có ý nghĩa. Dấu vết ngăn xếp có ý nghĩa. Đó là một trong những điều làm cho nó, cho đến nay, ngôn ngữ dễ gỡ lỗi nhất mà tôi từng làm việc cùng.