Retry Scope은 안정적인 수행을 위해서 자주 쓰인다.
기본적으로 Action 부분과 Condition으로 나뉘며,
Condition이 만족되지 않는 경우 혹은 Action 부분에서 에러가 났을 경우에만 Retry를 하게 된다.
1. 용도
Retry Scope는 보통 페이지가 이동될 때 그 트리거를 제대로 발동했는지 체크하기 위해 사용된다. 가령 클릭이 씹혀서 다음 단계로 못 나가는 케이스를 방지한다.
2. 장단점
Retry Scope은 사실 For each와 Try Catch의 조합으로 대체될 수 있다. 다만 그렇게 쓰는 것보단 훨씬 편하고 빠르게 쓸 수 있고 가독성도 좋은 편이라 자주 쓰인다. 그러나 에러났을 때 Retry Scope 내의 display name을 뱉어주지 않는다. 즉, Action중 어디서 에러가 났는지 알기 어렵다.
3. 주의점
위의 장단점, 용도를 생각하면 Retry Scope은 2가지 원칙을 가지고 써야 한다.
첫 째로 Action은 간결하게 짧게 끊어서 구성하며 트리거나 인식의 변화가 존재해야 한다.
두 번째로 Condition은 항상 입력해준다.
첫 번째 원칙은 간단하다. 디버깅이 힘드니까 쓰기 편한 만큼 짧게 짧게 끊어서 스텝 바이 스텝으로 체크해야 한다는 뜻이다. 두 번째 원칙은 Retry Scope에 대한 오해가 잦아서 나온 원칙이다. '에러나면 그냥 다시 해' 라는 식이나 '여기서 얼마나 대기해야 되는지 몰라서 반복해서 기다려'라는 식으로 쓰는 사람도 많기 때문이다. 그러나 그 경우 더 좋은 대체들이 얼마든지 있다. 특히 '반복해서 기다려'는 소스가 비효율적일뿐 원래 의도했던 결과라도 얻을 수 있는데, '에러나면 그냥 다시 해'라는 식으로 쓰게 되면 정작 클릭이 씹히는 경우 에러가 나지 않아 의도했던 결과를 얻지 못하게 된다.
++ 특이한 경우
Try Catch와 Retry Scope의 조합을 통해 For each-Try Catch를 더 간단하게 만들 수도 있다.
Retry Scope은 내부 세부 에러내용을 남기지 않지만 Try Catch를 안에 넣어 Exception 에러 로그를 찍어주고
재시도 하는 사이트도 있다.
이 경우 최종 Exception Message 컨트롤은 어려울 수 있으나 Break를 빼먹는 실수 등을 줄일 수 있다.
또한 로그는 실패하면서 남기 때문에 개발자가 디버그 하는 데는 크게 문제가 없다.
[역으로 현업에 스텝별 에러로그를 정해 보내고 싶다면 적절하지 않을 수 있다.]
