А
Приведенный пример с массивом плохой кейс для использования try catch
Ну я, разумеется, про озвученный тут кейз
Size: a a a
2021 January 02
А
Но если это пример для изучения трай кетч файналли, то сойдет
L2
Алексей
Вообще такого рода ошибки, если тебе нужно чтобы код продолжил работать, а не просто словил ошибку, то лучше их самому обрабатывать. Например, проверить индекс, не выходит ли за размеры массива если выходит, то задать новую длину массиву
Допустим, блоком catch эта ошибка обработается, но какой в этом смысл, если следующие строки в try выполняться не будут, а произойдет выход из метода?
А
LDev 21
Допустим, блоком catch эта ошибка обработается, но какой в этом смысл, если следующие строки в try выполняться не будут, а произойдет выход из метода?
Этот механизм не для исправления ошибок
L2
А для продолжение работы программы?
L2
Но для чего тогда ошибка обрабатывается. Чтобы не было последствий в дальнейшем ходе работы программы?
GV
LDev 21
Но для чего тогда ошибка обрабатывается. Чтобы не было последствий в дальнейшем ходе работы программы?
Чтобы у тебя программа не упала в рантайме, и продолжала работу
А
LDev 21
А для продолжение работы программы?
Если его не будет, то произойдет выход из программы
L2
Я понимаю, что блок catch для этого, но этот же блок тогда просто можно оставить пустым? Но знаю, что не рекомендуется
А
На таких примерах это не очевидно, а если взять веб сервер, например, то без кетчей сервер будет стопится
А
LDev 21
Я понимаю, что блок catch для этого, но этот же блок тогда просто можно оставить пустым? Но знаю, что не рекомендуется
Можно
А
Но как ты собираешься узнавать что и где у тебя не так?
L2
Алексей
Но как ты собираешься узнавать что и где у тебя не так?
Т.е в кетче я фактически не исправляю ошибку, а фиксирую её, и в зависимости от её наличия определяю дальнейшее поведение программы
GV
LDev 21
Я понимаю, что блок catch для этого, но этот же блок тогда просто можно оставить пустым? Но знаю, что не рекомендуется
Это абсолютно нелогично. Исключения в джава делятся на проверяемые и непроверяемые. Проверяемые нужно перехватывать в принудительном порядке, так как зачастую они возникают при доступе к внешним ресурсам, которые зачастую могут быть недоступны. В таком случае нужно понять, что не так и сказать об этом клиенту.
Непроверяемые исключения это зачастую результат ошибок самого программиста. И их необходимо перехватывать в исключительных случаях и записать в логи, чтобы разработчик мог исправить проблему
Непроверяемые исключения это зачастую результат ошибок самого программиста. И их необходимо перехватывать в исключительных случаях и записать в логи, чтобы разработчик мог исправить проблему
GV
Ты не должен исправлять ошибки исключения, так как зачастую не владеешь всей необходимой информацией для ее корректного исправления. Поэтому зачастую необходимо залогировать и либо корректно завершить программу, либо вернуть клиенту управление откатив состояние
L2
Понял, спасибо. Казалось бы, очевидные вещи и интуитивно к ним можно самим придти. Но после армии логика накрылась, приходится восстанавливать глупыми вопросами)
LK
подскажите пожалуйста, как можно создать миллион задач и передать их executor
Lr
Leonid Kharin
подскажите пожалуйста, как можно создать миллион задач и передать их executor
В цикле, но от миллиона вообще смвсьа никакого
LK
В цикле, но от миллиона вообще смвсьа никакого
они же будут создаваться последовательно, а executor уже сам их будет по потокам распределять я правильно же понимаю
Э
Leonid Kharin
подскажите пожалуйста, как можно создать миллион задач и передать их executor
так и сделать) в чём проблема?