Tại sao Java có lỗi trình biên dịch "câu lệnh không thể truy cập"?

Tôi thường thấy khi gỡ lỗi một chương trình, việc chèn một câu lệnh trả về bên trong một khối mã sẽ rất tiện lợi (mặc dù được cho là một phương pháp không tốt). Tôi có thể thử một cái gì đó như thế này trong Java ....

class Test {
        public static void main(String args[]) {
                System.out.println("hello world");
                return;
                System.out.println("i think this line might cause a problem");
        }
}

tất nhiên, điều này sẽ dẫn đến lỗi trình biên dịch.

Test.java:7: câu lệnh không thể truy cập

Tôi có thể hiểu tại sao cảnh báo có thể được biện minh là có mã không được sử dụng là hành vi xấu. Nhưng tôi không hiểu tại sao điều này cần phải tạo ra một lỗi.

Đây chỉ là Java đang cố gắng trở thành một Nanny, hay có lý do chính đáng để khiến đây là lỗi trình biên dịch?

Bởi vì mã không thể truy cập được là vô nghĩa đối với trình biên dịch. Trong khi việc làm cho mã có ý nghĩa đối với mọi người là điều tối quan trọng và khó hơn là làm cho nó có ý nghĩa đối với một trình biên dịch, trình biên dịch là người tiêu dùng thiết yếu của mã. Các nhà thiết kế của Java có quan điểm rằng mã không có ý nghĩa đối với trình biên dịch là một lỗi. Lập trường của họ là nếu bạn có một số mã không thể truy cập được, bạn đã mắc một lỗi cần được sửa.

Có một câu hỏi tương tự ở đây: Mã không thể truy cập: lỗi hay cảnh báo? , trong đó tác giả nói "Cá nhân tôi thực sự cảm thấy nó phải là một lỗi: nếu lập trình viên viết một đoạn mã, nó phải luôn với ý định thực sự chạy nó trong một số tình huống." Rõ ràng là các nhà thiết kế ngôn ngữ của Java đồng ý.

Liệu mã không thể truy cập có ngăn cản quá trình biên dịch hay không là một câu hỏi mà sẽ không bao giờ có sự đồng thuận. Nhưng đây là lý do tại sao các nhà thiết kế Java đã làm điều đó.

Một số người trong các bình luận chỉ ra rằng có nhiều lớp mã không thể truy cập được Java không ngăn cản việc biên dịch. Nếu tôi hiểu đúng hậu quả của Gödel, không trình biên dịch nào có thể bắt được tất cả các lớp mã không thể truy cập được.

Bài kiểm tra đơn vị không thể bắt mọi lỗi đơn lẻ. Chúng tôi không sử dụng điều này như một lý lẽ chống lại giá trị của chúng. Tương tự như vậy, một trình biên dịch không thể bắt tất cả các mã có vấn đề, nhưng nó vẫn có giá trị để ngăn việc biên dịch mã xấu khi có thể.

Các nhà thiết kế ngôn ngữ Java coi mã không thể truy cập được là một lỗi. Vì vậy, ngăn chặn nó biên dịch khi có thể là hợp lý.

(Trước khi bạn phản đối: câu hỏi không phải là liệu Java có nên gặp lỗi trình biên dịch câu lệnh không thể truy cập hay không. Câu hỏi đặt ra là tại sao Java có lỗi trình biên dịch câu lệnh không thể truy cập. Đừng phản đối tôi chỉ vì bạn nghĩ rằng Java đã đưa ra quyết định thiết kế sai).

Không có lý do chính xác tại sao không cho phép các câu lệnh không thể truy cập được; các ngôn ngữ khác cho phép chúng mà không gặp vấn đề gì. Đối với nhu cầu cụ thể của bạn, đây là mẹo thông thường:

if (true) return;

Nó trông có vẻ vô lý, bất cứ ai đọc mã sẽ đoán rằng nó phải được thực hiện một cách có chủ ý, không phải là một sai lầm bất cẩn khi để các câu lệnh còn lại không thể truy cập được.

Java có một chút hỗ trợ cho "biên dịch có điều kiện"

