Positive Mental Attitude

다양한 프레임워크와 라이브러리를 사용하는 요즘의 프로그래밍을 하다가 보면 의례 빠지지 않고 나오는 이름이 Context 다.

웹 프로그래밍을 하는 경우에도 보면 심심찮게 등장하는 클래스들 중에 Context 라는 단어가 들어간 경우가 많다.

(Asp.Net의 HttpContext 나, Java의 ServletContext 같은 것들)

닷넷 프로그램을 하다가 보면, 조금 복잡하고 어려운 내용이다 싶으면 어김없이 Context 라는 단어가 등장하곤 하는데, 이 Context 를 도대체 어떻게 해석해야 좋을지 모르겠다.

일단 사전을 찾아보면, Context 는 '문맥, 정황, 전후관계' 이라고 나온다.

쩝... 별로 도움이 안되는거 같다.

이제부터 내 나름대로 Context 가 가지는 의미에 대해서 이야기를 할텐데,

미천한 나의 경험에서 나온 추측이기 때문에 그 의미가 정확히 들어맞지 않을 수도 있고, 틀릴 수도 있다.

아무쪼록 '저 녀석은 저렇게 생각하는 구나' 정도로 이해해 주면 좋겠다.

보통 XxxContext 라고 하는 클래스들을 보면, 일단 데이터의 집합이다. 어떤 정보의 모음이라는 말이다.

일반적으로 정보의 모음이라고 하면 XxxInfo 정도의 이름이 되는데, 이 Info 와 다른 점이라고 하면,

내가 느낀 바로는, Context 는 항상 '경계, 영역, Boundary' 와 연관되어 있다는 사실이다.
즉 '어떤 영역, 경계를 구분하는 데이터의 모음' 이거나 '어떤 영역, 경계를 넘어갈 때 전달해야 하는 데이터 모음' 의 의미가 강하다는 말이다.

예를 들어, System.Security.SecurityContext 라는 클래스에 대한 MSDN의 설명은, '실행시 보안과 관련된 정보의 묶음'이라고 되어 있다.

SecurityContext 는 ExecutionContext 에 포함되어 있다는 내용도 있는데,

System.Threading.ExecutionContext 클래스 또한, 논리 Thread의 실행에 관한 정보를 담고 있다고 되어 있다.

실제 사용되는 경우와 맞추어 보면, 일련의 프로그램 흐름이 Thread 경계를 넘어서 진행될 때, 이전 Thread와 새로 넘어간 Thread의 실행 흐름을 같게 맞추어 주도록 하기 위한 정보라고 해석 할 수 있게 된다.

예를 들어, 어떤 사용자의 요청을 접수 받는 Thread가 있고, 그 요청을 실제로 처리하는 ThreadPool 이 있다고 해보자. 요청을 접수 받은 Thread가 사용자에 맞도록 보안 관련 세팅을 마쳤더라도, 그냥 ThreadPool에 실행을 요청해 버리면, 처리에 대한 보안 설정은 결국 ThreadPool에 있는 Thread의 보안 설정을 따르게 된다.

이런 경우에, 요청을 접수 받은 Thread가 보안 세팅을 한 후에, ExecutionContext.Capture를 통해 이전 실행 흐름에 대한 정보를 수집하고, ThreadPool의 Thread는 실행시에 이 ExecutionContext.Run 을 사용하여 실행하도록 하면, 다른 Thread 경계를 넘어서도, 같은 실행 흐름을 유지 할 수 있게 되는 것이다.

Asp.Net 프로그래밍을 할 때 등장하는 System.Web.HttpContext 같은 경우에는,

어떤 하나의 HTTP Request-Response 에 대한 정보를 담고 있는 클래스가 된다. 즉 동시에 이루어 지는 여러 HTTP Request-Response 들 각각의 분리시켜 주는 정보의 모음 이라는 말이다.

뭐 당연한 이야기 겠지만, Context 는 여러 경계에서 공유되는 정보 이므로, 한 경계에서 수정한 내용은 경계를 넘어서도 볼 수 있다는 사실도 염두해 둘 필요가 있을 듯 하다.

닷넷에서 등장하는 XxxContext 이름의 클래스 들 몇가지를 나열해 보면,

- System.Runtime.Remoting.Contexts.Context

- System.Threading.ExecutionContext

- System.Security.SecurityContext

- System.Runtime.Remoting.Messing.CallContext

- System.Runtime.Remoting.Messing.LogicalCallContext

- System.Threading.SynchronizationContext

     |

     +- System.Windows.Forms.WindowsFormsSynchronizationContext

     |

     +- System.Windows.Threading.DispatcherSynchronizationContext

헉! 무슨 Context 가 이렇게 많은지...

이중에서 SynchronizationContext 와 그 자식 클래스들이 등장하는데, 이 SynchronizationContext 를 위에서 애써 설명한 Context 의 개념으로 해석해 보면, SynchronizationContext는 동기화 경계를 나타내는 정보의 묶음이며, 이 동기화 경계를 넘어 가려면 어떤 식으로든 이 SynchronizationContext를 사용해야 한다고 생각할 수 있다.

