일반적으로 소스품질에서 Exception과 로깅이 차지하는 비중은 대단히 높다.
특히 비지니스 측면에서 고객만족도와 매우 연관성이 크다.
따라서 exception의 구분과 컨트롤은 프로 개발자라면 비지니스 로직만큼 공을 들여야 한다.
소스가 컴파일되고 순서대로 실행되는 과정에서 예외로 처리되는 것은 크게 2가지로 나뉘게 된다.
1) 인식불가 및 예상하지 못한 오류
- System Exception
2) 인식 및 예상가능한 오류
- Application Exception
- Business Rule Exception
개념적으로 System Exception은 폭넓은 의미 / 좁은 의미를 가진다.
폭넓은 의미로는 모든 소스에서의 Exception의 의미이고 좁은 의미에서는 예상하지 못한 모든 Exception이다.
여기서 하나 짚고 넘어가야 할 부분은 '인식 및 예상 가능하다'는 말의 의미이다.
RPA에서 인식 및 예상 가능하다는 의미는 고의로 예외로 처리한다는 뜻이다.
인식 및 예상가능한 에러는 Throw하지 않으면 에러가 나지 않고 진행될 수도 있으나
데이터 정합성에 문제가 생기거나 이후 프로세스에서 문제가 발생하는 에러이다.
Application Exception은 특정 시스템이 점검 등의 이유로 접속되지 않는 것을 어떤 특정값으로 확인할 수 있는 경우, 세션이 나가면 작업이 불가능해 고의로 에러를 내고 새롭게 시도를 해야 되는 경우 등에 쓸 수 있다.
Application Exception은 일반적으로는 적극적으로 쓰이지는 않는다. 대부분의 경우 예상하기 어렵기도 하거니와 그런 에러가 나면 Retry 할 수 있게끔만 만들어 놓으면 되기 때문이다. 다만 프레임워크 구조상 System Exception중 Exception Message를 구체적으로 가져갈 필요가 있는 경우는 자주 쓰기도 한다.
[Exception의 Try Catch 처리가 시퀀스 단위가 아니라 Business Logic 단위로 되어있는 경우, 안쪽에서 Exception이 발생하면 해당 Xaml의 인수값의 전달이 실패하는 특성때문에 그렇다. 개인적으로는 이런 프레임워크는 로깅 관리가 어렵다는 점 때문에 선호하지 않지만, 그런 경우 일부러 안쪽에서 Catch에서 메세지를 담아 Throw 하는 경우가 있다.]
Business Rule Exception은 프로세스상 정합성이 맞지 않는 경우의 예외이다.
Business Exception은 소스상 오류는 아니나 데이터 정합성이 맞지 않는다든가, 프로세스 정합성이 맞지 않아 미리 인식하고 종료해야 하는 경우 많이 쓰인다.
보통 재시도를 하지 않고 끝내기 때문에, 전체 재시도 하는 로직이라면 필히 Catch의 BusinessRule Exception란에 Break를 넣어주자.
이 개념을 알고 Sequence단위 FrameWork를 보면 훨씬 이해가 잘 된다.