Global Exception vs Try/Catch

[develofun]

현재 진행중인 프로젝트에 Global Exception과 Try/Catch를 사용하고 있는데요.

굳이 Try/Catch를 사용하지 않고 throw exception으로 던져서 Global Exception에서 로그남기고 예외 처리하면 되지 않나, 로그에 그에 맞는 메시지를 남기면 되지 않나 라는 의견이 있었는데요.

제 개인적인 의견으로는 Global Exception은 Try/Catch로 처리되지 못한 것들에 대해 최후의 보루로 생각하고 Try/Catch를 사용해서 각 예외가 발생한 위치와 발생 원인에 따라 분기하여 로그를 남기고 그에 맞는 처리 로직을 짜는 게 유지보수나 문제 해결을 좀 더 원활하게 해줄 것 같은데 어떻게들 생각하시나요?

[Vincent]

try-catch는 최대한 짧은 구간에서 사용하는 것이 맞다고 생각합니다.
그리고 개발할 때는 쓰되, 배포할때는 빼야하는 것이지요.
그것이 충분한 테스트를 했다 라는 증거입니다.
충분한 테스트는 개발자의 자신감과 제품에 대한 디테일과 신뢰로 직결됩니다.

돌고 있는 프로그램이 죽는 다는 것은 말이 안되기 때문에 Global Exception은 필요하다고 생각합니다.
하지만 세부적으로 있는 try - catch들은 짧게 짧게 해서 디테일하게 하시는 것이 맞습니다.
그리고 예측이 가능한 선에서 try catch없이 예외를 생각해내고 처리했다면 제거해야하는 것이지요.

쓰는 프로그램이 global exception이 없어서 죽는 것은 도메인에 따라 매우 치명적일 수 있습니다.
일반 ERP 업계에서는 크게 치명적이지 않을 수 있으나 (물론 그것도 회사마다 다름), FA 같은 공장 자동화 쪽에서는 기계에서 주는 값이 노이즈를 발생시켜서 파싱이 불가능하게 값이 들어와서 프로그램이 오류가 났을 경우, 기계를 제어하는 프로그램 종료되는데 기계는 종료 명령을 받지 못했으므로 계속해서 돌고 있을 수 있습니다.
그래서 Global Exception이 필요하고 Windows Event Viewer도 필요한 것입니다.

Try - Catch를 배포 후 런타임에서 제거해야하는 이유는 사람마다 여러가지가 있겠지만, catch에 예외가 발생했을 경우 Exception 객체 생성을 위해 오버헤드가 발생하여 약간이지만 느려짐이 있기 때문입니다. (사람은 보통 체감 불가능)
단순히 try의 scope 안에 들어왔다고 해서 코드가 느려지는 것도 아니고, try 다음에 finally로 빠졌다고 해서 코드가 느려지는 것도 아니고, catch에 걸렸을 때 오버헤드가 발생하고 컴퓨터입장에서 느려지는 것입니다.

try-catch를 문장마다 짧게 걸지않고 러프하게 길게 길게 건다는 것은,
개발자가 자신의 코드에 자신이 없다는 뜻이며, 예외를 특정할 의지가 없다는 뜻이고, 예외가 세부적으로 구분되어있지 않아서 추후 유지보수 할 때 예외의 내용까지 모두 파악해야한다는 것입니다.
그 소스코드를 유지보수하게 될 미래의 나와 동료의 시간을 갉아 먹는 것이지요.

제가 추천하는 방법은 유닛테스트 를 적극 활용하는 것입니다.
객체지향인 모델들을 추상화하여 라이브되는 프로젝트에 개발을 해놓고 그 기능을 그대로 유닛테스트 프로젝트에서 예외가 발생할만한 값들에 대해 넣고 유닛테스트에 try-catch를 거는 것입니다.

이 방식의 장점은 catch에 걸려서 예외가 발생하는 case 들을 특정할 수 있고, 그것이 소스코드로 누적이되며, 언제든 VS의 테스트탐색기를 통해 내가 원할 때 예외를 발생시켜볼 수 있다는 것입니다.
이렇게 해서 충분한 테스트가 되면 배포되는 라이브 소스코드에는 try-catch를 제거할 수 있습니다.

[nyjin]

asp.net core의 global exception을 말씀하시는 것으로 이해한다면 exception 발생시 stacktrace나 예외 메시지에 대한 일반적인 정보들을 모아 클라이언트에 전달하는 수준의 기본적인 예외 메시지와 500 응답으로 처리가 가능해보입니다
말씀처럼 API를 구성하다보면 예외 처리와 응답을 세분화하여 처리할 일들이 발생됩니다.
예를 몇가지 들어보겠습니다.

• 요청 값이 충분하지 않을 때 400 bad request를 처리
• ef core와 같은 orm을 쓸때 save 시점에 중복 id insert에 대한 예외 처리로 422 처리
• api 내에서 다른 api를 호출할때 대상 api 서버에서 특정 시간동안 응답을 주지 않거나 예외를 전달하는 경우 예외로 잡아 3회 재시도를 구성

각 controller, service 등의 서비스 레이어상에서 발생되는 다양한 서비스 시나리오의 예외 처리 구현은 서비스 품질을 더욱 높여줄 것이라 생각되서 의견에 동의합니다.