Page History
...
| Info | ||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
결함 처리를 이렇게 어렵게해? 의문을 제기할수 있습니다. 하지만 위와 같은 플랜을 가진 예외처리를 일반적인 OOP클래스로 코드로 직접 작성을 해보십시오 물론 위 케이스에한해서, 개발자에 따라 더 구조적이고 깔끔한 예외처리가가능할것입니다. 하지만 계속 유지보수가되고 있는 상황과 기존 모델이 할수 없는 문제점이 분명있으며 기존 예외처리모델(try/catch)는 다음과 같은 두가지 문제를 가지고 있습니다. 호출자에게 예외를 던지면, 대부분 호출자는 어떻게 처리해야할지 모름다음과 같이, 로컬에 파일이 추가 되면 DB까지 자동으로 적는 FileWatcher가 있다고 가정해봅시다.
기존 예외처리모델의 문제는, 호출자에게 책임을 계속 떠넘기는데 있습니다. 호출구조상 Stack의 윗부분에는 에러핸들링을 처리 하기위한 충분한 정보가 없습니다. 즉 D과정에 DbBrockenConnectionException 이 발생하고 이과정에서 예외가 발생하여 C의 예외처리기에 갔다고 했을시, C가가진 예외처보및 LogWrite기는 기존 DB접속에대한 정보가 없어서 재시도할 충분한 정보가 없습니다. 이것을 처리하기위해 LogWrite기에게 정보접속을 제공하고 객체를 공유하는것은 단순한 설계를 깨는것이며, 그렇게해서 처리한다고 해도..... try{ 시도} catch{ 또시도 } 이러한 부적절한 코드가 될것입니다. 책임을 지지않는 전역 Catch과거 예외 핸들링이 지원안되었을시, retun -1,switch(error) 이러한 코드로 일관성없는 에러처리를 위한 로직을 작성하였고 이것을 개선하고자 예외 처리모델이 나왔습니다. 예외를 발생시키고 , 어느곳에 집결을하여 예외 핸들링을 할수가 있어서 조금더 구조적인 예외 핸들링이 가능해졌습니다. Exception을 세부적으로 설계하고 구조적으로 Catch를 하여 일관성을 유지하는것 그것이 예외처리 모델에 기본이였습니다. 하지만 협업을 하면서 서비스코드내의 예외처리의 일관성이 유지가 되었는지 생각해볼필요가 있습니다.
장애가 발생했습니다. 하지만 이 처리자는 A,B작업이 어떻게 만들어졌는지 모르는 최근 합류자입니다.
이제는 C에서 처리하지 않은 예외가 D에 전가가 되었습니다.
결국 세부적 예외처리를 포기하고...
가상시나리오이지만, 자신의 서비스 코드에서 예외처리가 얼마나 서비스 흐름을 막고 있는지 생각해볼필요가 있습니다. 이것은 마치 GoTo 문을 고급기법으로 사용을 한것과 다름없습니다. AKKA에서는 부모가 자식(정확하게는 호출자)에게 예외를 전가시키지 않는 관리감독 전략을 통해 에러핸들링을 서비스 코드에서 분리하고, 최대한 서비스코드에서 에러처리를 분리하여 상위 부모에서 해결하려는 전략을 사용합니다. 생성에 관여한 부모액터가 가장 적절한 복구전략을 세울수 있기때문입니다.
|