Проблема заключается в том, как обрабатывать неожиданный ответ JSON от сервера сообщение об ошибке, это должно сделать вопрос яснее:Android аннотаций отдых обработки
интерфейс ApiService:
@Rest(
converters = MappingJackson2HttpMessageConverter.class,
interceptors = AuthInterceptor.class,
responseErrorHandler = MyErrorHandler.class)
public interface ApiService {
@Get("http://192.168.1.5:3000" + "/balance")
Balance getBalance();
...
}
MyErrorHandler класса соответствующие части
@Override
public boolean hasError(ClientHttpResponse response) throws IOException {
switch (response.getStatusCode()) {
case OK:
case CREATED:
return false;
default:
return true;
}
}
@Override
public void handleError(ClientHttpResponse response) throws IOException {
switch (response.getStatusCode()) {
case BAD_REQUEST:
Log.d(TAG, "handleError: bad request");
break;
default:
Log.d(TAG, "handleError: Default");
break;
}
}
Соответствующая часть MainActivity (где используется)
@Override
public void onResume() {
super.onResume();
getBalance();
}
@Background
void getBalance() {
showBalance(apiService.getBalance());
}
// show balance is accessing Balance fields and showing it on screen
Это работает хорошо, когда сервер возвращает то, что он должен возвращать, но когда он не делает (например, он возвращает код ошибки 400 и json с ключами, которые не входят в класс баланса), приложение вылетает из-за того, что парсер Json не может проанализировать ответ.
Я мог бы обернуть showBalance() в try catch, но если в другом месте больше использования getBalance() в ApiService, я должен был бы сделать это для всех из них. Есть ли способ разорвать поток приложения из MyErrorHandler, когда он обнаруживает код ошибки сервера
does 'error handling' ring any bell? –
Что я могу сделать в handleError(), чтобы приложение не пыталось преобразовать ответ в объект «Баланс», в настоящее время, как это происходит, он обнаружит, что произошла ошибка, и он все равно попытается преобразовать json в Balance – dzingiskan
Нет, я имею в виду, что вы должен написать свой код с допущением, что все может пойти не так, т. е. запрос SQL не удался (по какой-либо причине), HTTP-запрос завершился неудачно (по какой-либо причине). Как только вы это узнаете, вы не будете терпеть крах из-за провала промежуточных шагов, потому что вы будете готовы к этому делу. Это то, чего сейчас не хватает вашему подходу –