Pegjs: 오류 보고 재설계

PEG.js의 현재 오류 보고 시스템에 세 가지 문제가 있습니다.

1. 작업은 null 를 반환하여 오류를 보고합니다.

Reporting using `null` is inflexible (it doesn't allow to carry any information about the kind of error) and makes it impossible to return `null` as a regular value from actions, which would be useful sometimes (for example [in a JSON parser](https://github.com/dmajda/pegjs/blob/791034fad92c9cd7a9d1c71187df03441bbfd521/examples/json.pegjs#L45)).

#17도 참조하십시오.

1. 완전히 맞춤화된 메시지로 오류를 생성할 방법은 없습니다.

For example, imagine a HTTP 1.1 parser that wants to report an error about missing `Host` header in a HTTP request with a message like "A HTTP 1.1 request must contain a Host header". Currently the only way to do this is to throw an exception with desired message manually. This is cumbersome and it does not interact well with the backtracking behavior (throwing an exception halts the parsing completely, even when it is possible to backtrack and try another alternatives).

1. $ SyntaxError 의 expected 속성은 기계적으로 처리하기 어렵습니다.

The `expected` property of `SyntaxError` is either an array of expectations (each describing one alternative which the parser expected at the position of error) or `null` (meaning that the end of input was expected).

각 기대값은 문자열로 표시됩니다. 이 문자열은 예상되는 리터럴(PEG.js 구문을 사용하여 표현 - 따옴표로 묶인 문자열), 문자 클래스(PEG.js 구문을 사용하여 표현 - [...] ) 또는 모든 문자(문자열 "any" 로 표현)를 의미할 수 있습니다.

이러한 문제를 해결하기 위해 오류 보고 시스템을 재설계할 계획입니다. 내가 생각하고 있는 변경 사항을 설명하기 전에 현재 시스템이 어떻게 작동하는지 약간의 설명이 필요합니다.

현재 오류 보고는 어떻게 작동합니까?

PEG.js 파서는 문자열 리터럴, 문자 클래스 또는 . 일치를 시도하고 실패하면 _match failure_를 생성합니다. _position_ 및 _expectation_(파서가 일치시키려고 시도한 내용에 대한 설명)로 구성됩니다.

일치 실패를 생성한 후 파서는 역추적하고 다른 대안을 시도할 수 있습니다. 그들 중 누구도 성공하지 못하고 더 이상 시도할 것이 없으면 파서는 SyntaxError 예외를 던집니다. 속성(예: 위치, 예상, 오류 메시지 등)을 설정할 때 파서는 가장 먼 일치 실패(가장 큰 위치를 가진 것)만 고려합니다. 그러한 실패가 더 있다면 그들의 기대가 합쳐집니다.

명명된 규칙을 사용하면 상황이 조금 더 복잡해 지지만 이것은 이 논의와 관련이 없습니다.

제안된 변경 사항

오류 보고 시스템의 다음 변경 사항에 대해 생각하고 있습니다.

1. SyntaxError.expected 의 기대치는 문자열이 아니라 객체로 표현됩니다. 개체에는 "literal" , "class" , "any" , "eof" 와 같은 값이 있는 type 속성이 있어 기대 유형을 결정합니다. 일부 기대 유형의 경우 다른 속성에 세부 정보가 포함됩니다(예: "literal" 기대의 경우 예상 문자열이 포함된 value 속성). 이것은 기대치의 기계적 처리를 단순화할 것입니다.

type 속성의 대안은 클래스를 사용하는 것입니다. 하지만 type 속성은 사용자가 다루기 더 쉬울 것이라고 생각합니다.

1. null 를 반환하는 작업이 허용됩니다. 이는 일반 값이며 오류를 나타내지 않습니다.
2. 액션은 새로운 error 함수를 사용하여 매치 실패를 유발할 수 있습니다. 매개변수로 오류 메시지를 받습니다. 이 기능에 의해 트리거된 실패(_맞춤 일치 실패_라고 함)는 _위치_ 및 _오류 메시지_로 구성됩니다. 그들은 어떤 기대도 하지 않을 것입니다.

error 함수는 작업 실행을 중단하지 않고 실패로 표시하고 오류 메시지를 저장합니다. 실제 실패는 작업 실행이 완료된 후에만 생성됩니다. error 함수가 여러 번 호출되면 마지막 호출이 우선합니다(해당 오류 메시지가 사용됨).

사용자 지정 일치 실패는 일반 일치 실패처럼 처리됩니다. 즉, 구문 분석을 완전히 중단하지 않고 파서가 역추적하여 다른 대안을 시도할 수 있습니다. 하지만 한 가지 차이점이 있습니다. 마침내 SyntaxError 예외를 throw할 때 일반 일치 실패에 적용되는 예상 조합 규칙이 사용자 지정 규칙에 적용되지 않습니다. 가장 먼 위치의 일치 실패 세트에 하나 이상의 사용자 지정 항목이 있는 경우 일반 항목을 완전히 무시합니다. 사용자 정의 실패가 더 있으면 마지막에 생성된 실패가 승리합니다.

사용자 지정 일치 실패를 기반으로 하는 SyntaxError 예외는 일반 실패를 기반으로 하는 예외와 다릅니다. message 속성은 실패 오류 메시지와 같고 expected 속성은 null 입니다.

예시

```
시작 = 기호:[+-]? 숫자:[0-9]+ {
var 결과 = parseInt((기호 || "") + 숫자.join(""), 10);

 if (result % 2 == 0) {
   error("The number must be an odd integer.");
 }

 return result;

}
```

2 입력 시 위의 문법에서 생성된 파서는 SyntaxError message 가 "The number must be an odd integer." 로 설정되고 expected 가 $로 설정된 null #$9$#$를 생성합니다.

1. 액션은 expected 함수를 사용하여 일반 일치 실패를 트리거할 수도 있습니다. 예상 값 설명을 매개변수로 사용합니다. 이 기능은 전체 오류 메시지를 생성할 필요가 없고 자동으로 "예상 _X_하지만 "2"가 발견됨" 형식을 생성할 필요가 없는 상황에 대한 편의를 위해 주로 제공됩니다. 충분합니다.

expected 함수에 의해 생성된 일치 실패를 기반으로 하는 SyntaxError 예외는 일반 실패를 기반으로 하는 예외와 유사합니다.

예시

```
시작 = 기호:[+-]? 숫자:[0-9]+ {
var 결과 = parseInt((기호 || "") + 숫자.join(""), 10);

 if (result % 2 == 0) {
   expected("odd integer");
 }

 return result;

}
```

입력 2 에서 위의 문법에서 생성된 파서는 SyntaxError 를 생성하고 $ message 는 "Expected odd integer but "2" found." 로 설정되고 expected 는 [ { type: "user", description: "odd integer" } ] 로 설정됩니다.

다음 단계

제안된 변경 사항에 대한 모든 메모를 환영합니다. 의견으로 추가하십시오. 곧 제안(또는 피드백에 따라 일부 수정된 버전) 구현을 시작할 계획입니다.