Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일

First-chance exception에 대해 조건에 따라 디버거가 멈추게 할 수는 없을까?

제목이 좀 난해한데요. ^^ 쉽게 이해하기 위해 예를 한번 들어볼까요?

가령 다음과 같은 코드를 작성한 후,

class Program
{
    static void Main(string[] args)
    {
        string host = "www.microsoft11111.com";
        Console.WriteLine(host + ": " + ConnectTest(host));
    }

    static bool ConnectTest(string host)
    {
        try
        {
            Socket socket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
            socket.Connect(host, 80);

            socket.Close();
            return true;
        }
        catch { }

        return false;
    }
}

Visual Studio에서 "F5" 키를 눌러 디버깅을 시작하면 정상적으로 프로그램이 종료되는 것을 확인할 수 있습니다. 물론, "Output" 창에는 다음과 같은 예외 기록이 남습니다.

A first chance exception of type 'System.Net.Sockets.SocketException' occurred in System.dll

프로젝트가 커지면서 예외에 대한 try/catch를 남발하다 보면, 위와 같이 "first chance exception"이 발생하는 경우에 저 오류가 과연 아무런 영향이 없는 예외인지, 아니면 '의도치 않게 삼켜진 예외'인지 구분하기가 매우 어렵게 됩니다.

다행히, Visual Studio에서는 개발자가 try/catch로 처리했을지라도 예외가 발생한 경우 디버거로 하여금 Break가 되도록 하는 방법이 제공됩니다. 이에 대해서는 저번에 한번 설명을 드렸지요. ^^

First-Chance Exception
; https://www.sysnet.pe.kr/2/0/510

위의 마지막 부분에 설명한 데로, "Debug" / "Exceptions..." 메뉴로 "System.Net.Sockets.SocketException" 예외에 대해서 "Thrown" 상태를 설정해 두면 이후부터는 디버깅 시에 이런 예외가 발생하면 Visual Studio는 여지없이 디버거를 정지시키고 해당 예외가 발생한 라인에 멈추게 됩니다. 멋지죠? ^^




개인적으로, 저는 명시적으로 "Thrown" 설정을 해서 First-chance exception에 대한 예외를 어떻게든 없애는 방향으로 프로젝트를 진행합니다. 왜냐하면, 그렇지 않으면 나중에 프로젝트가 커져서 어떤 기능이 안될 때 도대체 왜 그 기능이 '아무런 오류도 없이 안되는지' 그 오류를 찾기 힘들기 때문입니다.

그런데, 그렇게 하다 보면 문제가 생기는 경우가 있습니다.

예를 들면, 위의 소켓 예제 코드에서 특정 서버에 대한 연결 가능 여부를 5초마다 체크하도록 했다고 가정해 보겠습니다.

ThreadPool.QueueUserWorkItem( (WaitCallback)(
    (obj) =>
        {
            while (true)
            {
                bool result = ConnectTest("www.rjrejfs.com");
                if (result == false)
                {
                    Console.WriteLine("Disconnected");
                }

                Thread.Sleep(5000);
            }
        }
    ));

만약, 위의 코드를 Visual Studio의 디버깅 상태에서 System.Net.Sockets.SocketException 예외에 대해 "Thrown" 상태로 두고 돌리면 5초마다 Visual Studio가 해당 소스 코드 라인에서 멈추는 부작용(!)이 생깁니다.

이 불편함을 없애려면 "System.Net.Sockets.SocketException" 예외의 "Thrown" 상태를 꺼야 하는데, 그렇게 되면 꼭 필요하게 체크해야 할 동일 예외에 대한 진단을 할 수 없게 됩니다.

바로 이럴 때, 특정 상황에서 발생하는 예외에 대해서는 "Thrown" 상태를 켜 두었어도 Visual Studio에서 멈추지 않게 하고 싶어지는데요. 혹시... 이에 대한 해답이 떠 오르는 분이 계실런지요? ^^

저는 한가지 생각났습니다. 바로, DebuggerNonUserCode / DebuggerStepThrough / DebuggerHidden 특성을 적절하게 사용하는 것입니다. 이를 반영해서 최종적으로 코드를 만들어 보면, 대충 다음과 같이 됩니다.

class Program
{
    static void Main(string[] args)
    {
        string host = "www.microsoft.com";
        Console.WriteLine(host + ": " + ConnectTest(host, true));

        ThreadPool.QueueUserWorkItem( (WaitCallback)(
            (obj) =>
                {
                    while (true)
                    {
                        bool result = ConnectTest("www.rjrejfs.com", false);
                        if (result == false)
                        {
                            Console.WriteLine("Disconnected");
                        }

                        Thread.Sleep(5000);
                    }
                }
            ));

        Console.ReadLine();
    }

