1. 단순히 에러를 확인만 하지 않는다.
- 에러를 확인했다면 그에 대한 계획이나 장치를 마련해야 한다.
// BAD - 출력만 하면 에러 로그를 잃어버리기 쉽다.
try {
functionThatMightThrow();
} catch (error) {
console.log(error);
}
// GOOD
try {
functionThatMightThrow();
} catch (error) {
// 1. console.error는 console.log보다 조금 더 알아채기 쉽다.
console.error(error);
// 2. 유저에게 에러를 알린다.
notifyUserOfError(error);
// 3. 서비스 자체에 에러를 기록한다.
reportErrorToService(error);
// 4. 그 외..
}
2. Promise가 실패된 것을 무시하지 않는다.
- 위와 같은 이유다. 계획이나 장치를 마련해야 한다.
// BAD
getdata()
.then(data => {
functionThatMightThrow(data);
})
.catch(error => {
console.log(error);
});
// GOOD
getdata()
.then(data => {
functionThatMightThrow(data);
})
.catch(error => {
// 1. console.error는 console.log보다 조금 더 알아채기 쉽다.
console.error(error);
// 2. 유저에게 에러를 알린다.
notifyUserOfError(error);
// 3. 서비스 자체에 에러를 기록한다.
reportErrorToService(error);
// 4. 그 외..
}
'프론트엔드 > JavaScript' 카테고리의 다른 글
[JavaScript] Clean Code - 11. 주석(Comments) (0) | 2021.08.28 |
---|---|
[JavaScript] 클린 코드 - 10. 포맷팅(Formatting) (0) | 2021.08.28 |
[JavaScript] 클린 코드 - 8. 동시성 (Concurrency) (0) | 2021.08.26 |
[JavaScript] 클린 코드 - 7. 테스팅 (0) | 2021.08.26 |
[JavaScript] 클린 코드 - 6. SOLID (0) | 2021.07.04 |