背景
バグの引き金となるでしょう、私たちは、あなたがユーザの現在位置を取得する必要があり、APPの機能であり、ユーザーがGPSを閉じたときに、ユーザーが場所に取得していない、ポップは、以下の通りです。
分析
この問題の直接の原因は、それがバックエンド、定義された値が整数型変換のバックエンドが失敗し、エラーに渡された「未定義」になりますがない変数への代入で、その結果、携帯端末の値未満を取ることです。
例外処理メカニズムの問題が原因とされる基礎となる、その後、フロントエンドとバックエンドには力を引き裂くために始めました
正面図：;加えて、APPのバージョンがあり、でも修正プログラム場合、ユーザーは必ずしも、アップグレードしない以前のバージョンのユーザーはまだ問題を抱えているので、このバックエンドのコードであっても、フロントエンドのパスが間違っている場合、それはまた、フォールトトレラントである必要があり、強すぎます修正する種類のバックエンド問題になろう。
バックエンドビュー：フロントは例外フォールバックメカニズムはありませんが、ユーザーはどのようなプログラムの例外が表示されないはずです。異常のカスタマイズのニーズ、特定の例外レポートでは、そのようなポップなど、一般的な異常を示さないはず「利用できないサービスを提供しています。」また、このHTTPリクエストレベルの制約に属する、フロントエンドは、制約に準拠していませんが、また私を非難します。私はあなたではなく、ビジネスコードに傍受バックエンドフレームワークのレベルを提供します。
双方は、納得できるすべての良い感覚を、言います。ユーザーがポップ例外のこのタイプを見ることができていないと判断：しかし、私たちは目標に合意します。
それは他の側を説得することはできませんので、それは問題のより詳細な分析からだけでは、より合理的な解決策を見てみましょう
ユニバーサル珍しいアプローチ
HTTPエラーは、通常は持っています
- 4で始まる：問題を抱えているクライアントのパラメータは、バックエンドのデバッグ情報を提供する必要があります。理論的には、FBIが、実際には必ずしもないときにのみ起こるべきである（それはまだ顔にヒットしません）
- 5最初：サーバー側のエラー、クライアントは、統一例外処理を提供してきました
- 2開始：異常なトラフィックを、UIフロントエンド、UI表示装置によれば、後端リターンコードコードコードコードを必要とする場合。何のUIの要件が存在しない場合は、直接フロントエンドの表示エラーメッセージは、バックエンドで返されます。
例外処理を統一するためには、一般的な企業の練習統一されているAPIは、データ形式のセットを返し、
{
"error_code": "xx", // code码，1代表正常，其他表示异常。
"error_msg": "xx" // msg，错误提示消息
"data": "xx" // 正常数据
}
我々はまた、最初と4で統一されたデータフォーマットの統一されたセットに加工されています。
その後、フロントエンド処理ロジック異常
問題は、枝の2が行ったことです。
前后端都没做错，问题是后端对于异常模型的抽象有问题，客户端参数有问题，需要后端提供debug信息，而不是给用户展示的错误信息。
其实服务端对于异常就分三种
- 客户端参数有问题的异常（前端需要debug信息和错误msg信息）
- 需要用户知道的业务异常，前端需要根据code展示的（前端需要code码）
- 通用的服务端异常，包装成消息给前端。（前端需要错误msg信息）
解法
分析清楚了问题后，就有了解法。
解法1：错误消息和debug消息分离，返回的API统一格式中增加一种字段。debug_msg 给开发看的,error_msg 还是给用户看的
解法2：定义几个枚举code。作为开发的约定
| code | error_msg | 参数错误含义 |
|---|---|---|
| 010000 | 系统错误[010000] | 请求方法不支持 |
| 010001 | 系统错误[010001] | 缺少路径参数 |
| 010002 | 系统错误[010002] | 缺少必须的请求参数 |
| 010003 | 系统错误[010003] | 类型不匹配 |
| 010004 | 系统错误[010004] | 请求体异常 |
| 010005 | 系统错误[010005] | // 参数校验异常(body 或 param) |
| 010006 | 系统错误[010006] | 参数绑定异常(表单) |
解法1定义比较清晰，但是为了这种corner case增加了一个字段的开销，网络传输代价高了。另外还需要前端配合更改，改动成本比较大。
解法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) {
// 缺少必须的请求参数
}
// 省略其他异常处理关注【方丈的寺院】，第一时间收到文章的更新，与方丈一起开始技术修行之路