posts/how-to-handle-errors-1

[utterances-bot]

에러 처리를 어떻게 하면 좋을까? - 1 | rinae's devlog

에러 처리를 일관된 형태로 하기 위한 고민 이야기, 첫 번째

https://rinae.dev/posts/how-to-handle-errors-1?fbclid=IwAR2XrFhVvRy2JgNwe5y8aNOUNKOGJ3ZvQkjKVAuhAV3uUyLDbUn6mzU1AnU

[amorfati0310]

안녕하세요 도형님 에러처리를 어떻게 하면 좋을까 글을 잘 읽었습니다. 글 중에 궁금한 부분이 있어서 질문드려요 catch (e) <- 저 e 의 타입을 보장할 수 없다는 구문에서 궁금증이 생겨서 질문드려요

1. 타입체크를 하는 의의? 일일이 속성 검사? 어떤 부분을 검사하는 건지 왜 하는 건지 잘 모르겠어서 질문드립니다. 단순 추측으로는 이런 이유로 체크하는 건가 해봤는데
   • error 가 아닌 다른 객체가 들어올 수 있어서 체크하는 건지?
   • error 중에 customError들로 분기처리를해서 처리하기 위해서 type check를 하는 건지? 궁금합니다

[adhrinae]

@amorfati0310 안녕하세요 답변이 늦어 죄송합니다. 댓글 달린 것을 본 직후에 '조금 이따가 시간 되면 달아야지' 하고 잊어버리고 있던걸 방금 발견했네요.

추측하신대로 타입체크를 하는 이유는 여러 단계에 걸쳐 서브루틴이 호출되고 있을 때 상황에 따라 다른 에러가 던져져야 할 때 어떤 에러가 원인이 되었는지 파악하기 위해서였습니다.

하지만 가능하다면 여러 에러를 검사할 수 있도록 만들지 말고 하나의 콜스택 안에서 가능하다면 하나의 에러만 발견되는 것이 좋겠죠. 하지만 여기서 하나 예외가 있습니다. 바로 라이브러리의 API를 사용했을 때입니다. 특정 라이브러리에서 문제가 발생하여 에러를 던졌는데, 굳이 그 에러는 처리하고 싶지 않고 제가 만든 커스텀 에러만 처리하고 싶다면 타입체크를 하는 것이 도움이 될 수도 있겠죠.

그리고 궁극적으로 타입스크립트의 타입 안정성을 높이고자 하는 생각도 있었습니다. e 의 타입을 타입스크립트에서 보장하려면 적절한 타입 가드가 필요하거든요.