Разные методы для разных типов

2 блока try на преобразование типов. и все дела но мне не понравилось такое решение. пытался пользоваться тем, что изучили в течении прошлых лекций.

(i>0 && i< 128) short

а 0 - ноль это Integer правильное решение более отпимально.

Сбило с толку краткое описание к задание "Вы еще не забыли про полиморфизм?" Раз задача на полиморфизм, я 4 часа честно пытался решить с помощью объектов, instatnceof, расширения и сужения типов. Ничего не вышло, огорчился, написал не особо красивый код, чтобы хоть как-то решить задачу, и валидатор принял решение с 1-го раза. Каково же было удивление, когда правильный вариант оказался таким же, как и мой... Только там один try - catch, а у меня два (один для "точки", второй без нее). Я так и остался в недоумении, где же здесь полиморфизм.

Эх, ну, хоть бы намекнули на трай-кэтч... Столько попыток, а валидатор без этого не пропускал, поехали: 1. Создаю буферизированный ридер и запускаю вечный цикл пока (истина). 2. Внутри цикла создаю строку значение и инициализирую её вводом с клавиатуры. 3. Если (значение.соответствует("выходу")), то ломаем цикл с помощь break; 4. Иначе пошла жара пробуем распарсить из строки число и вызвать соответствующий метод { ... 5. Если (значение.содержит("точку")), то { вызываем метод и передаём ему строку, спарсенную в дробное число } 6. Иначе, если (Парсим.вЦелоеЧисло(значение) больше нуля И меньше 128), то { вызываем метод c аргументом типа Short } 7. Иначе, ели (Парсим.вЦелоеЧисло(значение) меньше либо равно нулю ИЛИ больше либо равно 128), то { метод с пропарсенным целым числом } 8. Ловим (ИсключениеЧисловогоФормата) { значит попалась строка и мы её здесь обрабатываем — вызываем метод и передаём ему строку аргументом } 9. Всё получится! -- tlgrm: @LetsCodeIt | @SefoNotasi

Валидатор заставляет плодить try..catch, хотя можно было обойтись одним. Пробовать сразу парсить в double. Если спарсилось, то уже сужать до int и short. иначе выводить строку в catch. Каждый try это увеличение время работы программы P.S. да да да, можно было решить через регулярки😀

Получилось не так красиво, как в правильном решении, зато сам, с 1-ой попытки и лучше чем 60% учеников (себя не похвалишь, никто не похвалит😁). Когда кто-то пишет - о, это некрасивый код, так нельзя писать, всё переделай... блин, ну это тоже самое как говорить человеку, который учится параллельной парковке на площадке - а чо так медленно и некрасиво паркуешься, давай в дрифте, как в Форсаже! Народ, вы только учитесь, нельзя объять необъятное! Всё придёт со временем и опытом. Смотреть на правильное и элегантное исполнение кода конечно нужно, но ни в коем случае не нужно расстраиваться, если сейчас так не получается. Всё придёт со временем😊

Вопрос знатокам. Почему Integer.parseInt и Integer.valueOf упорно не хотят отрабатывать 6 знаков (хотя это еще Integer)? Например 22222 принимает, а 222222 улетает в стринг.

else if (Integer.valueOf(line) <= 0 || Integer.valueOf(line) >= 128)   print(Integer.valueOf(line));

Google ответа не дал.

Хорошая идея для решения, которую уже ниже указывали - делать через try-catch на предмет возникновения NumberFormatException. То есть по схеме:

try{
   print(Short.parseShort(string));
} catch (NumberFormatException e){
   try{
      print (Integer.parseInt(string));
   } catch (NumberFormatException e){
   ...
...
}

При этом последовательность такого парсинга short - int - double. Только поскольку по условию задачи short не совсем совпадает с диапазоном от -32768 до +32768 (собственно, short), то в блоке парсинга short нужно будет искусственно выбросить исключение, если число не попадет в диапазон (0,128).

при проверке на short парсил в short, работало, но валидатор не съел - только в integer(

Бага на джавараше быть не может?