Анализатор обнаружил, что переопределенный метод 'toString' или 'clone' может вернуть значение 'null' или выбросить исключение.
Использование методов 'toString' / 'clone' на объекте должно всегда возвращать строку / объект соответственно. Возврат же недействительного значения противоречит неявному контракту метода.
Давайте поясним сказанное на примерах некорректного переопределения метода 'toString':
@Override
public String toString()
{
return null;
}
Есть вероятность, что в дальнейшем при работе программы или ее отладке будет вызван данный метод для получения текстового представления объекта. Т.к. разработчик скорее всего не станет проверять результат работы этой функции на null, дальнейшее его использование может повлечь за собой исключение 'NullPointerException'. Если необходимо вернуть пустое или неизвестное значение текстового представление объекта, рекомендуется использовать для этого пустую строку:
@Override
public String toString()
{
return "";
}
Другой пример плохой практики при реализации метода 'toString' – выбрасывание исключения. Рассмотрим следующий синтетический пример:
@Override
public String toString()
{
if(hasError)
{
throw new IllegalStateException("toString() method error encountered");
}
....
}
Высока вероятность, что данный метод будет вызван пользователем класса в месте, не подразумевающем возможности возникновения и обработки исключений.
Если необходимо выдать сообщение об ошибке при генерации текстового представления объекта, лучше будет вернуть его текст в виде строки, либо каким-то образом залогировать эту ошибку:
....
@Override
public String toString()
{
if(hasError)
{
logger.warn("toString() method error encountered");
return "Error encountered";
}
....
}
С методом 'clone' аналогичная ситуация. Работая с этим методом, разработчик в голове может держать только 2 возможных исхода:
Но он явно не ожидает того, что при работе с методом может произойти подобное:
Данная диагностика классифицируется как:
|
Взгляните на примеры ошибок, обнаруженных с помощью диагностики V6073. |