Избавиться от response.getStatusCode() / 100 == 2
. Вместо этого напишите response.getStatusCode() == 200
или response.getStatusCode() == HttpStatus.SC_OK
.
Удалите ветвь else
и throw
после оператора if
.
Переименуйте метод в getExceptionByStatusCode
или generateExceptionForStatusCode
. Вы не handleException
, вы решаете, какой из них бросить.
Выберите правильный тип возврата. Не используйте RuntimeException
. Это может быть ResponseStatusException
или любой другой тип, соответствующий HTTP / абстракции вашего домена.
Для каждого случая решите, какой тип вы хотите вернуть. Опять же, не RuntimeException
.
Немного улучшенная версия будет
private String handleResponse(HttpResponse response) {
final int statusCode = response.getStatusCode();
if (statusCode == HttpStatus.SC_OK) {
return response.getEntity().toString();
}
throw getExceptionByStatusCode(statusCode);
}
private MyDomainHTTPException getExceptionByStatusCode(int statusCode) {
switch (statusCode) {
case HttpStatus.SC_NOT_FOUND:
return new MyDomainHTTPException("...");
case HttpStatus.SC_UNAUTHORIZED:
return new MyDomainHTTPException("...");
default:
return new MyDomainHTTPException("...");
}
}
Тем не менее, возвращение исключения в Java не чувствовать верно.
Работает нормально, но не совсем корректно из-за «особого» статуса исключений. Это может быть оправдано при ленивых оценках, и вы будете выдавать исключение, когда встретите определенное условие в будущем или в случаях с Optional.orElseThrow
.
Это может сбить с толку некоторых людей, которые получилииспользуется для шаблона throw new
и никогда не думал, что возвращение исключения является компилируемым параметром.
В больших средах (Spring, PrimeFaces - если моя память мне правильно служит), я видел фабрики исключений, используемые для составления исключений на основена данный контекст и правила. Они определенно используют исключения более широко, чем мы. Так что вы можете игнорировать мои чувства;)