코드가 작동하지만 약속 내에 try/catch 블록을 갖는 것이 가장 좋습니다.

Question

try/catch을 Promise으로 감싸는 것이 좋습니다. 아래 코드를 검토하고 있는데 Promise 안에 try/catch 블록이 있어야 할 필요성을 이해하지 못하는 것 같습니다. 또한 Promise 블록이 보이지 않는 곳에는 왜 catch 블록에서 볼 수 있듯이 Promise 해결 방법이 없습니다. 우수 사례 및 효율성 측면에서 이 Promise 안에있는 요점을이 코드의 일부분으로 이해해주십시오.

중복 된 부분을 정리하는 것과 관련된 제안 사항에 대해서도 감사드립니다. 그것은 약속 [실행 프로그램 기능] 내부 try/catch 블록을 가지고 가장 좋은 방법은

getRoute(): any { 
    return async (request: any, reply: any) => { 
     const result = new Promise<string>(async (resolve, reject) => { 
     try { 
      let userIsValid = await this.validator.validate(request.payload, RegisterUserValidator); 
      if (userIsValid.error) { 
      resolve(responseHelper.getErrorResponse(ResponseErrorCode.joiValidatorError, userIsValid.error)); 
      throw new ControlFlowNonError(); 
      } 
      let results = await this.authUser.registerUser(request.payload); 
      resolve(responseHelper.getSuccessResponse(results, null)); 
     } 
     catch (error) { 
      let message: ILogMessage = { 
      code: ResponseErrorCode.unknownError, 
      message: ResponseErrorCode.unknownError.toString(), 
      meta: error, 
      sourceFunction : 'ApiDataCreateCredentials: getRoute()' 
      }; 
      this.logHelper.error(message); 
      resolve(error); 
     } 
     }); 
     reply(result); 
    }; 
    }; 

Answer 1

인가?

아니요, 좋지 않습니다. promise executor 함수 내에서 약속을 사용할 이유는 거의 없습니다. 왜냐하면 당신이 그렇게 할 때, 당신은 외부에서, 수동으로 만들어진 약속을 전혀 필요로하지 않기 때문입니다. 내면의 약속을 되돌릴 수 있습니다. 그게 Promise constructor anti-pattern입니다.

FYI의 경우 여기서는 아니지만 약속 작성자 내에서 정규 예외를 처리하는 데는 try/catch을 사용하는 것이 합리적입니다 (수동으로 작성한 약속 실행자가 실제로 처음에 필요하고 일반적인 예외가 우려되는 경우). 로컬에서 처리하려고합니다.)

---

동일한 논리를 수행하는 방법에 대한 또 다른 아이디어가 있습니다. 이렇게하면 promise anti-pattern의 약속을 둘러싼 약속이 수동으로 생성 된 약속과 함께 제거되고 promise 흐름 제어를 사용하여 userIsValid.error이 로그 오류 코드로 이동합니다. 나는 여기에 기다리는 것을 사용하는 특별한 이점을 보지 못했기 때문에 .then()과 .catch()을 사용했다. 이 코드의 일반 자바 스크립트 버전 그래서 나는 타이프 라이터를 모르겠지만, 당신은 아마도 자신이 타이프 라이터로 다시 설정하는 약간의 문법 차이를 추가 할 수 있습니다 구현에 이상적인 보이지 않았다

getRoute(): function() { 
    return function(request, reply) { 
     return this.validator.validate(request.payload, RegisterUserValidator).then(userIsValid => { 
      if (userIsValid.error) { 
       // treat this as an error condition 
       throw responseHelper.getErrorResponse(ResponseErrorCode.joiValidatorError, userIsValid.error); 
      } 
      return this.authUser.registerUser(request.payload).then(results => responseHelper.getSuccessResponse(results, null)); 
     }).catch(error => { 
      let message: ILogMessage = { 
      code: ResponseErrorCode.unknownError, 
      message: ResponseErrorCode.unknownError.toString(), 
      meta: error, 
      sourceFunction : 'ApiDataCreateCredentials: getRoute()' 
      }; 
      this.logHelper.error(message); 
      // turn back into resolved promise with error as the result 
      return error; 
     }).then(reply);  // always call reply 
    } 
}  

것들 :

1. Promise anti-pattern (불필요한 래퍼 약속 생성). resolve() 여러 번 호출
2. 은 (두 번째는 무시하지만, 그런 식으로 코딩하는 이상적이지 보인다됩니다)
3. 여기 async/await을 사용하여 특정 혜택이있을 것 같지 않습니다. 그것은 내 의견으로는 흐름을 복잡하게하는 것처럼 보입니다.
4. resolve() 다음에 throw은 코드를 읽을 때 실제 머리를 쓴 사람입니다. 네, 결국 당신이하려는 일을 알아낼 수는 있습니다. 그러나 이것이 이상한 방법입니다. 내 계획은 조금 더 의미가 있습니다. if (userIsValid.error)은 정말로 당신을위한 오류 조건 일 뿐이므로이 방법으로 코딩하면 더욱 분명하게 알 수 있습니다. 그런 다음 모든 오류가 로깅 후 오류없이 처리되기를 원하기 때문에 .catch() 처리기를 정상적으로 반환하여 마지막 .then() 처리기가 항상 호출되도록합니다.당신의 주제와 관련된

기타 참조 :

Can't throw error from within an async promise executor function

Is it an anti-pattern to use async/await inside of a new Promise() constructor?