체인:거부 중 예외 봉인

묘사

#chain는 제공된 함수f로 인한 이상을 삭제하고 있습니다.나는 테스트 용례를 추가하고 행동을 변경해서 되돌아오겠다는 약속을 거절했다.
나는 이 문제의 영향을 받지 않기 때문에 (반드시) 바꾸지 않았다. #chainError.그러나 그것은 관련 요소의 영향을 받았다.함수f가 던져지면 첫 번째 함수#mapError는 오류 약속을 되돌려주지 않고 오류 약속을 되돌려줍니다.이 유형의 오류도 자동으로 삭제됩니다.만약 네가 원한다면, 나는 이 문제를 해결하기 위해 단독 당김 요청을 만들 수 있다.

토론 #1

좋은 소식:감사합니다.상응하는 chainError 버그에 대해 실패한 테스트 용례가 있습니까?이 요청에 단독 제출로 추가하는 것이 더 쉬울 수 있습니다.

토론 #2

완성, 지금 댓글은 지금 벌어지고 있는 일과 무관한 것 같지만.나는 그 줄을 지우고 싶지 않다.너무 촉박해 보여요.이렇게 하면 너에게 적합합니까?
트라비스의 구축은 인종 문제로 실패한 것 같다.브라우저에서 #onRejected can 체인 오류를 안정적으로 재현할 수 있습니다.이 테스트는 beforeEach 블록과 같은 변수를 사용합니다.따라서 resolve 블록의 비동기식reject과 beforeEach은 테스트 기간에 삽입하고 테스트 전에 약속을 해결하거나 거부할 수 있다.만약 결과가 예상과 일치하지 않는다면, 단언은 실패하거나 테스트가 시간을 초과할 것이다.

토론 #셋

오류에 대한 실패한 테스트를 제출할 수 있습니다.그러나 또 다른 유사한 문제가 있다.한 값의 유형을 가정하는 몇 가지 방법은 모두 영향을 받을 수 있다. 특히 #chainError, #chainError 및 #concat*.이것이 바로 내가 그것을 단독 관계에 두고 싶은 이유이다. (그러나 나는 내가 미리 이렇게 말할 수 있다고 생각한다.)
*) 고장이 났을 가능성이 있습니까?보류 중인 Promy에는 적용되지 않습니다.만약 이것이 의도적인 것이라면, 그것은 영향을 받지 않을 것이다.#empty 나는 지금 #empty 블록을 별로 좋아하지 않는다. 왜냐하면 하나의 테스트 용례를 더욱 읽기 어렵게 하기 때문이다. 이런 상황에서 이상한 경기 조건을 초래할 수 있기 때문이다.단독 테스트를 더욱 명확하게 하고 이상한 오류를 피하기 위해 이것들을 삭제하는 것을 보니 매우 기쁘다.
유형 오류의 경우 이러한 오류를 모두 캡처하는 것이 좋으므로 개별 PR이 더 좋을 수 있습니다.

토론 #4

네, 오늘 자세히 봤는데 beforeEach 영향을 받지 않았어요.나는

토론 #5

만 호출되면 concat승낙이 없으면 돌아오는 승낙이 계속 끊길 줄 알았다.그러나 chain(other)other는 우선 약속을 돌려주지 않기 때문이다.
그래서 그것은other.onRejected(...),chain과chain이다.나는 여전히 chainError 무엇을 해야 할지 확실하지 않기 때문에, 나는 단지 이 PR에 테스트 용례와 변경을 추가했을 뿐이다.
그 밖에 e368eef2976f07b564fd4afcab838ffe24f26ca0은 테스트에서 불확실성을 없애겠다고 약속합니다.만약 네가 원한다면, 나는 그것을 이 공관에 합병하거나 단독으로 한 부 발표할 수 있다.empty https://github.com/mudge/pacta/commit/e368eef2976f07b564fd4afcab838ffe24f26ca0아주 좋아요. empty 에 대한 소개는 모든 약속 유형에 대해 테스트 데이터 생성기 (예:

토론 #6

, rejected() 를 사용하여 테스트의 정확한 구조 함수 파라미터를 분리해야 한다고 생각합니다.나는 지금 이렇게 하고 있다. 목표는 그 전에 그것을 합병하는 것이다.emptyPromise() 지금 제가 살펴보겠습니다. fulfilledPromise()의 오류는 뻔합니다. (생성된 값

토론 #7

에 chain 함수가 있다고 가정하면) 그런데 왜 당신이 거기에 응용한 복구 프로그램pb으로 포장을 하는지...map는 try로 일합니까?구체적으로 말하자면, 왜 아래의 테스트는 여전히 실패합니까?

var promise = new Promise();

this.mapError(f).mapError(function (pb) {
    try {
        pb.map(function (value) {
            promise.resolve(value);
        });

        pb.onRejected(function (reason) {
            promise.reject(reason);
        });
    } catch (e) {
        promise.reject(e);
    }
});

this.map(function(value) {
    promise.resolve(value);
});

return promise;

만약 catch에 이상이 발생하면 chainError 거절당한 약속을 되돌려 우리가 사용할 수 있도록 해야 하지 않습니까?f에서 실제로 돌아오겠다는 약속은 전혀 해결되지 않은 것 같지만, 한동안 이 라이브러리에서 일하지 않았기 때문에 왜 그런지 이해하기 어렵다.mapError 이것은 테스트를 통과하지 못했다. 왜냐하면 되돌아오는 약속은 거절의 근본적인 원인이 아니라 상응하는 오류가 발생하기 때문이다.chainError가 던져졌을 때, 그것은 두 번째

토론 #8

프로세서로 보내졌다.f가 실현되지 않았기 때문에e1mapErrore1를 던질 것이다.map가 결국 거절의 원인이 되었다.
나는 근본적인 원인의 수요를 없애기 위해 테스트를 변경할 수 있지만, 이것은 가치 있는 특성이라고 생각한다.TypeError 물론: 테스트의 시간 초과는 나를 곤혹스럽게 하지만 이상 유형에 대한 정확한 단언을 삭제하면 두 번째 e2가 나타나는 것을 볼 수 있다.
지점을 마스터로 다시 설정하고 e2 일치

토론 #9

로 수정했습니다. (대칭적 결핍이 의심스럽습니다.) #9에서 이 점을 보실 수 있습니다.TypeError에 관해서는 chain에 대해 당신이 옳습니다. 이것은 현재 해결된 약속에만 적용됩니다.보이다https://github.com/fantasyland/fantasy-land#empty- Fantasy Land에서 사양을 가져오는 방법.우리가 chainError의 반군 성질을 보장할 수만 있다면 우리는 마땅히 좋은 것이어야 한다.

토론 #10

나는 실현을 다음과 같이 변경할 수 있다고 생각한다. (건장해 보이는wrt.type 오류)

/* empty :: Promise e a -> Promise e a */
Promise.prototype.empty = function () {
    return this.map(function (value) {
        return value.empty ? value.empty() : value.constructor.empty();
    });
};

어쨌든, 나는 #9을 기쁘게 생각하고, 이 공관을 닫는 것을 건의합니다.