http://java.sun.com/docs/books/jls/third_edition/html/statements.html#14.21

if (false) { x=3; }

không dẫn đến lỗi thời gian biên dịch. Một trình biên dịch tối ưu hóa có thể nhận ra rằng câu lệnh x = 3; sẽ không bao giờ được thực thi và có thể chọn bỏ mã cho câu lệnh đó khỏi tệp lớp đã tạo, nhưng câu lệnh x = 3; không được coi là "không thể truy cập" theo nghĩa kỹ thuật được quy định ở đây.

Cơ sở lý luận cho cách xử lý khác biệt này là cho phép các lập trình viên xác định "các biến cờ" như:

static final boolean DEBUG = false;

và sau đó viết mã như:

if (DEBUG) { x=3; }

Ý tưởng là có thể thay đổi giá trị của DEBUG từ false thành true hoặc từ true thành false và sau đó biên dịch mã một cách chính xác mà không có thay đổi nào khác đối với văn bản chương trình.

Đó là Vú em. Tôi cảm thấy .Net đã làm đúng điều này - nó đưa ra cảnh báo cho mã không thể truy cập, nhưng không phải là lỗi. Thật tốt khi được cảnh báo về điều đó, nhưng tôi không thấy có lý do gì để ngăn chặn quá trình biên dịch (đặc biệt là trong các phiên gỡ lỗi, nơi thật tuyệt khi ném trả về để bỏ qua một số mã).

Tôi chỉ nhận thấy câu hỏi này và muốn thêm 0,02 đô la của mình vào câu hỏi này.

Trong trường hợp của Java, đây thực sự không phải là một tùy chọn. Lỗi "mã không thể truy cập" không xuất phát từ việc các nhà phát triển JVM nghĩ rằng sẽ bảo vệ các nhà phát triển khỏi bất cứ điều gì hoặc cần hết sức cảnh giác, mà là do các yêu cầu của đặc tả JVM.

Cả trình biên dịch Java và JVM, đều sử dụng cái được gọi là "bản đồ ngăn xếp" - một thông tin xác định về tất cả các mục trên ngăn xếp, như được cấp phát cho phương thức hiện tại. Loại của mỗi và mọi vị trí của ngăn xếp phải được biết, để một lệnh JVM không xử lý nhầm mục của một loại cho một loại khác. Điều này chủ yếu quan trọng để ngăn chặn việc có một giá trị số được sử dụng làm con trỏ. Có thể sử dụng Java assembly để cố gắng đẩy / lưu trữ một số, nhưng sau đó bật / tải một tham chiếu đối tượng. Tuy nhiên, JVM sẽ từ chối mã này trong quá trình xác thực lớp, - đó là khi các bản đồ ngăn xếp đang được tạo và kiểm tra tính nhất quán.

Để xác minh các bản đồ ngăn xếp, máy ảo phải đi qua tất cả các đường dẫn mã tồn tại trong một phương thức và đảm bảo rằng bất kể đường dẫn mã nào sẽ được thực thi, dữ liệu ngăn xếp cho mọi lệnh đồng ý với những gì mà bất kỳ mã nào trước đó đã đẩy / được lưu trữ trong ngăn xếp. Vì vậy, trong trường hợp đơn giản của:

Object a;
if (something) { a = new Object(); } else { a = new String(); }
System.out.println(a);

