저는 프로젝트에서 @typescript-eslint/no-floating-promises 규칙을 사용합니다. 이런 코드를 작성하면 이 규칙이 불평할 것입니다 -
이 Promise 添加一个 catch 블록에 나를 원합니다. 예외 처리 블록에 일부 논리를 추가하려는 경우 이는 나에게 의미가 있습니다. 그러나 필요하지 않은 상황이 많이 있습니다. 오류가 발생하여 기쁩니다. 그래서 이 규칙으로 인해 발생하는 오류를 억제하기 위해 결국 이렇게 했습니다 -
catch 块，error 仍然会以相同的方式抛出（至少在我的控制台输出中看到它）。因此，我不明白显式指定此 catch 块的意义。我错过了什么吗？如果我添加/不添加 catch 块，抛出 error를 추가하지 않아도 정말 차이가 나나요? 
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
댓글 작성자는 모두 귀하의 질문에 잘 답변했습니다. 하지만 이것이 왜 중요한지 예를 들어 설명하기 위해 다음 코드를 상상해 보세요.
으아아아이 코드는 꽤 무해해 보입니다. 프로그램이 시작 후 1초 후에
'hello'기록되는 처리되지 않은 무작동 약속 거부가 있습니다.브라우저에서 바로 이런 일이 발생합니다. 브라우저는 "잡히지 않은 약속 거부" 오류를 기록하지만 그렇지 않으면 무시합니다.
그러나 NodeJS(Node v15 기준)에서 처리되지 않은 Promise 거부는 하드 오류입니다. 즉, 오류가 감지되면 프로세스가 종료됩니다!
터미널에서 코드를 실행하여 이를 확인할 수 있습니다(
으아아아-e는 "이 코드 문자열을 평가하고 실행"을 의미함)1초 전에 프로세스가 종료되었기 때문에
'hello'가 인쇄되지 않는 것을 볼 수 있습니다!작업이 예상대로 작동하는지 확인하려면 다음을 수행하세요.
으아아아.reject更改为.resolve:따라서 LTS 지원 버전을 사용하여 NodeJS 애플리케이션을 작성하는 경우 반드시 오류를 처리해야 합니다. 그렇지 않으면 예상치 못한 충돌이 발생할 위험이 있습니다.
코드가 브라우저에서만 실행된다면 실패를 처리해야 하는지 궁금할 것입니다. 결국 사용자는 콘솔을 보지 않기 때문에 나쁜 일이 발생했다는 것을 알지 못할 것입니다. 그렇다면 누가 신경쓰겠습니까? "코드 전용" 관점에서는 당신 말이 맞습니다. 그러나 사용자는 문제가 발생했을 때 애플리케이션으로부터 피드백을 받기를 원합니다.
다음 시나리오를 상상해 보세요. Promise는 사용자가 애플리케이션에 입력한 일부 데이터를 제출하는 API 호출의 결과를 추적합니다. 어떤 이유로 API 호출이 실패하면 애플리케이션은 적절하게 응답하고 사용자에게 문제가 있음을 알려야 합니다.
이를 처리하는 다른 방법은 앱이 무한 로딩 스피너를 표시하거나 사용자가 데이터가 실제로 제출되지 않았는데 성공적으로 제출되었다고 생각하는 것을 의미할 수 있습니다. 어느 쪽이든 - 매우 나쁘고 깨진 사용자 경험입니다!
결국에는
.catch(e => { throw e })这样的事情，你实际上并没有处理错误。当然，这段代码会使 linter 保持沉默 - 但您所做的只是创建一个新的、被拒绝的承诺，该承诺将记录到控制台。相反，您应该以某种方式将错误连接到应用程序的 UI，例如像.catch(e => {alert(e); throw e })처럼 간단한 일을 하는 것이 더 좋을 것 같습니다.