이 SynchronizationContext 는 종종 등장하는 클래스 이므로 나중에 기회가 되면 좀 더 살펴보려고 한다.

이제 두서없는 글의 결론을 내려보자.(다시 읽어보니 글이 영 정신이 없다.^^;)

나의 경우에는,

Context 가 들어간 클래스가 나오면 항상 <1.이 Context 가 구분 짓고자 하는 '경계, 영역' 이 뭔가> 를 따져보고, 이 Context 가 <2.'경계, 영역'을 구분하기 위한 용도인지, 아니면 '경계, 영역'을 넘어가기 위한 용도 인지> 살펴본 다음에, 만약 '경계, 영역'을 넘어가기 위한 용도라면 그 <3.'경계, 영역'을 넘어가기 위해 어떤 식으로 Context 를 사용해야 하는지> 살펴보는 방법으로 그 클래스를 이해하려고 한다.

출처 : http://blog.naver.com/jjoommnn/130034619314

예전에, .NET 응용 프로그램에서 예외 처리를 하는 방법에 관해 정리해놓았지요. ^^

.NET 예외 처리 정리 
; http://www.sysnet.pe.kr/Default.aspx?mode=2&sub=0&detail=1&wid=316

WPF - 전역 예외 처리 
; http://www.sysnet.pe.kr/Default.aspx?mode=2&sub=0&detail=1&wid=614

WPF로 오면서는 유독 First-chance Exception을 구분하는 것이 더 중요해졌습니다. 일례로 아래와 같은 경우들이 모두 "First-chance exception"을 모르면 문제를 해결하는 데 헤멜수가 있습니다.

예외 처리를 방해하는 WPF Modal 대화창
; http://www.sysnet.pe.kr/Default.aspx?mode=2&sub=0&detail=1&wid=619

WPF - XamlParseException 대응 방법
; http://www.sysnet.pe.kr/Default.aspx?mode=2&sub=0&detail=1&wid=622

다시 한번 강조하지만, "First-chance Exception"에 대해서 아직도 모르시는 분들은 부디 이번 기회에 꼭 알고 넘어가시기 바랍니다.

First-Chance Exception
; http://www.sysnet.pe.kr/Default.aspx?mode=2&sub=0&detail=1&wid=510

WPF에서, 예외 처리에 관해 어려움을 겪는 경우가 하나 더 있는데요. 아래의 코드를 보면서 설명해 보겠습니다.

public partial class Window1 : Window, INotifyPropertyChanged
{
    string name2;
    public string Name2
    {
        get { return this.name2; }
        set 
        {
            this.name2 = value;
            OnPropertyChanged("Name2");
            throw new ApplicationException("TEST");
        }
    }

    private void Window_Loaded(object sender, RoutedEventArgs e)
    {
        this.Name2 = "TEST";
    }
}

보통 위와 같은 상황에서, Visual Studio는 아래와 같이 정상적으로 디버그 지점을 잘 잡아냅니다.

[그림 1: ApplicationException 예외]


하지만, 명시적으로 사용한 this.Name2 = "TEST" 코드를 삭제하고, 대신에 Name2 속성을 데이터바인딩으로 연결하면,

<TextBox Height="30" Margin="16,40,124,0" 
         Text="{Binding Path=Name2}"
/>

이제는 더 이상 Visual Studio IDE에서 예외를 잡아내지 못합니다. 단지 "Output"창에 다음과 같은 식으로 오류 로그가 출력될 뿐입니다.

A first chance exception of type 'System.ApplicationException' occurred in WpfApplication1.exe
A first chance exception of type 'System.Reflection.TargetInvocationException' occurred in mscorlib.dll
System.Windows.Data Error: 8 : Cannot save value from target back to source. BindingExpression:Path=Name2; DataItem='Window1' (Name=''); target element is 'TextBox' (Name='textBox1'); target property is 'Text' (type 'String') TargetInvocationException:'System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.ApplicationException: TEST
   at WpfApplication1.Window1.set_Name2(String value) in D:\Settings\desktop\binding_exception\WpfApplication1\WpfApplication1\Window1.xaml.cs:line 31
   --- End of inner exception stack trace ---
   at System.RuntimeMethodHandle._InvokeMethodFast(Object target, Object[] arguments, SignatureStruct& sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner)
   at System.RuntimeMethodHandle.InvokeMethodFast(Object target, Object[] arguments, Signature sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner)
   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks)
   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at System.Reflection.RuntimePropertyInfo.SetValue(Object obj, Object value, BindingFlags invokeAttr, Binder binder, Object[] index, CultureInfo culture)
   at System.Reflection.RuntimePropertyInfo.SetValue(Object obj, Object value, Object[] index)
   at MS.Internal.Data.PropertyPathWorker.SetValue(Object item, Object value)
   at MS.Internal.Data.ClrBindingWorker.UpdateValue(Object value)
   at System.Windows.Data.BindingExpression.UpdateSource(Object value)'