    static bool ConnectTest(string host, bool thrown)
    {
        try
        {
            Socket socket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);

            if (thrown == true)
            {
                socket.Connect(host, 80);
            }
            else
            {
                if (ConnectNotThrown(socket, host, 80) == false)
                {
                    return false;
                }
            }

            socket.Close();
            return true;
        }
        catch { }

        return false;
    }

    [DebuggerHidden]
    static bool ConnectNotThrown(Socket socket, string host, int port)
    {
        try
        {
            socket.Connect(host, port);
            return true;
        }
        catch { }

        return false;
    }
}

위의 코드를 보면, 혹시나 연결이 안되었을 때 예외가 발생하기를 기대하는 코드에서는 ConnectTest(..., true)를 호출하고, 그렇지 않고 일상적으로 발생할 수 있거나 자주 발생해서 디버깅에 장애가 될 경우라면 ConnectTest(..., false)를 호출하는 것으로 해결하고 있습니다.

나름 유용하게 써 먹고 있는 팁입니다. ^^ (첨부된 파일은 위의 소스 코드가 포함된 간단한 프로젝트입니다.)

참고로, 위의 용도로는 DebuggerNonUserCode / DebuggerStepThrough / DebuggerHidden 특성 중에서 어느 것을 사용해도 무방하지만 다른 경우에서는 각각의 분리된 용도를 가지고 있는데요. 이에 대해서는 다음의 글을 참고하시면 되겠습니다. ^^

Change Debugger behavior with Attributes
; http://blogs.msdn.com/b/stevejs/archive/2005/12/03/499803.aspx






[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]







[최초 등록일: ]
[최종 수정일: 5/21/2021]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 



2012-06-05 03시56분
참고로, "Enable Just My Code (Managed only)" 옵션이 꺼져 있다면 위와 같은 상황에서도 Visual Studio에서 예외 발생에 대한 BP가 잡힙니다.
정성태

... 166  167  168  169  170  171  172  173  174  175  176  177  [178]  179  180  ...
NoWriterDateCnt.TitleFile(s)
532정성태9/2/200730430개발 환경 구성: 27. AD CA에서 Code Signing 인증서 유형 추가 방법
531정성태9/2/200726064.NET Framework: 95. WCF에서의 DataTable 사용
530정성태9/1/200722616.NET Framework: 94. WCF 예외에 대한 시행착오
529정성태8/31/200725451.NET Framework: 93. WCF - DataContract와 KnownType 특성 [1]
528정성태8/30/200720102오류 유형: 47. VPC - 네트워크 어댑터 MAC 주소 중복 오류
527정성태8/30/200730160Team Foundation Server: 20. 잠긴 파일을 강제로 해제 [2]
526정성태8/29/200720041오류 유형: 46. VS.NET 2008 - ASP.NET 디버깅 : Strong name validation failed.
525정성태8/27/200722331VS.NET IDE: 54. VS.NET 2008 - 새롭게 도입되는 XSD Schema Designer
524정성태8/23/200739866오류 유형: 45. 요청한 작업은, 사용자가 매핑한 구역이 열려 있는...
523정성태8/16/200722513VS.NET IDE: 53. VS.NET 2008 - 서비스 참조 시 기존 데이터 컨테이너 DLL 사용
522정성태8/13/200726135VS.NET IDE: 52. VS.NET 2008 - WCF를 위한 디버깅 환경 개선
521정성태8/8/200726271.NET Framework: 92. XmlSerializer 생성자의 실행 속도를 올리는 방법 - 두 번째 이야기 [3]
520정성태8/7/200721388VS.NET IDE: 51. Visual Studio 2008 베타 2 설치
519정성태7/27/200727766오류 유형: 44. System.BadImageFormatException [2]
518정성태7/26/200728725오류 유형: 43. System.ComponentModel.LicenseException [1]
517정성태7/19/200716993개발 환경 구성: 26. VPC - 일반 사용자 계정으로 구동
516정성태7/19/200720287오류 유형: 42. TFS - Error loading menu: Index was outside the bounds of the array [2]
515정성태7/18/200727943오류 유형: 41. SSL 서버 자격 증명을 만드는 동안 심각한 오류가 발생했습니다.
514정성태7/14/200720613Team Foundation Server: 19. Orcas에서 개선되는 TFS 기능들
513정성태7/4/200731595.NET Framework: 91. Foreground Thread / Background Thread [1]
512정성태6/27/200721641오류 유형: 40. error PRJ0050: Failed to register output.
511정성태6/25/200729593.NET Framework: 90. XmlSerializer 생성자의 실행 속도를 올리는 방법 [2]
510정성태6/25/200744477디버깅 기술: 15. First-Chance Exception
508정성태6/21/200727452Team Foundation Server: 18. Team Build에 사용되는 각종 Property 값 [4]
507정성태6/11/200725066VS.NET IDE: 50. Orcas - UAC 설정 관련
506정성태6/9/200720226오류 유형: 39. VC Package not available or not registered
... 166  167  168  169  170  171  172  173  174  175  176  177  [178]  179  180  ...