Skip to content

Commit c0283f8

Browse files
committed
update custom-errors article to reflect latest version
1 parent cfabea0 commit c0283f8

1 file changed

Lines changed: 7 additions & 6 deletions

File tree

1-js/10-error-handling/2-custom-errors/article.md

Lines changed: 7 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -13,6 +13,7 @@
1313
사용자 데이터가 저장된 JSON을 읽는 함수 `readUser(json)`가 있다고 해봅시다.
1414

1515
유효한 `json`은 다음과 같은 형태이어야 합니다.
16+
1617
```js
1718
let json = `{ "name": "John", "age": 30 }`;
1819
```
@@ -21,9 +22,9 @@ let json = `{ "name": "John", "age": 30 }`;
2122

2223
따라서 `readUser(json)`은 JSON 형식의 데이터를 읽을 수 있을 뿐만 아니라, 데이터를 '검증'할 수 있어야 합니다. 필수 프로퍼티가 없거나, 위 형식에 맞지 않으면 에러를 발생시킬 수 있어야 하죠. 그런데 이때 발생하는 에러는 `SyntaxError`가 아닙니다. JSON 형식은 맞지만, 자체 기준에 맞지 않기 때문에 발생한 에러이므로 전혀 다른 종류의 에러이죠. 지금부턴 이 에러를 `ValidationError`라고 부르겠습니다. 자 이제 `ValidationError`를 위한 클래스를 만들어봅시다.
2324

24-
`ValidationError` 클래스엔 문제가 되는 필드 정보가 저장되어야 합니다. 내장 클래스 `Error`를 상속받아 `ValidationError` 클래스를 만들어봅시다.
25+
`ValidationError` 클래스는 `Error` 클래스를 상속받아야 합니다.
2526

26-
그 전에 먼저 잠시 슈도 코드로 `Error` 클래스가 어떻게 생겼는지 살펴보겠습니다.
27+
`Error` 클래스는 자바스크립트 내장 클래스인데, 상속 구조를 이해하기 위해 슈도 코드로 살펴보겠습니다.
2728

2829
```js
2930
// 자바스크립트 자체 내장 에러 클래스 Error의 '슈도 코드'
@@ -119,7 +120,7 @@ try {
119120
// ...
120121
```
121122
122-
그런데 에러 유형 확인은 `err.name`보다는 `instanceof`를 사용하는 게 훨씬 좋습니다. 나중에 `ValidationError`를 확장하여 `PropertyRequiredError` 같은 새로운 확장 에러를 만들게 될 텐데, `instanceof`는 새로운 상속 클래스에서도 동작하기 때문입니다.
123+
그런데 에러 유형 확인은 `err.name`보다는 `instanceof`를 사용하는 게 훨씬 좋습니다. 나중에 `ValidationError`를 확장하여 `PropertyRequiredError` 같은 새로운 확장 에러를 만들게 될 텐데, `instanceof`는 새로운 상속 클래스에서도 동작하기 때문입니다.
123124
124125
`catch`에 알려지지 않은 에러가 있을 때 이 에러는 재 던지기 된다는 점(`(**)`) 또한 주목해서 봐주시기 바랍니다. `catch` 블록에선 유효성 검사와 문법 오류만 처리하고, 다른 종류의 에러는 밖으로 던져야 합니다.
125126
@@ -233,8 +234,8 @@ try {
233234
throw err; // 알 수 없는 에러는 다시 던지기 함
234235
}
235236
}
236-
```
237-
237+
```
238+
238239
위 스키마엔 두 종류의 에러만 나와 있네요. 그런데 에러의 종류는 더 추가될 수 있습니다.
239240
240241
이쯤 되면 "미래에 `readUser` 기능이 커지면서 에러 종류가 많아질 텐데 그때마다 에러 종류에 따라 에러 처리 분기문을 매번 추가해야 하나?"라는 의문이 생길 수 있습니다.
@@ -319,7 +320,7 @@ try {
319320
320321
이제 `readUser`는 위에서 설명한 것처럼 동작합니다. Syntax 에러나 Validation 에러가 발생한 경우 해당 에러 자체를 다시 던지기 하지 않고 `ReadError`를 던지게 됩니다.
321322
322-
이렇게 되면, `readUser`를 호출하는 바깥 코드에선 `instanceof ReadError` 딱 하나만 확인하면 됩니다. 에러 처리 분기문을 여러 개 만들 필요가 없어집니다.
323+
이렇게 되면, `readUser`를 호출하는 바깥 코드에선 `instanceof ReadError` 딱 하나만 확인하면 됩니다. 에러 처리 분기문을 여러 개 만들 필요가 없어집니다.
323324
324325
'예외 감싸기'란 이름은 종류별 에러를 좀 더 추상적인 에러, `ReadError`에 하나로 모아(wrap) 처리하기 때문에 붙여졌습니다. 이런 기법은 객체 지향 프로그래밍에서 널리 쓰이는 패턴입니다.
325326

0 commit comments

Comments
 (0)