티스토리 뷰
[!이시중] 2021년 10월 26일 21:53에 최초 작성된 글로써 원글은 https://yuniel.tistory.com/41 에서 확인할 수 있음.
지난번 프론트에서 에러를 로깅하는 방법 중 하나인 sentry 관련 포스팅을 진행하며, 프론트엔드에서 에러 처리하는 방법에 대하여 정리해 봐야겠다는 생각이 들었다. 막상 정리하고 보니 너무나 기본 문법들이었는데, 안일한 마음에 나도 많이 놓치고 있었던 부분들이었다. 다만, 프론트엔드 내부에서의 일시적인 에러 처리이며, 에러 관련 데이터 수집 등에는 다소 비효율적이라는 한계가 있다.
https://hyermione.tistory.com/5
TypeScript
필자도 한 한 달 정도의 아주 얕게 맛보기로 타입 스크립트를 사용해 본 적이 있다. 당시 타입스크립트를 거두어 낸 이유는 vue2로 개발하던 서비스에 타입스크립트 얹기란 무의미한 기능들이 많이 있었고, 빠른 스케줄링 사이에서 많은 개발자가 type의 정의를 any로 두고 썼기 때문에 쓸 이유가 없다고 생각되었다. 가장 결정적인 이유는 당시 사용하던 라이브러리가 타입스크립트를 지원하지 않은 부분이었다.
하지만 대다수의 JS팀들은 타입스크립트를 사용한다.
다이나믹함이 특징인 자바스크립트는 데이터가 변화 할 때마다 실시간으로 데이터의 타입이 함께 변화되어진다. 수시로 변동하는 상황에서 타입 에러를 종종 맞이하게 되는데, 사용자 액션 중 일부분에서 타입 에러가 발생하여 다음 단계로 넘어갈 수 없다면 이처럼 최악인 상황이 어디있을까.
프론트엔드 내에서 최소한이라도 타입 에러를 방지할 수 있는 방법은 타입 스크립트를 사용하는 것이다.
Try-catch || Try-catch-finally
try {
/**
* 수행/실행하고 싶은 로직
* 정상으로 수행 된다면 문제없이 거치는 블록문
*/
} catch (error) {
/**
* try문에서 error 발생 시, 수행되는 로직
* error의 객체를 받아올 수 있음
* 에러에 따른 처리 로직 수행 가능
*/
} finally {
/**
* 로직의 성공/실패 여부와 상관없이 try문 종료 시, 무조건 실행되는 로직
*/
}
다음과 같은 구문을 사용한다면 100%의 보장은 없지만 임시방편으로 에러를 처리할 수 있다.
다만, 어디에서 에러가 발생하는지 하나씩 찾지 않는 이상 레포팅이 되지 않는다는 점 (물론 로직에 따라 DB에 로그를 저장할 수 있지만 순전히 프론트엔드에서만 처리하기에는 한계가 있다. 또한 개인적으로 많은 네트워크 비용이 야기될 거란 우려도 있다.). 에러 처리 로직에서 또 다른 에러를 야기할 수 있다는 점. 모든 로직에 대하여 해당 구문을 사용함으로써 많은 공수와 긴 코드를 야기한다는 점 등의 우려가 있다. 물론 잘 정리할 수 있고, 특정 컨벤션에 따라 진행한다면 좋은 방법이 될 수 있다.
throw
throw는 사용자에 의하여 임의로 정의된 예외를 처리할 때 사용되어진다. throw문이 실행되면 이후의 코드는 실행되지 않는다.
if (typeof text !== String) {
throw 'String 형식이 아닙니다.'
}
/**
* 기존에 실행하고자 하는 로직
*/
throw문은 try-catch문과 만나면 더욱 강력해지는 장점이 있다.
try {
if (typeof text !== String) {
throw {
why : 'String 형식이 아닙니다.'
}
}
/**
* 기존에 실행하고자 하는 로직
*/
} catch (error) {
console.log(error.why);
}
try {
if (typeof text !== String) {
throw new Error('String 형식이 아닙니다.');
}
/**
* 기존에 실행하고자 하는 로직
*/
} catch (error) {
console.log(error.message);
}
첫번째 예시처럼 throw는 한 문장으로 쓸 수도 있지만, Object 형식으로 선언해도 됨을 보여주기 위하여 예시 코드를 작성해보았다. 보는 것 처럼 try-catch문에서는 throw가 catch로 넘어가는 error가 되어 원하는 조건에 맞는 error처리 로직을 개발할 수 있다는 장점이 있다.
역시도 개발자의 섬세함이 돋보여야 하는 방법이다.
'JavaScript > JS' 카테고리의 다른 글
DOM과 virtualDom. 그리고 shadowDom인데 이제 섀도우 돔을 중심으로 (0) | 2022.06.15 |
---|---|
console API 란? (0) | 2022.05.20 |
JS setTimeout에 event loop / task Queue / call Stack을 곁들인.. (0) | 2022.05.18 |
JS 커스텀 이벤트(custom Event) 생성 및 실행(dispatchEvent) (0) | 2022.05.17 |
[JavaScript 물음표] Optional Chaining - 옵셔널 체이닝 (0) | 2022.03.08 |
- Total
- Today
- Yesterday
- vue
- 모바일사파리
- js
- 리액트상태관리
- gitRebase
- 프론트엔드
- 리액트훅
- 김민태
- 사파리
- Git
- 리코일
- 센트리모니터링
- CSS
- 깃명령어
- npm
- 자바스크립트
- javascript
- frontend
- 센트리
- 깃
- 리액트
- react
- BFCache
- 크롬
- sentry
- 프론트앤드
- storybookUI
- reacthook
- js테스트
- TIL
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |