С учетом этого случая
String myString;
try {
myString= foo(x);
} catch (Exception e) {
myString= bar(x);
}
Что произойдет, если foo(x)
сгенерирует исключение, поскольку он не может обрабатывать строки с символами UTF-16, тогда вместо этого мы будем использовать bar(x)
.
В вашем случае с троичным оператором String myString = foo(x) ? foo(x) : bar(x)
, если вы сначала проверите foo(x)
, и он выдаст ошибку, то вся ваша программа выдаст ошибку, что приведет нас обратно к установке оператора try вокруг вашего троичного оператора.
Без оригинального кода трудно сказать, почему разработчики сделали это таким образом, но выше приведен пример того, почему они выбрали эту практику проектирования.Также хорошо отметить, что в данном случае не весь устаревший код плох;Устаревший код работает, удобен в обслуживании и легко читается для новых разработчиков.Поэтому, как говорится в комментарии, лучше оставить все так.
Редактировать
Вы сказали, что хотели какой-то 1 вкладыш, который уменьшает котельную плиту.Вы можете сделать что-то вроде этого
void hee(String mystring) {
try {
myString= foo(x);
} catch (Exception e) {
myString= bar(x);
}
}
Поместить эту функцию в служебный класс с последующим изменением myString = foo(x)
на hee(x)
будет достаточно, поскольку ваш исходный объект X не является примитивным типом Java.Это решение обратно совместимо (так как это устаревший код, я не уверен, какой jdk вы используете) и требует минимального объяснения.