Чому Java має помилку компілятора "недосяжний вираз"?

Я часто виявляю, що під час налагодження програми зручно (хоча, можливо, погана практика) вставляти оператор return у блок коду. Я можу спробувати щось подібне на 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");
        }
}

звичайно, це призведе до помилки компілятора.

Test.java:7: недосяжне твердження

Я міг зрозуміти, чому попередження може бути виправданим, оскільки невикористаний код - це погана практика. Але я не розумію, чому це має спричинити помилку.

Це просто Java, яка намагається бути Нянею, чи є вагома причина зробити помилку компілятора?

Оскільки недосяжний код для компілятора безглуздий. Незважаючи на те, що надання значущого коду для людей є першорядним і складнішим, ніж його значення для компілятора, компілятор є основним споживачем коду. Дизайнери Java вважають, що код, який не має значення для компілятора, є помилкою. Їх позиція полягає в тому, що якщо у вас є якийсь недосяжний код, ви допустили помилку, яку потрібно виправити.

Тут є подібне запитання: Недоступний код: помилка чи попередження? , в якому автор каже: "Особисто я впевнений, що це повинна бути помилка: якщо програміст пише фрагмент коду, він завжди повинен мати намір насправді запустити його за певним сценарієм". Очевидно, що мовні дизайнери Java погоджуються.

Чи повинен недоступний код перешкоджати компіляції - це питання, щодо якого ніколи не буде консенсусу. Але саме тому це зробили дизайнери Java.

Ряд людей у ​​коментарях зазначають, що існує безліч класів недосяжного коду, який Java не заважає компілювати. Якщо я правильно розумію наслідки Gödel, жоден компілятор не може схопити всі класи недосяжного коду.

Блокові тести не можуть виявити кожну помилку. Ми не використовуємо це як аргумент проти їх значення. Так само компілятор не може вловити весь проблемний код, але для нього все ще важливо запобігти компіляції поганого коду, коли він може.

Дизайнери мови Java вважають недосяжний код помилкою. Тому запобігання його компіляції, коли це можливо, є розумним.

(Перш ніж ви проголосуєте проти: питання полягає не в тому, чи повинна Java мати помилку недосяжного компілятора виразів . Питання полягає в тому, чому в Java є недосяжна помилка компілятора виразів. Не голосуйте проти мене лише тому, що ви вважаєте, що Java прийняла неправильне дизайнерське рішення.)

Немає остаточної причини, через яку недопустимі недоступні твердження; інші мови дозволяють їх без проблем. Для ваших конкретних потреб це звичайний фокус:

if (true) return;

Це виглядає безглуздо, кожен, хто читає код, здогадається, що це, мабуть, було зроблено свідомо, а не необережною помилкою, залишивши решту тверджень недосяжними.

Java має невелику підтримку "умовної компіляції"

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

if (false) { x=3; }

не призводить до помилки під час компіляції. Компілятор, що оптимізує, може усвідомити, що твердження x = 3; ніколи не буде виконано, і він може пропустити код для цього виразу із сформованого файлу класу, але вираз x = 3; не розглядається як "недосяжний" у зазначеному тут технічному розумінні.

Обґрунтування цього різного поводження полягає у наданні можливість програмістам визначати "позначення змінних", таких як:

static final boolean DEBUG = false;

а потім напишіть код, такий як:

if (DEBUG) { x=3; }

Ідея полягає в тому, що має бути можливість змінити значення DEBUG з false на true або з true на false, а потім правильно скомпілювати код без будь-яких інших змін у тексті програми.

Це Няня. Я відчуваю,. Net зрозумів це правильно - воно видає попередження про недосяжний код, але не помилку. Добре бути попередженим про це, але я не бачу підстав для запобігання компіляції (особливо під час налагоджувальних сеансів, де приємно кинути повернення, щоб обійти якийсь код).

Я тільки що помітив це запитання і хотів додати до цього свої $ .02.

У випадку з Java це насправді не є варіантом. Помилка "недосяжний код" походить не від того, що розробники JVM думали захищати розробників від чого завгодно або бути надмірно пильними, а від вимог специфікації JVM.

