callback(콜백)패턴 사용시 주의사항1 - 콜백함수 내 에러처리

콜백패턴은 JavaScript뿐만 아니라 다른 언어 및 플랫폼에서도 많이 쓰이는 패턴이다.

공용 모듈같은 데서 콜백패턴을 활용할 때 주의해야 할 점이 있는데

콜백함수내 에러처리에 대해 생각을 해봐야한다.

아래와 같은 코드를 보자

------------------------------------------------------------------

//모듈패턴을 이용해 구현

function common(){

    

    var _callbackListener = null;

    

    return {

        

        init : function(){

            _callbackListener = null;

        },

        

//콜백 패턴 활용

        setCallbackListener : function (func){

            _callbackListener = func;

        },

        

        execute : function(){

            

            console.log("commonModule execute");

            console.log("commonModule step 1");

            

//등록된 콜백을 실행

            if(_callbackListener!=null){

                _callbackListener("step1.5");

            }

            

            console.log("commonModule step 2");

            

//등록된 콜백을 실행

            if(_callbackListener!=null){

                _callbackListener("step2.5");

            }

            

            console.log("commonModule step ....");

        }

    };//end of return...

};//end of common...

var commonModule = common();

commonModule.init();

commonModule.setCallbackListener(function(code){

    

    var a;

    //인위적으로 에러 발생

    var b = a.length;

    

    console.log("excute callbackListener : " + code);

        

});

commonModule.execute();

-------------------------------------------------------------------

common 모듈을 정의하고

setCallbackListener 을 통해 콜백함수를 등록한 다음에

execute를 통해 common모듈의 기능을 수행하고 있다.

하지만 콜백함수에서 에러가 발생하게되면 처리가 멈춰서

공용모듈의 execute함수가 다음 기능을 더이상 수행하지 못하게 된다.

<실행결과>

일반적인 pc 브라우저라면 대부분 훌륭한 개발자도구(inspecter)가 있기 때문에 이런 에러를 잡기 어렵지 않다.

하지만

타 임베디드 환경(ex : smartTV 등) 에서 돌아가는 브라우저인 경우 

개발자 도구(inspecter)가 따로 없어서 오직 로그에만 의존해야 하는 경우가 많으며

심지어 로그조차 볼 수 없는 경우도 있다.

로그를 볼 수 있어도 저런 syntax 에러를 따로 출력하지 않는 경우도 있다.

예제에 있는 코드는 규모가 작아 비교적 에러를 잡기 어렵지 않겠지만

제약된 개발환경에서 규모가 큰 프로그램 소스를 다룰 때는

저런 부분 때문에 큰 비용 손실을 초래할 수도 있다.

<해결책?>

1. try - catch 구문으로 방어코드 작성?

콜백함수 등록을 인터페이스로 제공하는 상황에서는 어떤 콜백이 실행될지 알 수 없으므로

try - catch 구문을 통해 에러 핸들링을 한다.

콜백함수내 처리는 에러로 인해 멈추겠지만

try-catch로 빠져나오기 때문에

일단 공용모듈의 기능이 멈추지는 않는다.

그리고 에러에 대한 처리도 

직접 로그에 출력하거나, 팝업을 띄운거나

개발자 의도대로 직접 처리할 수 있는 장점이 있다.

하지만 공용 모듈의 기능 설계에 따라 이러한 동작으로 인해 다른 버그가 나올 수 있다는 점에 대해

조금 생각해봐야한다.

----------------------------------------------------------------------

function common(){

    

    var _callbackListener = null;

    

    return {

        

        init : function(){

            _callbackListener = null;

        },

        

        setCallbackListener : function (func){

            _callbackListener = func;

        },

        

        execute : function(){

            

            console.log("commonModule execute");

            console.log("commonModule step 1");

            

            if(_callbackListener!=null){

                try{

                    _callbackListener("step1.5");

                }catch(e){

                    console.log("callbackListener error : " + e);

                }

                

            }

            

            console.log("commonModule step 2");

            

            if(_callbackListener!=null){

                try{

                    _callbackListener("step2.5");

                }catch(e){

                    console.log("callbackListener error : " + e);

                }

            }

            

            console.log("commonModule step ....");

        }

    };

};

-------------------------------------------------------------------------------------------

<결과>

2. ... 고민중..  다른 깔끔한 해결책을 아시는 분들은 댓글좀..;;