JavaRush/Java Форум/Помощь по изучению передачи аргументов

2 уровень

23.08.2022
711просмотров
13комментариев

Помощь по изучению передачи аргументов

Изучаю Java Core через учебник Майк Макграта "Java для начинающих". Встретился с такой ошибкой, на картинке прикрепленной изображен код, который требуется написать для поиска в массиве args аргумента с содержанием (-en), но в итоге при запуске выдает следующую ошибку: !Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0 at Option.main(Option.java:5) Вот код который написал с шаблона. public class Option { public static void main(String[] args) { if (args[0].equals("en")) {System.out.println ("Опция для английского языка"); } } }

Комментарии (13)

популярные
новые
старые

Для того, чтобы оставить комментарий Вы должны авторизоваться

Павел

Уровень 11

24 августа 2022, 06:33

Напиши следующий код и запусти

public static void main(String[] args) {

	String[] holodos = new String[0];//создаем пустой массив

	if (holodos[0] //берем первый элемент массива
                             .equals("en")) {
		System.out.println("Английский");
	}
}

Получишь такую же ошибку java.lang.ArrayIndexOutOfBoundsException Наверное ты уже можешь понять что пошло не так. Мы создали пустой массив, а потом вынимаем первый его элемент что бы сравнить со строкой "en". Но дело в том что массив пустой и первого элемента там нет. Это все равно что подойти к холодильнику с целью достать яблоко, а его там нет, ни кто его не положил. Сбой программы) Что же делать? Надо что то положить. Перепиши код вот так

public static void main(String[] args) {

	String[] holodos = new String[]{"en"}; //создали массив с одним элементом - строка "en"

	if (holodos[0] //достаем первый элемент
			.equals("en")) {
		System.out.println("Английский");
	}
}

Теперь все отрабатывает как надо, мы подошли к холодильнику за яблоком, открыли, яблоко там есть, взяли. Теперь посмотри на String[] args и на String[] holodos - и тот и тот это массивы. Тоесть в твоем случае программа упала по тому что в массиве String[] args не было первого элемента. Название массива args - это имеется ввиду аргументы, аргументы программы. Как передать в массив аргументов какое то значение, ребята написали ниже, даже в картинках)🖖

wan-derer.ru

Уровень 40

24 августа 2022, 05:15

При сравнении переменной со стрингом лучше писать так:

if ("ABCD".equlas(myVar)) {
    // do something
}

так как .equals() это метод класса String, соответственно если вызвать myVar.equals() то это сработает только если myVar инициализирована как String. Если же она null, то будет исключение т.к. у null нет никаких методов и значит, вызвать их нельзя. Но это так, к слову. Для твоего случая напиши:

System.out.println(args.length);

и проанализируй полученный результат :)

Justinian Judge в Mega City One

Master

24 августа 2022, 18:55

При сравнении переменной со стрингом лучше писать так:

не лучше. Йода стайл (шиворот-навыворот) в джаве моветон в большинстве кейсов, так как в джаве другой подход (в отличие от процедурщины, откуда пришел упоминаемый тобой прием) и валидация и так будет на налл, по бизнес-требованиям или по техническим и когда дойдет до сравнения, то там уже будет все safety, а если не будет, значит где-то фундаментальные про;% проблемы. + не стоит забывать, что эксепшены это боль, можно завернуть весь код в try catch и наллов не будет вообще ) Только что это будет? ))) Если писать шиворот-навыворот не там где нужно..можно такие трудноуловимые баги схлопотать, мало не покажется, там где бы система вальнулась на этапе тестирования или в проде и быстро пофиксилось и там, где начали приходить наллы неожиданно, а оно бы "съедалось" системой и она бы это игнорировала. Чем раньше выявится баг - тем дешевле он обходится Очень часто эксепшен даже ожидается и принесет гораздо меньше проблем, чем если его не будет. Но опять же, это вопрос контекста. В программировании все крутится вокруг контекста, сами правила по себе это просто набор рекомендаций, в одних случаях я напишу как ты предлагаешь, йода стайл, в других я напишу как в джаве принято. Но второй вариант используется чаще в энтерпрайз разработке, поскольку наллы это вообще отдельная боль джавы и ее архитектуры, много холиваров на эту тему, мнений, но у джавы есть и свои подходы, как с ними работать. Йода стайл неспецифический инструмент для этого, это своего образа костыль, который ухудшает один момент, но может принести больше пользы в другом и из-за этого имеет право на существование. Ты это все и так понимаешь, я писал в основном чтобы кто-то не взял это как best practive, поскольку йода стайл таковым не является, как для джавы, так и десятка других языков, это инструмент последнего выбора, когда все альтернативы еще хуже.

