Java Interview Tasks
前往频道在 Telegram
Реальные вопросы и задачи с собеседований. Оригинальный авторский контент. Актуальный материал. Уровень вопросов от junior до supersenior. Автор канала - @alexzelentsov По рекламе: @alexzelentsov
显示更多4 893
订阅者
无数据24 小时
+47 天
+16730 天
帖子存档
4 890
Обещал привести пример метода parseCatch для продакшена
Реализация зависит от конкретной логики приложения, которое использует этот метод
Общие вещи:
private Integer parseCatchProd(String s) {
try {
return Integer.parseInt(s);
} catch (NumberFormatException e) {
return null;
}
}
такой вариант не подойдет, потому что мы будем терять exceptions, которые тут будут потеряны
Поэтому можно сделать, например, так:
private Integer parseCatchProd(String s) {
try {
return Integer.parseInt(s);
} catch (NumberFormatException e) {
log.error(e.getMessage(), e);
return null;
}
}
Далее: null возвращать обычно не самая хорошая идея, можно вернуть Optional
или какое-нибудь дефолтное значение, например, -1
Кроме того, возможно вообще не нужно делать catch внутри этого метода, если, например, у вас где-то уровнем выше обрабатываются уже такие ошибки
Как вариант, можно сделать так (если вам не очень критична производительность):
private Optional parseCatchProd(String s) {
try {
return Optional.of(Integer.parseInt(s));
} catch (NumberFormatException e) {
log.error(e.getMessage(), e);
return Optional.empty();
}
}
Если это не так придется, как всегда, пожертовать чем-то, например, best practice:)
4 890
Свежая конфа по джаве:
Java, Cloud, Data, AI, Robotics, Programming Languages, Security, Architecture, Developer Practices and Culture
https://youtube.com/playlist?list=PLKuh52zVrL6n_LKPLZN_n2tdYjACndZmB
4 890
Всем привет.
Экспресс ответ к последнему вопросу про catch/if.
Для негативного варианта (когда приходит невалидная строка) все просто - каждый раз создаётся exception, а это дорогая операция, так как надо создать объект со стек трейсом. Результаты говорят сами за себя.
Результаты позитивного сценария говорят о том, что if хоть и срабатывает каждый раз, но большого оверхеда не вносит.
Выводы: почти всегда лучше вариант с if, кроме случая, когда у вас очень мало запросов с валидными строками (например, меньше 5%)
Код, который использовался в вопросе не стоит рассматривать как идеальный-супер-продакшен код, он сделан таким, что бы убрать ненужные для измерений действия, которые могут вносить оверхед в результаты.
Так же хочу сказать, что мне написало много людей с вопросами, когда будут новые посты, поэтому решил продолжить выкладывать новые вопросы и другой релевантный контент тут, не смотря на большую нехватку времени. Всем спасибо кто дочитал.
4 890
Тинькофф приглашает на One Day Offer
Ищем Java- и Kotlin-разработчиков с опытом от трех лет, чтобы сделать им оффер за день. В течение дня вы общаетесь с командой, а после получаете оффер, если вам понравится команда, работа подойдет по условиям, а задачи — по скиллам.
Встречаемся 28 мая онлайн. Успейте подать заявку до 26 мая. В течение трех дней вернемся с обратной связью: https://l.tinkoff.ru/one_day_offer_java_
4 890
Как вы считаете, на сколько медленнее parseIf, чем parseCatch в случае валидной строки (например "1232133141")?
4 890
Как вы считаете, на сколько быстрее parseIf, чем parseCatch в случае невалидной строки (например "1232133141w")?
4 890
Давайте посмотрим два возможных варианта кода, для обработки невалидных строк из предыдущего поста. Как вы считаете, какой вариант будет быстрее и на сколько для позитивного сценария и для негативного? (Далее будет два опроса)
4 890
Проблемы , которые могут быть в коде из прошлого поста:
1) код не компилируется: возвращаемый тип должен быть не void, а Integer
2) параметр s может быть null, можно добавить проверку
3) строка s может быть не приводима к int, например, “12we” или ”11111111111111111111111”, в обоих случаях метод выбросит эксепшен, и тут надо выбрать вариант, как обработать такие ситуации:
[0] ничего не делать, возможно, это приемлемое поведение для вашего случая (например: у вас обработка исключений уже продумана в коде, который вызывает данный метод)
[1] проверять входной параметр s в начале метода, перед вызовом parseInt
[2] обернуть вызов parseInt в try-catch
Вариант [1] лучше тем, что в процессе работы не создаётся эксепшен, так как создание эксепшена-тяжелая операция
Вариант [2] может быть лучше, если параметр s почти всегда валидное для int значение, тогда мы экономим на проверке из варианта 1
То есть надо отталкиваться от того, насколько вам важен перформанс в конкретном случае и какие данные приходят на вход в метод.
В следующих постах посмотрим насколько тяжелая операция “throw exception” с точки зрения перформанса и приведу конкретные измерения для разных вариантов
4 890
Объяснение к вопросу про ExecutorService:
ExecutorService проглатывает исключения в случае выполнения Runnable, поэтому если вы отправили на выполнение Runnable, вы обязаны поместить все тело метода внутрь try-catch. Если вы помещаете в ExecutorService Callable, удостоверьтесь, что вы всегда достаете его результат с помощью блокирующего get(), чтобы увидеть исключение если оно будет.
Старая статья про ExecutorService: https://habr.com/ru/post/260953/
4 890
Проблемы в коде:
1) notify нельзя переопределять, потому что он final
2) Если вызывать notify, то нужно это делать внутри synchronized блока
3) lock не инициализируется и будет npe
4 890
Все о Java в одном месте!
DMdev - это настоящая дорожная карта джависта на YouTube.
Новичок, junior, middle, senior - каждый найдёт информацию для себя.
Попав в комьюнити DMdev, многие жалеют лишь об одном - что не попали сюда раньше.
Не повторяй ошибок других - переходи на канал и становись лучшим в Java программировании🙌🏻
