задний план
У нас есть функция в приложении, которая должна получить текущее местоположение пользователя, а затем, когда пользователь выключит GPS, местоположение пользователя не будет получено, и будет вызвана ошибка.Содержимое всплывающего окна выглядит как следует.
анализ проблемы
Прямая причина этой проблемы заключается в том, что значение мобильного терминала не может быть получено, в результате чего переменной не присваивается значение, а в серверную часть передается «неопределенное». сообщает об ошибке.
Основная причина в том, что есть проблема с механизмом обработки исключений, поэтому бэкенд и фронтенд начинают рваться.
Фронтальная точка зрения: Внутренний код слишком ненадежен, даже если внешний интерфейс неправильный, он должен быть отказоустойчивым; кроме того, у приложения есть версия, даже если это исправление, пользователь может не обязательно обновляться, у пользователя предыдущей версии все еще будут проблемы, поэтому попробуйте решить проблему такого рода.
внутренний вид: Во внешнем интерфейсе нет механизма покрытия исключений, и пользователь не должен видеть никаких подобных программных исключений. Для исключений с пользовательскими требованиями сообщайте о конкретных исключениях, и не должны отображаться общие исключения, такие как всплывающее окно «Служба недоступна». Кроме того, такого рода ограничение относится к уровню http-запроса, и если интерфейс не следует этому ограничению, это моя вина. Я перехватил его для вас на уровне back-end фреймворка, не доходя до бизнес-кода.
Обе стороны правы, и ни одна не может убедить другую. Но все согласны с целью: мы не должны позволять пользователям видеть всплывающие исключения такого типа.
Поскольку вы не можете убедить другую сторону, вы можете только более глубоко проанализировать проблему, чтобы найти более разумное решение.
Общая обработка исключений
http обычно ошибка с
- Начиная с 4: есть проблема с параметрами клиента, и серверу необходимо предоставить отладочную информацию. По идее должно появиться только при совместной отладке, но на практике не обязательно (не пощечина ли это)
- Начиная с 5: Ошибка на стороне сервера, а на стороне клиента унифицированная обработка исключений.
- Начиная с 2: бизнес ненормальный.Если есть требование к пользовательскому интерфейсу, серверная часть вернет код, а внешний интерфейс отобразит пользовательский интерфейс в соответствии с кодом. Если нет требований к пользовательскому интерфейсу, внешний интерфейс напрямую отображает сообщение об ошибке, возвращаемое серверной частью.
Чтобы унифицировать обработку исключений, общая практика компаний заключается в том, что API единообразно возвращает набор форматов данных.
{
"error_code": "xx", // code码,1代表正常,其他表示异常。
"error_msg": "xx" // msg,错误提示消息
"data": "xx" // 正常数据
}
Мы тоже, и мы единообразно обрабатываем все данные, начинающиеся с 4, в этот унифицированный формат данных.
Затем логика обработки исключений во внешнем интерфейсе
Проблема на этот раз - перейти на 2-ю ветку.
Передняя и задняя части не ошибаются.Проблема в том, что у задней части есть проблема с абстракцией модели исключений.客户端参数有问题,需要后端提供debug信息
, а не сообщение об ошибке, отображаемое пользователю.
На самом деле на стороне сервера существует три типа исключений.
- Исключение с проблемными параметрами клиента (интерфейсу требуется отладочная информация и информация об ошибке)
- Бизнес-исключение, которое должно быть известно пользователю, интерфейс должен отображаться в соответствии с кодом (интерфейсу нужен код кода)
- Общие исключения на стороне сервера, упакованные в виде сообщений для внешнего интерфейса. (Внешнему интерфейсу требуется информация об ошибке)
решение
После четкого анализа проблемы существует метод понимания.
Решение 1. Разделите сообщения об ошибках и отладочные сообщения и добавьте поле в возвращаемый единый формат API.debug_msg
для развития,error_msg
еще для пользователей
Решение 2. Определите несколько кодов перечисления. как соглашение о развитии
code | error_msg | Значение ошибки параметра |
---|---|---|
010000 | Системная ошибка [010000] | Метод запроса не поддерживается |
010001 | Системная ошибка [010001] | отсутствует параметр пути |
010002 | Системная ошибка [010002] | Отсутствует обязательный параметр запроса |
010003 | Системная ошибка [010003] | Несоответствие типов |
010004 | Системная ошибка [010004] | Исключение тела запроса |
010005 | Системная ошибка [010005] | // Исключение проверки параметра (тело или параметр) |
010006 | Системная ошибка [010006] | Исключение привязки параметра (форма) |
Определение решения 1 относительно ясное, но для этого крайнего случая добавляются накладные расходы на поле, а стоимость передачи по сети высока. Кроме того, необходимо модифицировать переднюю часть, а стоимость модификации относительно велика.
Решение 2 совместимо с текущей реализацией, и внешний интерфейс менять не нужно, но для客户端参数有问题
Этот тип напоминания об ошибке не очень удобен, и определенные ошибки параметров не могут отображаться в интерфейсе. Только лог.
Обсудите с фронтендом и определите решение 2.
Суммировать
Итак, эта проблема, окончательное решение
- Когда передняя часть не может получить позиционирование, она будет
undefined
назначение этой переменной - Серверная часть изменила механизм обработки исключений для мобильного сервиса.
@RestControllerAdvice
public class ApiStandardException {
private static final String ERROR_MSG = "系统错误";
@ExceptionHandler(value = Exception.class)
public ResponseEntity<Result> handle(final Exception ex, final WebRequest request)
throws Exception {
try {
if (ex instanceof HttpRequestMethodNotSupportedException) {
// 请求方法不支持
LOG.warn("Request method is not supported");
throw new BusinessException(WebRequestErrorEnum.METHOD_ERR.getCode(), ERROR_MSG);
} else if (ex instanceof MissingPathVariableException) {
LOG.warn("MISSING_PATHVAR" + ex.getMessage());
// 缺少路径参数
throw new BusinessException(WebRequestErrorEnum.MISSING_PARAM.getCode(), ERROR_MSG);
} else if (ex instanceof MissingServletRequestParameterException) {
// 缺少必须的请求参数
}
// 省略其他异常处理
Обратите внимание на [Храм аббата], как можно скорее получите обновление статьи и начните путь технической практики вместе с аббатом.