[Visual Studio/디버거] 특정 라인까지 실행 후 중지하는 방법, 그리고 단축키

디버그의 필수요소. 이 라인까지 실행 후 BREAK

  디버그를 하다 보면 break포인트만으로는 감당할 수 없는 상황이 자주 생깁니다. 예를 들어 다음과 같은 코드가 있다고 생각해보세요.
if (elemMore != null)
{
    Log.InfoFormat("어떠어떠한 로그를 출력!");

    CurrentPage.Click(elemMore);

    CurrentPage.WaitForNetworkIdle0(30000);

    if (_isPageTabNewWindowCreated == false)
        GoBackCount++;
}
  이제 디버그를 돌립니다. 첫줄의 if문에 breakpoint를 걸고, 다음과 같은 프로세스를 따르고자 합니다.
  1. elemMore이 null인지 체크 null이 아니어야 함.
  2. elemMore가 제대로 스크롤된 후 클릭되는지 확인.
  3. _isPageTabNewWindowCreated가 true로 변경되었는지 확인.
  자, 여기서 가장 효율적인 디버깅 방법은 뭘까요? 언뜻 생각해서는, 추가로 Click 메서드에 breakpoint를 걸고, WaitForNetworkIdle0에도 걸고, 그 밑의 if문에도 걸고… 그리고 실행한 뒤 F5를 눌러가며 breakpoint를 따라 디버깅하는 방법이 최선이라 생각할 수도 있습니다.
  그러나 Visual Studio에서는 그러한 노가다를 방지하기 위한 효과적인 방법을 제시해줍니다. 바로 ‘현재 커서까지 실행’이라는 기능이죠. 이 기능을 사용하면, 현재 커서(마우스 커서가 아닙니다. Character 커서입니다.)까지 실행한 뒤 알아서 중지됩니다.
  그럼, 어떻게 써야할까요?

커서까지 실행


  위의 초록색 재생 버튼이 보이시나요? 디버그 중 breakpoint에 걸린 상태에서, 즉 일시 중지된 상태에서 특정 라인에 마우스를 올려두면 저렇게 초록색 여기까지 실행 버튼이 나타나게 됩니다. 그리고 해당 버튼을 누르면 그 라인까지 실행되고, 직접 건 breakpoint가 없어도 알아서 그 라인에서 중지됩니다. 정말 유용한 기능이 아니라고 할 수 없죠.
  그럼 문제. 이 기능을 사용하면 도대체 뭐가 좋은걸까요? 당연히, 노가다의 필요성이 줄어듭니다. 불필요한 반복 작업의 횟수가 줄어들고요.
  무슨 말인지 잘 이해가 안 되실 수도 있겠다 싶네요. 다시 위의 디버깅 프로세스를 봐주세요. 만약 이 기능이 없다면, 두 가지의 방법으로 같은 디버깅을 진행할 수 있습니다.
  우선, 첫 번째 방법으로, elemMore == null을 확인하는 조건문에 breakpoint가 걸린 상태에서, 한 줄씩 한 줄씩 넘기며(F11) 디버깅하는 방법입니다.
  문제는, 이렇게 할 경우 Log.InfoFormat등의, 현재 작업에 필요없는 메서드의 본문까지 들어가버린다는 겁니다. 물론, 이럴 땐 프로시저 단위 실행(F10)을 눌러 Log.InfoFormat등의 부분에서만 건너뛸 수 있지만, F11을 눌렀다가, F10을 눌렀다가, 귀찮은 것은 매한가지입니다.
  그리고 두 번째 방법으로, 위에도 적었던, breakpoint를 매 줄마다 걸어서 디버깅하는 방법입니다. 물론 말할 것도 없이 비효율적입니다. 텍스트 에디터가 씨뻘겋게 되는 것은 덤이고요.
  그러나, 커서까지 실행 기능이 있는 한 이 모든 문제는 다 의미가 없죠. elemMore == null 체크 부분에 breakpoint를 건 후, null이 아닌 것이 확인됐으면 7번째 줄, 즉 WaitForNetworkIdle0에 커서를 옮긴 뒤 ‘커서까지 실행’ 기능을 실행시킵니다.(Ctrl + F10)
  그러면 Click 메서드가 실행된 뒤 WaitForNetworkIdle0에서 실행이 일시 정지됩니다. 그리고 Click메서드가 잘 실행됐는지 확인한 뒤, GoBackCount++ 부분으로 커서를 옮긴 뒤 ‘커서까지 실행’ 기능을 실행시켜 해당 부분에 적중되는지 확인하면 _isPageNewTabWindowCreated가 true인지 false인지 확인할 수 있겠죠.
  쓰잘데기없는 노가다를 획기적으로 줄여주는 멋진 기능입니다.

