Изучаю 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 ("Опция для английского языка");
}
}
}
FlamieCyrex
2 уровень
Помощь по изучению передачи аргументов
Комментарии (13)
- популярные
- новые
- старые
Для того, чтобы оставить комментарий Вы должны авторизоваться
Павел
24 августа 2022, 06:33
Напиши следующий код и запусти
Получишь такую же ошибку java.lang.ArrayIndexOutOfBoundsException
Наверное ты уже можешь понять что пошло не так. Мы создали пустой массив, а потом вынимаем первый его элемент что бы сравнить со строкой "en". Но дело в том что массив пустой и первого элемента там нет.
Это все равно что подойти к холодильнику с целью достать яблоко, а его там нет, ни кто его не положил. Сбой программы)
Что же делать? Надо что то положить. Перепиши код вот так
Теперь все отрабатывает как надо, мы подошли к холодильнику за яблоком, открыли, яблоко там есть, взяли.
Теперь посмотри на String[] args и на String[] holodos - и тот и тот это массивы. Тоесть в твоем случае программа упала по тому что в массиве String[] args не было первого элемента.
Название массива args - это имеется ввиду аргументы, аргументы программы.
Как передать в массив аргументов какое то значение, ребята написали ниже, даже в картинках)🖖
+2
wan-derer.ru
24 августа 2022, 05:15
При сравнении переменной со стрингом лучше писать так:
так как .equals() это метод класса String, соответственно если вызвать myVar.equals() то это сработает только если myVar инициализирована как String. Если же она null, то будет исключение т.к. у null нет никаких методов и значит, вызвать их нельзя.
Но это так, к слову. Для твоего случая напиши:
и проанализируй полученный результат :) 0
Justinian Judge в Mega City One Master
24 августа 2022, 18:55
не лучше.
Йода стайл (шиворот-навыворот) в джаве моветон в большинстве кейсов, так как в джаве другой подход (в отличие от процедурщины, откуда пришел упоминаемый тобой прием) и валидация и так будет на налл, по бизнес-требованиям или по техническим и когда дойдет до сравнения, то там уже будет все safety, а если не будет, значит где-то фундаментальные про;% проблемы.
+ не стоит забывать, что эксепшены это боль, можно завернуть весь код в try catch и наллов не будет вообще ) Только что это будет? )))
Если писать шиворот-навыворот не там где нужно..можно такие трудноуловимые баги схлопотать, мало не покажется, там где бы система вальнулась на этапе тестирования или в проде и быстро пофиксилось и там, где начали приходить наллы неожиданно, а оно бы "съедалось" системой и она бы это игнорировала.
Чем раньше выявится баг - тем дешевле он обходится
Очень часто эксепшен даже ожидается и принесет гораздо меньше проблем, чем если его не будет. Но опять же, это вопрос контекста.
В программировании все крутится вокруг контекста, сами правила по себе это просто набор рекомендаций, в одних случаях я напишу как ты предлагаешь, йода стайл, в других я напишу как в джаве принято. Но второй вариант используется чаще в энтерпрайз разработке, поскольку наллы это вообще отдельная боль джавы и ее архитектуры, много холиваров на эту тему, мнений, но у джавы есть и свои подходы, как с ними работать.
Йода стайл неспецифический инструмент для этого, это своего образа костыль, который ухудшает один момент, но может принести больше пользы в другом и из-за этого имеет право на существование.
Ты это все и так понимаешь, я писал в основном чтобы кто-то не взял это как best practive, поскольку йода стайл таковым не является, как для джавы, так и десятка других языков, это инструмент последнего выбора, когда все альтернативы еще хуже.
+5
Денис Java Developer
25 августа 2022, 11:08
и валидация и так будет на налл,
Ну вот тут я бы поспорил. Предположим ты процессишь опциональное поле из клиентского пейлоада. Оно вполне может быть Null - допустимый сценарий. Зачем вешать дополнительную валидацию на null если можно просто "перевернуть"?
Нет, конечно можно заюзать какой ни будь
Но рекомендовать это как best practice правда не стоит. Эт хороший подход но для ряда случаев. +3
DEF
25 августа 2022, 20:24
Много где даже специально расставляют всякие лишние ассерты, проверки, и генераторы исключений, как раз чтобы побольше ошибок сыпалось по возможности. Любое исключение - это не просто ошибка, а еще и стектрейс, дающий представление о ситуации.
Хороший подход, потому что альтернатива ему - непрерывные подробные логи, а это огромный объем данных даже на простых задачах.
+3
Justinian Judge в Mega City One Master
26 августа 2022, 22:35
затем что ты решаешь одну проблему, а добавляешь три.
Почитай про йода стайл, аргументацию за и против, использовать можно что угодно, в джаве он и finalize используется, причем пишут его те, кто нам рассказывает, что это моветон.
Главное чтобы ты понимал аргументацию за и против, тогда твои решения будут осознанными, это лишь инструменты, они не хорошие и не плохие, просто что-то либо сделает программу лучше, либо хуже.
0
Денис Java Developer
26 августа 2022, 22:48
Да я в общем то и говорил об инструментах :) Если ты работаешь с nullable полем - тебе нужен код который сумеет это сделать и не упасть :) почему оно nullable вопрос десятый, всякое случается, от бизнес требований до "папередников". Вот такой вот разворот сравнения один из вариантов решения :) Да ты и сам в курсе.
О нем так или иначе стоит говорить, но не подавать как лучший из подходов, лучших просто не существует :) каждый подход хорош для какой-то задачи.
0
Денис Java Developer
26 августа 2022, 22:49
DEF:
Хороший подход, потому что альтернатива ему - непрерывные подробные логи, а это огромный объем данных даже на простых задачах.
Лежащий сервис конечно же удобнее нормально настроенного логирования, да :)
А если эти стектрейсы просто выводятся куда-то, чем это отличается от нормального логгирования кроме нечитаемости?
+1
DEF
24 сентября 2022, 21:41
Мотивацией это отличается. От разовых ошибок защищают оркестраторы - они перезапустят сервис, но если ошибка стабильная это не поможет и сервис будет надежно лежать, тебя ночью из постели достанут и как следуют промотивируют.
С логами такое не прокатывает: ошибку ты если и видишь, у тебя всегда есть другие задачи, а начальству на подобные рапорты обычно плевать, пока не пойдет обратка от пользователей. В общем замечают такое не скоро, и исправить получается редко, хотя разработке ошибка видна еще на ранних этапах. Бюрократия. Почему скрытые проблемы это плохо - на то они и скрытые.
С логами даже разработке легко упустить проблему - в логи редко смотрят, логи не дают мотивации что-то там править лишнее, сверх своего объема работы, и т.к. приложение не падает, есть возможность логи просто игнорировать.
Если проблема не критичная, конечно ничего падать не должно, но только на проде - не критичную проблему можно обойти и продолжить работу. А на деве падать должно даже не критичное, т.к. если падать не будет, проблему могут не заметить и пропустить.
Если проблема критичная - дальнейшая работа невозможна или опасна. Тут уже защитные ловушки отрабатывают, и просто добивают приложение. Автотесты конечно тоже хорошо, но в рантайме они ничего не гарантируют, поэтому на проде обычно работает слой дополнительных ловушек, контролирующих нормальный ход работы сервиса.
Насмотрелся на подход "не падать никогда" - он обычно выливается в игнорирование всех ошибок. Потом такие ошибки вскрывать очень больно, авторы их тщательно закапывают, иногда даже в логи ничего не пишут, просто пустой try catch.
А если и пишут, то обычно в кастомном формате, без стектрейсов. Вся важная инфа при этом упущена, попробуй повтори. Так что стектрейсы в логах нужны.
Важные места, обложенные диагностическими логами, при одной отработке генерят несколько сотен мб логов - надежно, гарантированно можно найти проблему, но это слишком дорогая альтернатива стектрейсам.
0
Денис Java Developer
24 сентября 2022, 22:10
С логами такое не прокатывает И конечно же человечество еще не придумало систем мониторинга типа Графаны и/ли Кибаны, которые эти логи слушают и выводят красивые агрегированные данные по каждому сервису. Конечно же человечесто не умеет в экстренные системы оповещения начиная от имейла и заканчивая уютным телеграмчиком :) Естественно тебя должны поднимать в три часа ночи и ты с выпученными глазами бежишь дебажить приложение, это конечно же удобнее нормально настроенного логгирования и мониторинга.
Вспоминается старый анекдот знаете ли: "Вы не любите людей? Вы просто не умеете их готовить".
Ну и да... злые языки говорят, что в некоторых компаниях есть выделенные команды следящие за стабильностью сервиса. Хотя я и не исключаю что где-то до сих пор работает подход "тыжпрограммист" и рандомный Вася педалит и фичи и саппорт и фронт и бек и девопс и принтеры секретаршам налаживает периодически.
, авторы их тщательно закапывают, Авторы, я полагаю, никогда не слышали про код ревью, аудит и судебные разбирательства.
А если и пишут, то обычно в кастомном формате, без стектрейсов Не сомневаюсь что в ОАО "Рога и копыта" именно так и происходит... но я бы не стал здесь употреблять слово "Обычно".
Но в целом я вашу мысль понял, просто имейте в виду, что в мире есть другие IT компании, в которых все может несколько отличаться от вашей.
P.S. хотел бы я посмотреть на стомегабайтный лог в случае выброса исключения... :) Имхо одна эта цифра должна заставить задуматься о том, что здесь что-то не так. Или это вы Heap Dump логом зовете?)
0
DEF
25 сентября 2022, 10:02
Конечно в идеальном мире жить хорошо, но мы живем в реальном мире, со всеми его недостатками.
Уровень важности сервиса никак не коррелирует с компетентностью руководства.
Все и везде должно быть настроено правильно, в соответствии с лучшими практиками, но такого нет.
А проблемы есть. Разработка их обычно решает своими силами, т.к. через бюрократию пробить нормальные решения получается редко, после нескольких попыток люди даже пытаться перестают.
Код ревью и аудит - звучит хорошо, но часто это только на словах, а по факту либо вообще отсутствует, либо чистая формальность и никто на это реально времени тратить не хочет.
Нормальные команды, где все работает как нужно и процессы отлажены - их еще поискать нужно.
Даже автотесты не везде используются, хотя инструмент вполне простой и доступный.
Так что на земле ситуация немножко хуже, чем в радужных мечтах.
По факту часто у разработки на руках только невнятное описание проблемы и логи.
И если автор кода закопал проблему и наплевал на логи, вскрыть проблему очень трудно.
А авторы так делают - не все поголовно профи, много вот таких. Тут даже опыт ничего не гарантирует - кто-то развивается, а кто-то нет, хотя стаж одинаковый.
Как можно пустые try catch оставлять не понимаю, но видел неоднократно - тут все от человека зависит. Тщательного отбора нет.
Диагностические логи - это логирование всех промежуточных состояний и данных, чтобы потом можно было это поднять и проанализировать, повторить ход работы приложения.
Это самый тупой способ логирования, который видел, т.к. приходится хранить невероятное количество данных, из которых для расследования инцедентов потребуется всего лишь песчинка, а остальные по факту просто бесполезно занимают место. Тем не менее такое применяется - мир не идеален.
Много где исключительно разработка от проблем: пока проблема не сильно мешает, ее игнорируют, до последнего. Отсюда вот этот весь треш.
0
Денис Java Developer
25 сентября 2022, 10:12
Конечно в идеальном мире жить хорошо, но мы живем в реальном мире
У каждого своя реальность. Мне пока что попадались компании в которых процессы настроены нормально :) Возможно я очень везуч, возможно это потому, что я знаю английский и работаю не на отечественном рынке :)
Но в фирме которую описываете вы... я бы не задержался определенно :)
И не надо оправдывать хреново построенные процессы тем, что "у всех так". Не у всех. Не мало зависит еще и от самих людей, хотят они строить нормальный сервис или делать на от*ись. Мне удалось изрядно разворошить одну голландскую фирмочку и построить таки нормальные процессы саппорта, внедрить нормальные инструменты, часть написать пришлось самому конечно же. А мог просто сидеть на зарплате и пинать балду. Что делать и что правильно - личный выбор каждого.
0
Anonymous #2583212 Backend Developer в Open Code
24 августа 2022, 03:57
Нажимаешь сюда
Потом сюда
И в этом окошке тебе нужно как раз передать тот самый аргумент
+5