Trình biên dịch C# không báo cáo tất cả các lỗi cùng một lúc tại mỗi biên dịch?

Question

Khi tôi biên soạn dự án này, nó hiển thị như 400+ lỗi trong cửa sổ Danh sách lỗi, sau đó tôi truy cập trang lỗi, sửa một số và số đi tới 120 lỗi và sau đó sửa sau biên dịch các báo cáo như 400+ một lần nữa. Tôi có thể thấy rằng các tập tin khác nhau đang đến trong cửa sổ danh sách lỗi, vì vậy tôi nghĩ rằng trình biên dịch hủy bỏ sau một số lỗi nhất định?

Nếu vậy, lý do cho việc này là gì? Nó không phải là thu thập tất cả các lỗi có mặt trong dự án ngay cả khi chúng trên 10K +?

Answer 1

Tôi đã có ý định viết một bài viết blog về điều này.

Có thể bạn chỉ cần chạy vào một số giới hạn được mã hóa cứng cho số lỗi được báo cáo. Nó cũng có thể là bạn đang chạy vào một kịch bản tinh tế và thú vị hơn.

Có rất nhiều phỏng đoán trong trình biên dịch dòng lệnh và trình biên dịch IDE cố gắng quản lý báo cáo lỗi. Cả hai để giữ cho nó dễ quản lý cho người dùng, và để làm cho trình biên dịch mạnh mẽ hơn.

Tóm lại, cách trình biên dịch làm việc là nó cố gắng để có được những chương trình thông qua một loạt các giai đoạn, mà bạn có thể đọc về ở đây:

http://blogs.msdn.com/b/ericlippert/archive/2010/02/04/how-many-passes.aspx

Ý tưởng được rằng nếu giai đoạn đầu được một lỗi, chúng tôi có thể không thể hoàn thành thành công giai đoạn sau mà không (1) đi vào vòng lặp vô hạn, (2) bị lỗi hoặc (3) báo cáo lỗi "xếp tầng" điên. Vì vậy, những gì xảy ra là, bạn nhận được một lỗi, bạn sửa chữa nó, và sau đó đột nhiên giai đoạn tiếp theo của biên dịch có thể chạy, và nó tìm thấy một bó nhiều lỗi hơn. Về cơ bản, nếu chương trình bị rối tung lên đến mức chúng ta thậm chí không thể xác minh sự thật cơ bản về các lớp và phương thức của nó, thì chúng ta không thể cung cấp sai sót một cách đáng tin cậy cho các thân phương pháp. Nếu chúng ta không thể phân tích một cơ thể lambda, thì chúng ta không thể cung cấp sai sót cho việc chuyển đổi của nó thành một cây biểu thức. Và vân vân; có rất nhiều tình huống mà các giai đoạn sau cần phải biết rằng các giai đoạn trước đã hoàn thành không có lỗi.

Mặt khác của thiết kế này là (1) bạn nhận được các lỗi "cơ bản nhất" đầu tiên, không có nhiều lỗi xếp tầng ồn ào, và (2) trình biên dịch mạnh mẽ hơn vì nó không 't phải cố gắng để làm phân tích về các chương trình mà các bất biến cơ bản của ngôn ngữ bị hỏng. Phía bên trái dĩ nhiên là kịch bản của bạn: rằng bạn có năm mươi lỗi, bạn sửa tất cả chúng, và đột nhiên năm mươi xuất hiện nữa.

Answer 2

Đó là cấu hình theo MSDN

Theo mặc định, số lượng tối đa là 200 lỗi và cảnh báo.

Answer 3

Tất nhiên nó sẽ dừng lại ở một thời điểm nào đó.

Ngay cả sau 1 lỗi, tất cả phần còn lại đều không rõ ràng. Một trình biên dịch sẽ cố gắng phục hồi, nhưng điều đó không được đảm bảo để thành công. Vì vậy, trong bất kỳ dự án không tầm thường nào, đó là một quyết định thực tế giữa việc dừng lại ở lỗi đầu tiên (về mặt lý thuyết là điều tốt nhất để làm) và cày cấy ở trạng thái không đáng tin cậy.

Hành động chính xác nhất sẽ dừng sau 1 lỗi, nhưng điều đó sẽ dẫn đến tình huống 'khắc phục sự cố 1 tại một thời điểm' tẻ nhạt. Vì vậy, trình biên dịch sẽ cố gắng đồng bộ hóa lại trạng thái đã biết và báo cáo trạng thái tiếp theo. Nhưng một lỗi có thể gây ra lỗi sai trong mã chính xác theo nó, do đó, tại một số điểm nó dừng lại là hợp lý.

Tham khảo trường hợp của riêng bạn: 400+ chuyển đến 120 sau một vài bản sửa lỗi.