[프라미스와 에러 핸들링] 보와

Author: Violet-Bora-Lee

1-js/11-async/04-promise-error-handling/article.md

@@ -1,9 +1,9 @@
 
 # 프라미스와 에러 핸들링
 
-프라미스 체인은 에러를 잘 처리합니다. 프라미스가 거부되면 제어 흐름이 제일 가까운 rejection 핸들러로 넘어갑니다. 이는 실무에서 아주 유용하게 사용됩니다.
+프라미스가 거부되면 제어 흐름이 제일 가까운 rejection 핸들러로 넘어가기 때문에 프라미스 체인을 사용하면 에러를 쉽게 처리할 수 있습니다. 이는 실무에서 아주 유용한 기능입니다.
 
-존재하지 않는 주소를 `fetch`에 넘겨주는 예시를 살펴봅시다. 에러가 발생하지만 `.catch`를 사용해 에러를 처리할 수 있습니다.
+존재하지 않는 주소를 `fetch`에 넘겨주는 예시를 살펴봅시다. `.catch`에서 에러를 처리합니다.
 
 ```js run
 *!*
@@ -13,9 +13,9 @@ fetch('https://no-such-server.blabla') // 거부
   .catch(err => alert(err)) // TypeError: failed to fetch (출력되는 내용은 다를 수 있음)
 ```
 
-위 예시를 통해 알 수 있듯이 `.catch`는 바로 나올 필요가 없습니다. 하나 혹은 여러 개의 `.then` 뒤에 올 수 있습니다.
+예시에서 보듯 `.catch`는 첫번째 핸들러일 필요가 없고 하나 혹은 여러 개의 `.then` 뒤에 올 수 있습니다.
 
-이번엔 사이트에는 아무런 문제가 없지만, 응답으로 받은 JSON의 형식이 잘못된 경우를 살펴보겠습니다. 가장 쉬운 에러 처리 방법은 체인 끝에 `.catch`를 붙이는 것입니다.
+이번엔 사이트에는 아무런 문제가 없지만 응답으로 받은 JSON의 형식이 잘못된 경우를 살펴봅시다. 가장 쉬운 에러 처리 방법은 체인 끝에 `.catch`를 붙이는 것입니다.
 
 ```js run
 fetch('/article/promise-chaining/user.json')
@@ -38,11 +38,11 @@ fetch('/article/promise-chaining/user.json')
 */!*
 ```
 
-정상적인 경우라면 `.catch`는 절대 트리거 되지 않습니다. 그런데 네트워크 문제, 잘못된 형식의 JSON 등으로 인해 프라미스 중 하나라도 거부되면 `.catch`에서 에러를 잡게 됩니다.
+정상적인 경우라면 `.catch`는 절대 트리거 되지 않습니다. 그런데 네트워크 문제, 잘못된 형식의 JSON 등으로 인해 위쪽 프라미스 중 하나라도 거부되면 `.catch`에서 에러를 잡게 됩니다.
 
 ## 암시적 try...catch
 
-프라미스 executor와 프라미스 핸들러 코드 주위엔 '보이지 않는 `try..catch`'가 있습니다. 예외가 발생하면 암시적 `try..catch`에서 예외를 잡고, 이를 reject처럼 다룹니다.
+프라미스 executor와 프라미스 핸들러 코드 주위엔 '보이지 않는(암시적) `try..catch`'가 있습니다. 예외가 발생하면 암시적 `try..catch`에서 예외를 잡고 이를 reject처럼 다룹니다.
 
 예시:
 
@@ -64,7 +64,7 @@ new Promise((resolve, reject) => {
 }).catch(alert); // Error: 에러 발생!
 ```
 
-executor 주위의 '암시적 `try..catch`'는 자동으로 에러를 잡고, 이를 거부상태의 프라미스로 변경시킵니다.
+executor 주위의 '암시적 `try..catch`'는 스스로 에러를 잡고, 에러를 거부상태의 프라미스로 변경시킵니다.
 
 이런 일은 executor 함수뿐만 아니라 핸들러에서도 발생합니다. `.then` 핸들러 안에서 `throw`를 사용해 에러를 던지면, 이 자체가 거부된 프라미스를 의미하게 됩니다. 따라서 제어 흐름이 가장 가까운 에러 핸들러로 넘어갑니다.
 
@@ -92,13 +92,13 @@ new Promise((resolve, reject) => {
 }).catch(alert); // ReferenceError: blabla is not defined
 ```
 
-마지막 `.catch`는 이렇게 명시적인 거부뿐만 아니라 핸들러 위쪽에서 비정상적으로 발생한 에러 또한 잡습니다.
+마지막 `.catch`는 이렇게 명시적인 거부뿐만 아니라 핸들러 위쪽에서 발생한 비정상 에러 또한 잡습니다.
 
 ## 다시 던지기
 
-체인 마지막의 `.catch`는 `try..catch`와 유사한 역할을 합니다. `.then` 핸들러를 원하는 만큼 사용하다 마지막에 `.catch` 하나만 붙이면, `.then` 핸들러에서 발생한 모든 에러를 처리할 수 있습니다.
+체인 마지막의 `.catch`는 `try..catch`와 유사한 역할을 합니다. `.then` 핸들러를 원하는 만큼 사용하다 마지막에 `.catch` 하나만 붙이면 `.then` 핸들러에서 발생한 모든 에러를 처리할 수 있습니다.
 
-일반 `try..catch`에선 에러를 분석하고, 처리할 수 없는 에러라 판단되면 다시 던질 때가 있습니다. 프라미스에도 유사한 일을 할 수 있습니다.
+일반 `try..catch`에선 에러를 분석하고, 처리할 수 없는 에러라 판단되면 에러를 다시 던질 때가 있습니다. 프라미스에도 유사한 일을 할 수 있습니다.
 
 `.catch` 안에서 `throw`를 사용하면 제어 흐름이 가장 가까운 곳에 있는 에러 핸들러로 넘어갑니다. 여기서 에러가 성공적으로 처리되면 가장 가까운 곳에 있는 `.then` 핸들러로 제어 흐름이 넘어가 실행이 이어집니다.
 
@@ -117,7 +117,7 @@ new Promise((resolve, reject) => {
 }).then(() => alert("다음 핸들러가 실행됩니다."));
 ```
 
-`.catch` 블록이 정상적으로 종료되었기 때문에 다음 성공 핸들러, `.then`이 호출된 것을 확인할 수 있습니다.
+`.catch` 블록이 정상적으로 종료되었기 때문에 다음 성공 핸들러 `.then`이 호출된 것을 확인할 수 있습니다.
 
 `.catch`를 활용한 또 다른 사례를 살펴봅시다. `(*)`로 표시한 핸들러에서 에러를 잡는데, 여기서는 에러를 처리하지 못하기 때문에(`URIError` 처리 방법만 알고 있음) 에러를 다시 던집니다.