개인적으로 아쉬운 부분이 바로 위와 같이 데이터 바인딩 구문에서 예외를 먹어버리는 현상입니다. 아쉽긴 해도, WPF의 Validation 정책을 아시는 분들은 이런 식의 동작이 "By design"이라고 수긍이 되는 면이 있습니다.

WPF Sample Series - Handling and Reporting WPF Data Binding Validation Errors and Exceptions
; http://karlshifflett.wordpress.com/2008/04/03/wpf-sample-series-handling-and-reporting-wpf-data-binding-validation-errors-and-exceptions/

그러하니, 유효성 검사에서 자연스럽게 처리될 예외이므로 응용 프로그램 종료로 이어지는 예외 상황을 만들지 않도록 데이터 바인딩 과정에서 try/catch로 예외를 미리 처리하게 된 것입니다. 재미있는 점이 있다면, 마이크로소프트는 DataBinding 에 오류가 발생하는 것을 알 수 있도록 그나마 세심하게 배려했다는 정도!

How can I debug WPF bindings?
; http://www.beacosta.com/blog/?p=52

위의 글에 보면, 데이터 바인딩 오류에 대해 "Trace"로 오류 로그를 남기는 방법과 PresentationTraceSources.TraceLevel 을 이용한 방법을 소개해 주고 있습니다.

그래도... 이런 거에 만족할 수는 없지요? ^^ 어떻게 해서든지 저는 공용 속성의 set 접근자에서 발생하는 오류를 잡아내야 겠습니다.

단서를 찾을 수 있는 곳은 Validation을 처리하는 코드일 것 같습니다.

WPF Sample Series - Handling and Reporting WPF Data Binding Validation Errors and Exceptions 글에 보면, ExceptionValidationErrorHandler 코드를 볼 수 있는데요.

void ExceptionValidationErrorHandler(object sender, RoutedEventArgs e)
{
    System.Windows.Controls.ValidationErrorEventArgs arg = e as System.Windows.Controls.ValidationErrorEventArgs;

    ;
}

해답은 바로 위의 arg 인자에서 제공되는 Error 속성에 있습니다. 보통 ExceptionValidationErrorHandler 가 실행되는 경우는 다음과 같은 2가지 경우입니다.

• 위에서 설명한 데로 set 접근자에서 오류가 발생한 경우, 또는 타입이 달라서 예외가 발생한 경우
• IDataErrorInfo 를 구현한 개체가 해당 속성의 값이 유효하지 않다고 하는 경우

이 2가지를 구분하려면 arg.Error.RuleInError의 타입으로 검사하면 됩니다.

• (arg.Error.RuleInError is ExceptionValidationRule) == true: 첫번째 경우
• (arg.Error.RuleInError is DataErrorValidationRule) == true: 두번째 경우

이런 것을 반영해 보면 다음과 같은 식으로 코드를 만들면 될 것 같습니다.

void ExceptionValidationErrorHandler(object sender, RoutedEventArgs e)
{
    System.Windows.Controls.ValidationErrorEventArgs arg = e as System.Windows.Controls.ValidationErrorEventArgs;

    if (arg.Error.Exception != null && arg.Error.RuleInError is ExceptionValidationRule)
    {
        if (arg.Error.Exception is System.FormatException)
        {
            // 대개의 경우 발생할 수 있는 ExceptionValidationRule
        }
        else
        {
            // 그 외의 예외는 의도적이지 않은 예외
            throw arg.Error.Exception.InnerException;
        }
    }
}

이렇게 되면, 타입이 일치하지 않아 발생하는 예외는 그대로 Validation 검사로 진행하도록 하고, 그 이외의 상황에서는 throw를 해서 개발자로 하여금 set접근자에서 예외가 발생했음을 알 수 있도록 해줍니다.

그나마 예외 상황을 잡아보긴 했지만 아직 해결되지 않은 문제가 있습니다. ExceptionValidationErrorHandler 단계에서는 스택이 이미 풀린 상태이기 때문에 정확히 오류가 발생하는 곳에 코드를 위치시킬 방법이 없습니다. 할 수 없이, 예외가 발생했다는 정도만을 정확하게 인식하고 "throw arg.Error.Exception.InnerException"에서 확인할 수 있는 예외를 디버그 예외 상자에 등록하거나, 아니면 여전히 Output창의 "First-chance Exception"을 확인해서 디버그 예외 상자에 등록해 두는 식으로 접근해야 합니다.

게다가... 또 한가지 아쉬운 것은.

Validation 처리 과정으로 넘어오지 않은 예외에 대해서는 여전히 잡을 방법이 없습니다. 예를 들어, 데이터바인딩에는 "Name2"라는 속성명인데, 실제로는 그러한 속성이 없는 경우에는 ExceptionValidationErrorHandler까지 진입하지도 않습니다. 어쩔 수 없이 "How can I debug WPF bindings?" 에서 설명한 방식으로 데이터바인딩 예외를 추적하는 방법을 따라야 합니다.

관련 예제 코드는 첨부 파일에 올려놓았습니다.

출처 : http://www.sysnet.pe.kr/Default.aspx?mode=2&sub=0&detail=1&pageno=0&wid=746&rssMode=1&wtype=0