tại dòng 3, JVM sẽ kiểm tra xem cả hai nhánh của 'if' chỉ được lưu trữ vào một (chỉ là var # 0 cục bộ) thứ gì đó tương thích với Object (vì đó là cách mã từ dòng 3 trở đi sẽ xử lý var # 0 cục bộ ).

Khi trình biên dịch nhận được một mã không thể truy cập, nó không hoàn toàn biết trạng thái của ngăn xếp có thể ở thời điểm đó, vì vậy nó không thể xác minh trạng thái của nó. Nó không thể biên dịch mã nữa vào thời điểm đó, vì nó cũng không thể theo dõi các biến cục bộ, vì vậy thay vì để lại sự mơ hồ này trong tệp lớp, nó sẽ tạo ra một lỗi nghiêm trọng.

Tất nhiên một điều kiện đơn giản như if (1<2)sẽ đánh lừa nó, nhưng nó không thực sự đánh lừa - nó cung cấp cho nó một nhánh tiềm năng có thể dẫn đến mã và ít nhất cả trình biên dịch và máy ảo đều có thể xác định, cách các mục ngăn xếp có thể được sử dụng từ đó trên.

PS Tôi không biết .NET làm gì trong trường hợp này, nhưng tôi tin rằng nó cũng sẽ không biên dịch được. Điều này thường sẽ không phải là vấn đề đối với bất kỳ trình biên dịch mã máy nào (C, C ++, Obj-C, v.v.)

Một trong những mục tiêu của trình biên dịch là loại trừ các lớp lỗi. Một số mã không thể truy cập được một cách tình cờ, thật tuyệt khi javac loại bỏ lớp lỗi đó tại thời điểm biên dịch.

Đối với mỗi quy tắc bắt gặp mã sai, ai đó sẽ muốn trình biên dịch chấp nhận nó vì họ biết họ đang làm gì. Đó là hình phạt của việc kiểm tra trình biên dịch, và cân bằng chính xác là một trong những điểm khó của thiết kế ngôn ngữ. Ngay cả khi kiểm tra nghiêm ngặt nhất vẫn có vô số chương trình có thể được viết, vì vậy mọi thứ không thể tệ như vậy.

Mặc dù tôi nghĩ rằng lỗi trình biên dịch này là một điều tốt, nhưng có một cách bạn có thể khắc phục nó. Sử dụng một điều kiện bạn biết sẽ đúng:

public void myMethod(){

    someCodeHere();

    if(1 < 2) return; // compiler isn't smart enough to complain about this

    moreCodeHere();

}

Trình biên dịch không đủ thông minh để phàn nàn về điều đó.

Chắc chắn là một điều tốt khi phàn nàn rằng trình biên dịch càng nghiêm ngặt càng tốt, chừng nào nó cho phép bạn làm những gì bạn cần. Thông thường, cái giá nhỏ phải trả là nhận xét mã ra, lợi ích là khi bạn biên dịch mã của bạn hoạt động. Một ví dụ chung là Haskell về việc mọi người hét lên cho đến khi họ nhận ra rằng thử nghiệm / gỡ lỗi của họ chỉ là thử nghiệm chính và là thử nghiệm ngắn. Cá nhân tôi trong Java hầu như không gỡ lỗi trong khi (thực tế là có chủ đích) không chú ý.

Nếu lý do cho phép if (aBooleanVariable) return; someMoreCode;là cho phép cờ, thì thực tế là if (true) return; someMoreCode;không tạo ra lỗi thời gian biên dịch có vẻ như không nhất quán trong chính sách tạo ngoại lệ CodeNotReachable, vì trình biên dịch 'biết' đó truekhông phải là cờ (không phải biến).

Hai cách khác có thể thú vị, nhưng không áp dụng cho việc tắt một phần mã của phương thức cũng như if (true) return:

Bây giờ, thay vì nói, if (true) return;bạn có thể muốn nói assert falsevà thêm -ea OR -ea package OR -ea classNamevào các đối số jvm. Điểm tốt là điều này cho phép một số chi tiết và yêu cầu thêm một tham số bổ sung vào lệnh gọi jvm, do đó không cần đặt cờ GỬI trong mã, nhưng bằng cách thêm đối số trong thời gian chạy, điều này hữu ích khi mục tiêu không phải là máy của nhà phát triển và việc biên dịch lại và chuyển bytecode mất nhiều thời gian.

Cũng có System.exit(0)cách, nhưng điều này có thể là quá mức cần thiết, nếu bạn đặt nó trong Java trong JSP thì nó sẽ kết thúc máy chủ.

Ngoài việc Java được thiết kế bằng ngôn ngữ 'bảo mẫu', tôi muốn sử dụng một thứ gì đó bản địa như C / C ++ để kiểm soát nhiều hơn.