Денис Enterprise Java Developer

25 августа 2022, 11:08

и валидация и так будет на налл, Ну вот тут я бы поспорил. Предположим ты процессишь опциональное поле из клиентского пейлоада. Оно вполне может быть Null - допустимый сценарий. Зачем вешать дополнительную валидацию на null если можно просто "перевернуть"?

MY_CONSTANT.equals(rawData.getField());

Нет, конечно можно заюзать какой ни будь

StringUtils.equals(MY_CONSTANT, rawData.getField());

Но рекомендовать это как best practice правда не стоит. Эт хороший подход но для ряда случаев.

DEF

Уровень 1

25 августа 2022, 20:24

Много где даже специально расставляют всякие лишние ассерты, проверки, и генераторы исключений, как раз чтобы побольше ошибок сыпалось по возможности. Любое исключение - это не просто ошибка, а еще и стектрейс, дающий представление о ситуации. Хороший подход, потому что альтернатива ему - непрерывные подробные логи, а это огромный объем данных даже на простых задачах.

Justinian Judge в Mega City One

Master

26 августа 2022, 22:35

Зачем вешать дополнительную валидацию на null если можно просто "перевернуть"?

затем что ты решаешь одну проблему, а добавляешь три. Почитай про йода стайл, аргументацию за и против, использовать можно что угодно, в джаве он и finalize используется, причем пишут его те, кто нам рассказывает, что это моветон. Главное чтобы ты понимал аргументацию за и против, тогда твои решения будут осознанными, это лишь инструменты, они не хорошие и не плохие, просто что-то либо сделает программу лучше, либо хуже.

Денис Enterprise Java Developer

26 августа 2022, 22:48

Да я в общем то и говорил об инструментах :) Если ты работаешь с nullable полем - тебе нужен код который сумеет это сделать и не упасть :) почему оно nullable вопрос десятый, всякое случается, от бизнес требований до "папередников". Вот такой вот разворот сравнения один из вариантов решения :) Да ты и сам в курсе. О нем так или иначе стоит говорить, но не подавать как лучший из подходов, лучших просто не существует :) каждый подход хорош для какой-то задачи.

Денис Enterprise Java Developer

26 августа 2022, 22:49

DEF: Хороший подход, потому что альтернатива ему - непрерывные подробные логи, а это огромный объем данных даже на простых задачах. Лежащий сервис конечно же удобнее нормально настроенного логирования, да :) А если эти стектрейсы просто выводятся куда-то, чем это отличается от нормального логгирования кроме нечитаемости?

DEF

Уровень 1

24 сентября 2022, 21:41

Мотивацией это отличается. От разовых ошибок защищают оркестраторы - они перезапустят сервис, но если ошибка стабильная это не поможет и сервис будет надежно лежать, тебя ночью из постели достанут и как следуют промотивируют. С логами такое не прокатывает: ошибку ты если и видишь, у тебя всегда есть другие задачи, а начальству на подобные рапорты обычно плевать, пока не пойдет обратка от пользователей. В общем замечают такое не скоро, и исправить получается редко, хотя разработке ошибка видна еще на ранних этапах. Бюрократия. Почему скрытые проблемы это плохо - на то они и скрытые. С логами даже разработке легко упустить проблему - в логи редко смотрят, логи не дают мотивации что-то там править лишнее, сверх своего объема работы, и т.к. приложение не падает, есть возможность логи просто игнорировать. Если проблема не критичная, конечно ничего падать не должно, но только на проде - не критичную проблему можно обойти и продолжить работу. А на деве падать должно даже не критичное, т.к. если падать не будет, проблему могут не заметить и пропустить. Если проблема критичная - дальнейшая работа невозможна или опасна. Тут уже защитные ловушки отрабатывают, и просто добивают приложение. Автотесты конечно тоже хорошо, но в рантайме они ничего не гарантируют, поэтому на проде обычно работает слой дополнительных ловушек, контролирующих нормальный ход работы сервиса. Насмотрелся на подход "не падать никогда" - он обычно выливается в игнорирование всех ошибок. Потом такие ошибки вскрывать очень больно, авторы их тщательно закапывают, иногда даже в логи ничего не пишут, просто пустой try catch. А если и пишут, то обычно в кастомном формате, без стектрейсов. Вся важная инфа при этом упущена, попробуй повтори. Так что стектрейсы в логах нужны. Важные места, обложенные диагностическими логами, при одной отработке генерят несколько сотен мб логов - надежно, гарантированно можно найти проблему, но это слишком дорогая альтернатива стектрейсам.