다시 한 번 강조하는 단축키!

  이 포스트를 쓰는 이유는, 사실 여기까지 실행 기능은 디버그 좀 해보신 분들은 다 아시리라 생각합니다. 허나 단축키는 아닐거라고 생각했기 때문입니다.
  그도 그럴 것이, 위 이미지에서 보시다시피 분명 툴팁은 여기까지 실행이지만, 기능 명칭은 커서까지 실행인지라, 키보드 단축키에서 여기까지 실행 키워드로 백날 찾아봐야 나오지 않기 때문입니다.
  여기까지 실행 == 커서까지 실행 == true의 기본 단축키는 Ctrl + F10입니다. 물론, 키보드 환경설정에서 단축키를 변경할 수도 있습니다. 주의하실 점은, 단축키로 실행할 때엔 마우스 커서 위치가 아닌, 캐릭터 커서 위치까지 실행된다는 점입니다. 코드의 여기까지 실행됐으면 좋겠다! 싶은 부분을 마우스로 클릭하거나 키보드로 이동 해서 커서를 옮긴 뒤 해당 기능을 실행해주셔야 합니다.
&nbps; 그럴 거면, 마우스로 저 초록색 버튼을 클릭해도 되지 않느냐, 하시는 분이 계실지도 모르겠지만 해당 버튼은 코드의 맨 왼쪽, 그러나 줄번호는 아닌 어떤 공간에 마우스를 일정 시간 올려놔야 나오기 때문에 실행하기까지 약간의 딜레이가 있습니다. 하지만, 우리 개발자들은 마우스보다 키보드가 빠른 법. 이 단축키를 활용하신다면 그 짧은 시간을 더더욱 단축할 수 있을 겁니다.
​

댓글

댓글 쓰기

이 블로그의 인기 게시물

C# 남아도는 메모리에도 불구하고 OutOfMemoryException이 발생한다면?

이미지
  C# 코딩 중 평소 볼 수 없던 생소한 현상이 발생했습니다. 분명 메모리는 남아도는데(32기가바이트 중 26기가바이트 사용 가능) 프로그램이 돌다가 OutOfMemory 예외를 던지며 죽어버리는 현상이었죠. List 에 수많은 파싱된 데이터를 넣는 작업 중이었습니다.   그래서 메모리 프로파일러를 잘 관찰해보니 2GB의 메모리를 사용하면 무조건 뻗어버리는 현상을 발견했고, 왜 그럴까 생각해보다가 문득 예전 XP에서 4기가 메모리를 달아도 32비트 운영체제의 한계 아닌 한계로 3기가 조금 넘게밖에 인식을 못 했던 것이 생각났습니다. 생각은 자연스럽게 컴파일이 32비트로 됐구나! 쪽으로 넘어갔고 프로젝트 설정에 보니 빌드 항목에 해당되는 체크박스가 있더군요.   현재 메모리가 남아도는데도 OutOfMemory 예외가 뜬다면 100% 저게 체크된 상태일 겁니다. 그림과 같이 체크 해제 하신 후 실행하시면 특별한 경우가 아닌 이상 컴퓨터 메모리가 바닥날 때까지 저 예외를 볼 일 없게 될겁니다.
자세한 내용 보기

USB를 뒤는 괜찮은데 앞에 꽂으면 인식이 힘들다?

