Page History
...
Expand | ||
---|---|---|
| ||
[INFO][2017-09-13 오전 7:34:22][Thread 0029][[akka://ServiceA/user/supervisor#740151541]] CreateChildActor:child1 |
Info |
---|
결함 처리를 이렇게 어렵게해? 의문을 제기할수 있습니다. 하지만 규모가 큰 서비스코드를 생각해봅시다. 과거 예외 핸들링이 지원안되었을시, retun -1,switch(error) 이러한 코드로 일관성없는 에러처리를 위한 로직을 작성하였고 이것을 개선하고자 예외 처리모델이 나왔습니다. 예외를 발생시키고 , 어느곳에 집결을하여 예외 핸들링을 할수가 있어서 조금더 구조적인 예외 핸들링이 가능해졌습니다. Exception을 세부적으로 설계하고 구조적으로 Catch를 하여 일관성을 유지하는것 그것이 예외처리 모델에 기본이였습니다. 하지만 협업을 하면서 서비스코드내의 예외처리가 일관성이 유지가 되었는지 생각해볼필요가 있습니다.
장애가 발생했습니다. 하지만 이 처리자는 A,B작업이 어떻게 만들어졌는지 모르는 최근 합류자입니다.
이제는 C에서 처리하지 않은 예외가 D에 전가가 되었습니다.
결국 세부적 예외처리를 포기하고...
가상시나리오이지만, 자신의 서비스 코드에서 예외처리가 얼마나 서비스 흐름을 막고 있는지 생각해볼필요가 있습니다. 이것은 마치 GoTo 문을 고급기법으로 사용을 한것과 다름없습니다. AKKA에서는 부모가 자식에게 예외를 전가시키지 않는 관리감독 전략을 통해 이문제가 복잡해지지 않게 일관성을 유지하려고 장치를 제공하며 후속 플랜도 개발자가 직접 할수있게 추상화를 해놓은것입니다. 이것은 액터생성시 애시당초 탑다운 방식으로 관계도 형성을 명확하게 구조화하기때문에 가능한 전략입니다. |