오늘 퇴근하고 길을 걸으며 문득 try catch문에 대한 중요성이 생각이 났다.
try catch문은, 개발을 하면서 언제 어떻게 발생할지 모르는 변수에 대해서 비교적 쉽게 해결 방법에 대한 접근이 가능하다고 생각된다.
말 그대로, try 하다가 에러가 발생하면 ~하게 처리해라(catch)라는 의미다.
단적인 예를 들면 이와 같다.
파라미터가 정수인지 판단하는 아주 간단한 메서드이다.
예시는 아주 간단하지만, 만약 이 코드가 더 길어지고 DB에 붙어서 트랜잭션을 처리해야 하거나,
그 외에 비즈니스 로직을 처리하다 보면 더 다양한 Exception이 발생할 수 있다.
여하튼, 간단하게 매개변수가 인풋인지를 판단해야 하는데 try catch문을 만약 안 쓰게 되면
수많은 오류가 발생할 수 있다.
메인 메서드를 위와 같이 두고 실행해보자.
case 1, case 2는 문자와 숫자가 파싱이 잘 됐기 때문에 무리 없이 실행이 됐지만
3번째 케이스는 숫자가 아니기 때문에 NumberFormatException이 발생했다.
이렇게 되면 프로세스가 중간에 끊겨버리게 되고, 예기치 않은 상황이 발생할 수 있다.
만약에 여기에 DB가 붙어있다거나, 외부 API를 호출하게 되는 부분이 추가되어 있다면,
데이터 무결성 검증을 위해서 많은 고생을 해야 하고 클라이언트로부터 데이터에 대한 신뢰성이 떨어질 수 있다.
하지만
try catch문을 잘 사용한다면 지속적인 QA 및 테스트를 통해 데이터의 무결성을 높이는 과정을 보다 쉽게 접근이 가능하다.
코드를 try catch를 사용해 아래처럼 바꿔보면
아까완 달리 case 3가 잘 출력된 것을 볼 수 있다.
이렇게 되면 예외에 케이스에 대해 로직을 마무리 지을 수 있고, 아까보단 에러 및 예외 상황에 대한 접근이 비교적 쉽다.
프로덕션으로 내기 전에 이런 로컬 테스트 및 QA를 거쳐 프로그램을 develop을 시켜야 하고 예외 케이스에 대한 준비를 해두어야 한다.
비록 찜찜하게 아래에 Exception이 출력되긴 했지만 저건 e.printStackTrace() 때문에 출력이 된 거다.
로컬 테스트 환경에서 익셉션을 가독성 있게 확인하기 위해 출력한 것이다.
e.printStackTrace()가 없으면 콘솔이 출력되지 않는다.
이와 반대로 예외 상황을 커스텀하게 만들 수 있다.
위 코드를 그대로 사용해서 설명을 이어 나간다.
위 메서드는 파라미터가 숫자이면서 1000이 넘지 않는지 판단하는 메서드이고,
1000이 넘어가면 오류를 발생시킨다.
결과 -
1번째 케이스는 파싱 한 문자열이 숫자이면서 1000도 넘지 않아 true가 리턴되었고,
2번째 케이스는 숫자이지만 1000이 넘어가서 Exception을 발생시켰고, 인자로 넘긴 문자열이 콘솔 창에 출력이 됐다.
API를 개발할 때, HttpStatus Code처럼 일정 조건을 만족하지 않으면 커스텀한 익셉션을 던질 수 있다.
댓글