이미지
USB 장치 인식 실패   보기만 해도 짜증나는 제목이죠. USB 장치 인식 실패. 원인은 여러가지가 있을 수 있습니다. USB 컨트롤러가 고장이거나, USB 케이블이 단선됐거나, 전원 공급이 원활하지 않거나. 하지만 뒷쪽에 꽂으면 괜찮은데 앞에 꽂으면 USB 장치 인식을 실패한다면? 십중팔구 전원 문제입니다. 불안정한 전원 공급   본체 앞쪽에 달려 있는 USB 포트는 메인보드에 다이렉트로 붙어 있는 뒷쪽과 달리 메인보드에서 케이블 하나를 거쳐 전면 패널에 연결 됩니다. 게다가, 이 케이블과 연결되는 메인보드의 부분은 주로 메인보드에 전원이 연결되는 부분과 정 반대쪽에 있기 때문에 , 저가형 불량 메인보드에선 아예 회로 자체가 잘못돼 전원이 제대로 전달되지 않는 경우도 있습니다.   이렇게 메인보드 자체의 문제일 경우엔 어쩔 수 없지만, 그게 아니라면 몇 가지 시도해 볼 수 있는 방법이 있습니다. USB 포트 청소   전원 공급이 불안정한 이유 중 하나가 될 수 있는 포트 내부의 먼지. 접촉 단자 사이에 먼지가 끼어 전류를 방해하거나 합선시키기도 합니다. 우선 USB 포트를 청소해주세요. 오래된 USB 케이블 교체   USB 케이블이 오래된 경우, 접촉면이 휘거나 벌어져 제대로 꽉 맞물리지 않거나, 싸구려라면 심할 경우 접히고 접히다 단선된 상태일 수도 있습니다. 오래된 USB 케이블은 교체해주세요. 메인보드의 USB 선 연결 상태 확인   메인보드를 보면, 파워가 연결되는 부분과 정 반대쪽(주로 맨 아래쪽)에 위와 같이 생긴 USB 커넥터가 연결돼 있을 겁니다. 못 찾겠으면, 본체 전면 패널쪽에서 이어져 오는 선중에 위와 같이 생긴걸 찾아보세요. 저걸 빼서 대충 후후 불고 다시 꽂아주시기 바랍니다. 항상 꽂혀 있는 것이라 정성스레 청소할 필욘 없어요. 단, 저 케이블 어딘가가 접혀있다면 꼭 펴주세요. USB 절전 모드 사용 안 함   위 영상을 보시고 똑같이 따라해주세요. 일부 파워 용량
자세한 내용 보기

MySQL 데이터 타입과 Java 데이터 타입 비교/매칭

  안녕하세요? 혼살입니다. 블로그에 정말 오랜만에 글을 씁니다. 일하고 겜하고 일하고 겜하고 집에 박혀서 매일 똑같은 일상을 보내다 보니 블로그에 글을 오랫동안 안 쓰고 있었네요. 대부분 근황은 유튜브 동영상으로 대체하다 보니 더욱 더 그랬던 것 같습니다.   하지만 이번엔 영상보다 글로 남기는 게 더 유익할 것 같아 간만에 글을 쓰게 되었습니다. 바로 MySQL Data Types & Java Data Types 매칭! 현재 진행중인 외주 작업 중 SET 타입을 Java에선 어떻게 처리하나 찾아보다가 잘 정리된 블로그 글 을 발견해 나중에 손쉽게 찾기 위해 제 블로그에도 씁니다. 위 링크에 들어가시면 테이블로 잘 정리돼 있으니 한 번 들어가 보시는것도 괜찮겠네요. 왼쪽은 MySQL, 오른쪽은 Java의 데이터 타입입니다. BIT <-> Boolean TINYINT <-> Integer BOOL/BOOLEAN (TINYINT(1)) <-> Integer SMALLINT <-> Unsigned 상관없이 Integer MEDIUMINT <-> Integer, Unsinged라면 Long INT <-> Integer, Unsigned라면 Long BIGINT <-> Long, Unsigned라면 java.math.BigInteger FLOAT <-> Float DOUBLE <-> Double DECIMAL <-> java.math.BigDecimal DATE <-> java.sql.Date DATETIME <-> java.sql.Timestamp TIMESTAMP <-> java.sql.Timestamp TIME <-> java.sql.Timestamp YEAR <-> yearsIsDateType이 설정됐다면 java.sql.Date, 아니라면 Short CHA
자세한 내용 보기