JavaScript의 오류 격리

인터페이스 요청 실패, 인터페이스 데이터 일부 누락, 운영 데이터가 기대에 미치지 못함... 애플리케이션이 출시되고 온라인에 도달하면 이러한 위험에 직면하기 시작합니다.

이러한 문제로 인해 JavaScript 오류(예: 널 포인터 예외)가 발생하고 효과적으로 격리되지 않으면 흰색 화면, 페이지 상호 작용 불가 등의 온라인 문제가 발생할 수 있습니다.

Double 11 준비 과정에서 지난 1년 동안 프런트엔드 관련 온라인 이슈를 수집한 21건 중 절반이 '데이터 이상으로 인해 페이지 표시 예외 발생'과 관련된 문제였습니다. 다소 관련이 있습니다.

특정 범위 내에서 오류의 영향을 격리하는 방법이 특히 중요합니다.

이 기사에서는 우리가 시도한 몇 가지 해결 방법과 직면한 문제에 대해 설명합니다.

Null 포인터 예외로 시작

데이터로 인해 발생하는 가장 일반적인 문제는 Null 포인터 예외입니다.

　var result = a.b.c.d;

이러한 코드는 지뢰와 같습니다. a가 동적 데이터이면 문제가 발생하기 직전입니다.

값을 가져오는 get 메소드를 캡슐화합니다. 데이터가 존재하지 않는 경우 정의되지 않은 값이 반환되므로 이러한 문제를 빠르게 피할 수 있습니다.

　var result = get(a, 'b.c.d'); 
　但如同我们期望大家在取值前，都先做判断一样，并不能保证所有人都这么用了，用不用全靠自觉。
if (a && a.b && a.b.c) {
        var result = a.b.c.d;
}

따라서 다음과 같은 솔루션이 있습니다.

비동기 데이터 검증

비동기 데이터 검증에 대한 생각 예, 획득 후 데이터를 사용하기 전에 스키마 검증을 수행하여 중요한 데이터 누락 및 비정상 유형을 감지합니다.

이 솔루션에 대응하여 fetch를 기반으로 fetch-checker Note 1 구성 요소를 캡슐화했습니다.

　fetch-checker는 사용자가 데이터를 요청할 때 데이터에 해당하는 스키마를 제공하도록 강제합니다.

let schema = {
    "rule": {
      "type": "string",
    },
    "banner": {
      "type": "object",
      "required": true,
      "default": {
        "url": "https://item.taobao.com/item.htm?id=527331762117"
      }
    }
};

이 스키마를 설명해야 합니다.

각 필드의 종류

필수 필드인지

필수 필드가 누락된 경우 데이터 추출이 필요한지

fetch-checker가 데이터를 수신한 후 먼저 확인 단계가 수행됩니다. 필요한 경우 누락된 데이터를 채워서 호출자에게 반환합니다. 이런 방식으로 사용자가 얻은 데이터는 기대와 일치해야 합니다.

　 그러나 이 솔루션이 직면한 과제는 다음과 같습니다.

　 호출자가 완전한 스키마 설명을 제공하는지 확인하는 방법입니다. 스키마 작성을 원하지 않는 경우 대략적인 스키마 설명을 제공하여 확인을 통과할 수 있습니다.

스키마를 간소화하는 방법. 즉, 번들 크기에 큰 영향을 미치지 않으며 검증 기능도 충족할 수 있습니다.

코드 컴파일

바벨에서 영감을 받은 이 솔루션은 컴파일 단계에서 NPE 위험이 있는 코드를 동등한 안전한 코드로 변환하는 것입니다. 아래와 같이:

var a = {};
// input
var result = a.b.c;
// output
var result = (_object2 = (_object3 = a) == null ? null : _object3.b) == null ? null : _object2.c;

a가 빈 객체인 경우 컴파일된 코드를 실행하면 null이 반환되므로 코드에서 오류가 발생하고 후속 프로세스가 차단되는 것을 방지할 수 있습니다.

Babel 플러그인 babel-plugin-safe-member-expression Note 2에서는 위와 같은 시도를 했습니다. 현재 케이크 프로젝트에서는 이 기능을 활성화SafeMemberExpression 구성을 통해 선택적으로 활성화할 수 있습니다.

이 솔루션은 이에 비해 액세스 비용이 저렴합니다. 개발자는 기존 코드를 조정할 필요가 없지만 여전히 과제가 있습니다.

개발 단계의 문제는 쉽게 노출되지 않으며 피드백 없이 오류가 보고되어야 합니다. 이상적인 상태는 개발 및 디버깅 단계에서 최대한 많은 문제를 노출하고 온라인에서 오류를 최대한 줄이는 것입니다.

숨겨진 코드를 정의하는 방법. 현재 모든 a.b 호출 메소드는 위의 구성표에 따라 컴파일됩니다. 테스트 과정에서 아무런 문제도 발견되지 않았지만 숨겨진 위험이 있는 코드만 처리하는 것이 더 안전합니다.

정적 검증

　　以 flow 为代表的静态校验工具，可以在一定程度上检测出 NPE 隐患。
type res = {
        data ?: Object
}
let name = res.data.name;
// property `name`. Propery cannot be accessed on possibly undefined value

위 코드에서 설명했듯이 사용자는 먼저 데이터가 null이 허용되는지 여부를 명확히 해야 합니다. null이 허용되도록 플로우 감지를 통해 이렇게 data.name을 호출하면 오류가 감지됩니다.

그러나 모든 기업이 정적 검증에 접근할 수 있도록 홍보하는 방법과 접근 후 개발자가 모든 유형을 설명하도록 보장하는 방법도 어렵습니다.

위 내용은 JavaScript의 오류 분리 내용입니다. 더 많은 관련 내용은 PHP 중국어 홈페이지(www.php.cn)를 참고해주세요!