І Java-компілятор, і JVM використовують те, що називається "картами стеків" - певну інформацію про всі елементи в стеку, як це виділено для поточного методу. Тип кожного слота стека повинен бути відомим, щоб інструкція JVM не поводилася з елементами одного типу для іншого типу. Це в основному важливо для запобігання тому, щоб числове значення ніколи не використовувалось як вказівник. За допомогою збірки Java можна спробувати натиснути / зберегти номер, але потім висунути / завантажити посилання на об’єкт. Однак JVM відхилить цей код під час перевірки класу, тобто коли карти стеків створюються та перевіряються на узгодженість.

Щоб перевірити карти стеків, віртуальна машина повинна пройти всі шляхи коду, які існують у методі, і переконатися, що незалежно від того, який шлях коду коли-небудь буде виконаний, дані стеку для кожної інструкції узгоджуються з тим, що натискав будь-який попередній код / зберігається в стосі. Отже, у простому випадку:

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

у рядку 3 JVM перевірить, що обидві гілки 'if' зберігали лише в (що є лише локальним змінним # 0) щось, що сумісне з Object (оскільки саме так код з рядка 3 і далі буде обробляти локальний var # 0 ).

Коли компілятор потрапляє до недосяжного коду, він не зовсім знає, в якому стані може бути стек на той момент, тому він не може перевірити його стан. На той момент він вже не може повністю скомпілювати код, оскільки він також не може відстежувати локальні змінні, тому замість того, щоб залишити цю неоднозначність у файлі класу, він видає фатальну помилку.

Звичайно, така проста умова if (1<2)обдурить, але це насправді не обдурює - вона дає їй потенційну гілку, яка може призвести до коду, і принаймні як компілятор, так і віртуальна машина можуть визначити, як звідти можна використовувати елементи стека на.

PS Я не знаю, що робить .NET у цьому випадку, але я вважаю, що компіляція також не вдасться. Зазвичай це не буде проблемою для будь-яких компіляторів машинного коду (C, C ++, Obj-C тощо)

Однією з цілей компіляторів є виключення класів помилок. Якийсь недосяжний код є випадково, приємно, що javac виключає цей клас помилок під час компіляції.

Для кожного правила, яке ловить помилковий код, хтось захоче, щоб компілятор прийняв його, оскільки він знає, що робить. Це покарання перевірки компілятора, і правильний баланс є одним із хитрих моментів мовного дизайну. Навіть при найсуворішій перевірці все ще існує нескінченна кількість програм, які можна писати, тому все не може бути настільки поганим.

Хоча я вважаю, що ця помилка компілятора - хороша річ, є спосіб, як її обійти. Використовуйте умову, яка, на вашу думку, буде істинною:

public void myMethod(){

    someCodeHere();

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

    moreCodeHere();

}

Компілятор недостатньо розумний, щоб скаржитися на це.

Це, звичайно, добре скаржитися, чим жорсткіший компілятор, тим краще, наскільки це дозволяє вам робити те, що вам потрібно. Зазвичай невелика ціна - це коментування коду, виграш полягає в тому, що при компіляції ваш код працює. Загальним прикладом є Haskell, про який люди кричать, поки не усвідомлюють, що їх тест / налагодження - це лише основний і короткий тест. Я особисто на Java майже не виконую налагодження, будучи (насправді навмисно) не уважним.

Якщо причина дозволу if (aBooleanVariable) return; someMoreCode;- дозволити прапори, то той факт, що if (true) return; someMoreCode;не генерує помилку часу компіляції, здається невідповідністю політиці генерації винятку CodeNotReachable, оскільки компілятор "знає"true це не прапор (не змінна).

Ще два способи, які можуть бути цікавими, але не стосуються вимкнення частини коду методу, а також if (true) return:

Тепер, замість того, щоб говорити, if (true) return;ви можете сказати assert falseі додати -ea OR -ea package OR -ea classNameдо аргументів jvm. Хороший момент полягає в тому, що це забезпечує певну деталізацію і вимагає додавання додаткового параметра до виклику jvm, тому немає потреби встановлювати прапор DEBUG у коді, а додавати аргумент під час виконання, що корисно, коли ціль не є машина розробника та перекомпіляція та передача байт-коду вимагають часу.

Існує також System.exit(0)спосіб, але це може бути надмірним, якщо ви помістите його на Java у JSP, тоді сервер буде завершено.

Окрім того, що Java є побічною конструкцією мови "няні", я б скоріше використовував щось рідне, як C / C ++ для більшого контролю.