디버깅은 프로그램의 오류를 수정하는 작업으로, 프로그램의 개발에 있어 가장 많이 시간이 소요되는 작업이다. 프로그램을 설계하고, 설계된 내용에 따라 코딩을 하고, 코딩된 내용을 디버그하는 반복적인 작업을 통해 하나의 모듈이 만들어 지며 이러한 모듈이 모여서 프로그램이 만들어 진다. 

이중 가장 시간을 많이 소요되는 것은 단연코 디버깅 작업인 것이다. 개발자인 우리가 얼마나 많은 시간을 디버깅을 하면서 보냈는지, ‘.’을 제대로 찍지 않아서 또는 오타로 인해, 까만 밤을 하얗게 지새며, 결국 아주 사소한 것으로 밝혀졌을 때 ‘내 탓이오, 내 탓이오’를 외치며 가슴을 쳐 댔는지는 개발을 해 본 사람이 아니면 느낄 수 없는 비애일 것이다. 

프로그램의 오류에는 문법적인 오류, 프로그램의 로직상의 오류, 시스템적인 오류 등으로 나눌 수 있다. 

첫째, 문법적인 오류는 컴파일러가 오류내역을 알려주기 때문에 개발언어의 문법에 익숙하다면 그다지 시간이 소요되진 않는다. 물론 간혹 특이한 문법적인 요소를 써야하는 경우로 인해 애를 먹을 때도 있지만, 다른 오류에 비하면 비교적 적인 시간이 소요된다. 

둘째, 프로그램 로직상의 오류는 개발하고자 하는 업무흐름을 개발자의 실수로 인해 (+)를 해야 할 때 (-)를 한다던지 혹은 변수명을 잘못 코딩거나, Oevrridng이 되어야 했는 데 함수명을 잘 못 쓰는 바람에 Overridng이 되지 않으면서 발생하는 등 정말 다양하다. 

셋째, 시스템적인 오류는 메모리 할당을 잘못하였다던지, 해제를 잊고 하지 않음으로써, 시스템이소위 뻗어버리는 경우에 해당한다. 

프로그램의 오류는, 개발자가 재현(reproduce)을 할 수 있으면, 즉 오류를 만들 수 있으면, 대부분해결이 가능하다. 그러나 오류를 만들 수 없는 경우, 즉 평상시에는 잘 돌다가도 갑작스레 오류로 인해 시스템이 뻗어버린다던지, 간략한 dump만을 보여준다던지 하는 경우에는 오류를 잡기가 거의 불가능하다. 설령 의심나는 모듈을 수정한다고 하더래도, 개발자가 오류를 제대로 만들 수 없는 환경이라면, 제대로 수정이 되었는지 아무도 확신할 수 없고 그저 ‘인샬라’-신의 뜻대로- 를 외치는 수 밖에 딱히 할 수 있는 게 없다. 

프로그램의 오류를 막기 위해 또는 오류가 났을 때 왜 오류가 났는지를 파악하기 위해 exception처리를 하게 된다. 대부분의 경우 오류가 났을 때의 상태를 로깅하고 사용자에게 오류가 났음을 알려주는 것을 코딩하게 된다. 문제는 대부분 바쁜 개발일정을 이유로 해서 exception 처리를 소홀히 함으로 인해 막상 오류나 장애가 발생했을 때 그다지 도움되는 정보를 남기지 못한다는 것이다. 

ExCatJ는 Exception이 발생했을 때의 환경을 자동으로 로깅하고 싶다는 아주 작은 아이디어에서 시작한다. Exception이 일어났을 때의 위치와 변수값을 자동으로 로깅하는 기능을 갖는다. Java의 Java Platform Debug Architecture(JPDA) 기술에 기반하였으며 개발 소스 또한 샘플예제를 일부 변형하여 만들기 시작한다 