Денис Enterprise Java Developer

24 сентября 2022, 22:10

С логами такое не прокатывает И конечно же человечество еще не придумало систем мониторинга типа Графаны и/ли Кибаны, которые эти логи слушают и выводят красивые агрегированные данные по каждому сервису. Конечно же человечесто не умеет в экстренные системы оповещения начиная от имейла и заканчивая уютным телеграмчиком :) Естественно тебя должны поднимать в три часа ночи и ты с выпученными глазами бежишь дебажить приложение, это конечно же удобнее нормально настроенного логгирования и мониторинга. Вспоминается старый анекдот знаете ли: "Вы не любите людей? Вы просто не умеете их готовить". Ну и да... злые языки говорят, что в некоторых компаниях есть выделенные команды следящие за стабильностью сервиса. Хотя я и не исключаю что где-то до сих пор работает подход "тыжпрограммист" и рандомный Вася педалит и фичи и саппорт и фронт и бек и девопс и принтеры секретаршам налаживает периодически. , авторы их тщательно закапывают, Авторы, я полагаю, никогда не слышали про код ревью, аудит и судебные разбирательства. А если и пишут, то обычно в кастомном формате, без стектрейсов Не сомневаюсь что в ОАО "Рога и копыта" именно так и происходит... но я бы не стал здесь употреблять слово "Обычно". Но в целом я вашу мысль понял, просто имейте в виду, что в мире есть другие IT компании, в которых все может несколько отличаться от вашей. P.S. хотел бы я посмотреть на стомегабайтный лог в случае выброса исключения... :) Имхо одна эта цифра должна заставить задуматься о том, что здесь что-то не так. Или это вы Heap Dump логом зовете?)

DEF

Уровень 1

25 сентября 2022, 10:02

Конечно в идеальном мире жить хорошо, но мы живем в реальном мире, со всеми его недостатками. Уровень важности сервиса никак не коррелирует с компетентностью руководства. Все и везде должно быть настроено правильно, в соответствии с лучшими практиками, но такого нет. А проблемы есть. Разработка их обычно решает своими силами, т.к. через бюрократию пробить нормальные решения получается редко, после нескольких попыток люди даже пытаться перестают. Код ревью и аудит - звучит хорошо, но часто это только на словах, а по факту либо вообще отсутствует, либо чистая формальность и никто на это реально времени тратить не хочет. Нормальные команды, где все работает как нужно и процессы отлажены - их еще поискать нужно. Даже автотесты не везде используются, хотя инструмент вполне простой и доступный. Так что на земле ситуация немножко хуже, чем в радужных мечтах. По факту часто у разработки на руках только невнятное описание проблемы и логи. И если автор кода закопал проблему и наплевал на логи, вскрыть проблему очень трудно. А авторы так делают - не все поголовно профи, много вот таких. Тут даже опыт ничего не гарантирует - кто-то развивается, а кто-то нет, хотя стаж одинаковый. Как можно пустые try catch оставлять не понимаю, но видел неоднократно - тут все от человека зависит. Тщательного отбора нет. Диагностические логи - это логирование всех промежуточных состояний и данных, чтобы потом можно было это поднять и проанализировать, повторить ход работы приложения. Это самый тупой способ логирования, который видел, т.к. приходится хранить невероятное количество данных, из которых для расследования инцедентов потребуется всего лишь песчинка, а остальные по факту просто бесполезно занимают место. Тем не менее такое применяется - мир не идеален. Много где исключительно разработка от проблем: пока проблема не сильно мешает, ее игнорируют, до последнего. Отсюда вот этот весь треш.

Денис Enterprise Java Developer

25 сентября 2022, 10:12

Конечно в идеальном мире жить хорошо, но мы живем в реальном мире У каждого своя реальность. Мне пока что попадались компании в которых процессы настроены нормально :) Возможно я очень везуч, возможно это потому, что я знаю английский и работаю не на отечественном рынке :) Но в фирме которую описываете вы... я бы не задержался определенно :) И не надо оправдывать хреново построенные процессы тем, что "у всех так". Не у всех. Не мало зависит еще и от самих людей, хотят они строить нормальный сервис или делать на от*ись. Мне удалось изрядно разворошить одну голландскую фирмочку и построить таки нормальные процессы саппорта, внедрить нормальные инструменты, часть написать пришлось самому конечно же. А мог просто сидеть на зарплате и пинать балду. Что делать и что правильно - личный выбор каждого.

Anonymous #2583212 Backend Developer в Open Code

24 августа 2022, 03:57

Нажимаешь сюда

Потом сюда

И в этом окошке тебе нужно как раз передать тот самый аргумент