OldJohn

1. Научиться получать данные с внешнего ресурса (те самые таблицы) и выводить их в консоль как есть.
2. Разобраться что за данные ты получаешь. JSON? XML? Научиться парсить (разбирать) их на отдельные поля и сохранять в коллекцию. И выводить в консоль.
3. Подключить базу данных и сохранять уже в базу, а не в коллекцию.
4. Подключить web. У Шилдта наверно есть про сервлеты. Вот на них можно. Цель - выводить данные уже не в консоль, а в браузер - в виде JSON.
5. Оставить это как версию и сделать то же самое на Spring Boot. Работодателям нужен только Spring, но то что ты делал на "низком уровне" тоже может пригодиться, типа "Я и так тоже могу".
6. Теперь думать про фронт. В любом случае, надо знать основы HTML, CSS, вёрстки. Вариантов несколько:
- интегрировать фронт прямо в Spring-приложение, используя шаблонизаторы (их "из коробки" 3 на выбор, самый популярный thymeleaf);
- сделать фронт как отдельное приложение для браузера, которое будет ходить на бэк за данными и взаимодействовать с пользователем. Самый популярный фреймворк для фронта - React, но бэкэндерам лучше заходит Angular;
- экзотика типа Vaadin.....
7. На основе кода бэка сделать бота в Telegram и/или мобильное приложение (если интересно, конечно).
Я бы советовал по мере эволюции бэка уже искать работу/стажировку. Новичкам часто дают тестовые задания - делая их ты лучше поймёшь что нужно работодателям, ну и потренируешься.
Удачи!

"Выращивайте" проект.
Напишите, для начала, MVP - какую-то штуку, которая собирает статистику, хотя бы одного захардкоженного матча/турнира и выводит в консоль.
Потом расширяйте.

Всегда надо помнить, что Исключение - это довольно дорогая операция и без необходимости лучше её не использовать

try-catch - это эволюционно развитый if-else. Вот те кто кодили на "C" знают как тяжело работать с файловыми операциями. Любой fopen,fread e.t.c. надо проверять на код возврата и обеспечивать аварийный выход с очисткой (!) всех ресурсов. И вот отслеживание всех ресурсов и их состояний это нетривиальная задача. Для этого создали try-with-resources. И вообще возврат в это тяжелое мракобесное время проверок errorcode - никому не советую.

В случае с делением на 0 (ArithmeticException). Если вы рисуете на экране график функции - то возможна ситуация
где будет много делений на нуль. Тогда обработка исключений может стать performance issue. Это правда.

Может помочь декомпозиция формулы с делением на результат с Option[Int] (в Scala и Java это уже рабоатет) и возвращать неопределенное значение None в случае когда в знаменателе стоит ноль. Вообще в языках ФП данный подход очень рекомендуется т.к. в этих языках есть синтаксический сахар для быстрого сворачивания (flatMap) списков таких опциональных значений.

Тоесть если вы из функции хотите вернуть пустоту - то возвращаете None вместо бросания прикладных исключений.

Стоит также обратить внимание на то, что есть try with resources, что позволяет после работы автоматически закрывать соединение и т.д. Т.е. все, что имплементирует интерфейс AutoClosable. Например, подключиться к БД, что-то сделать, а затем закрыть соединение. Как мимнимум в if else этого нет.
С другой стороны try catch более тяжелый с точки зрения производительности.

Если вы можете выполнить проверку условия в блоке if else, то используйте его + оберните его в try catch, чтобы перехватить непредвиденное исключение, если оно возникнет.

Это древний холивар.

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

Имхо: Если есть возможность сделать без try catch, то лучше делать без try catch. Во всяком случае так работает с null pointer exception:

// Good
if (x != null) {
    
} else {

}

// Bad
try {
     // action with x
} catch(NullPointerEcxeption e) {

}

Вот тут можешь попрактиковаться sql-ex.ru

1. Срочно научиться пользоваться поиском.
https://qna.habr.com/search?q=Как+учить+Java%3F
2. Все.