처리되지 않은 예외가 작동하지 않는 Visual Studio 2015 중단


114

Visual Studio에는 "Break on Un-handled exception"에 대한 특정 확인란이있었습니다. 2015 년에는 제거되었습니다 (또는 찾을 수없는 곳으로 옮겨졌습니다). 따라서 이제 사용자 수준 예외 처리기를 제공하지 않아도 변환 된 프로젝트가 더 이상 중단되지 않습니다. 특정 예외를 처리하기 때문에 모든 "발생 예외"를 중단하고 싶지 않습니다. 특정 핸들러를 제공하지 못하는 경우.

지금 내 코드는 단순히 현재 프로 시저를 종료하고 GOOD가 아닌 다음 호출 스택 위치에서 실행을 계속합니다.

누구나 Visual Studio 2015에서 이것을 다시 얻는 방법을 알고 있습니까? 어제 커뮤니티 에디션으로 업그레이드했습니다.


Visual Studio 2015는 Tool또는 Window탭에 원하는 모든 위치가 없는 경우 이전 버전의 현재 레이아웃을 유지합니다 . 귀하의 경우 예외 설정을 찾고 있습니다.
그렉

4
@greg, 패널을 어디에서 찾을 수 있는지 모르는 것이 아닙니다. 내 관심사는 내가 찾고있는 행동이 그 패널에 없다는 것입니다.
Ted Lowery

여기에도 같은 문제가 있습니다. 우리의 경우 autofac에 모든 유형이 등록되지 않은 경우 예외 중단이 발생합니다. vs2013과 동일한 솔루션을 사용하면 작동하지만 vs2015에서는 아무것도 얻지 못합니다. 그것은 단지 vs2015에서 vs2013 및 RAN에서 생성 된 프로젝트의 경우 경우이 또한 타사의 등록 및 (nservicebus 등의) 예외 .I 경이에 문제가
초코 스미스

3
그 새 도구 창은 정말 짜증납니다.
cedd

에 따르면 예외의 MS 분류 당신은 할 경우 처리되지 않은 항상 디버거를 나누기 예외. "Options-> Debugging-> General"목록에서 "Break when excptions cross AppDomain ..."옵션을 선택해야 할 수도 있습니다.
tsul

답변:


118

디버깅을 시작할 때 기본적으로 오른쪽 아래 창에 나타나는 "예외 설정"이라는 새 창이 있습니다. 예상 할 수있는 모든 옵션이 있습니다.

CTRL+ ALT+로 가져올 수 있습니다.E

이를 통해 디버거에서 중단을 유발하는 예외를 선택할 수 있습니다.

그러나 핵심은 이러한 예외가 항상 중단되는지 또는 처리되지 않은 예외 일 때만 중단되는지 여부를 설정할 수도 있다는 것입니다. 그러나이를 설정하는 것은 그리 직관적이지 않습니다.

먼저 도구> 옵션> 디버깅에서 "내 코드 만 사용"을 선택해야합니다.

그러면 새 예외 설정 창에서 열 머리글 (Break When Thown)을 마우스 오른쪽 단추로 클릭하고 "추가 작업"열을 추가 할 수 있습니다. 그러면 각 예외를 "사용자 코드에서 처리되지 않은 경우 계속"으로 설정할 수 있습니다.

따라서 예외 또는 전체 그룹을 마우스 오른쪽 단추로 클릭하고 "사용자 코드에서 처리되지 않은 경우 계속"플래그를 비활성화하십시오. 안타깝게도 "추가 작업"열은 "사용자 코드에서 처리되지 않은 경우 중단"과 같은 빈 상태로 표시됩니다.

여기에 이미지 설명 입력

여기에 대한 자세한 내용 :

http://blogs.msdn.com/b/visualstudioalm/archive/2015/02/23/the-new-exception-settings-window-in-visual-studio-2015.aspx


7
실제로 그 창에는 "던진 된 휴식"옵션 만 있습니다. 그것은 내가 원하는 것이 아닙니다. 나는 "처리되지 않을 때 중단"을 원합니다.
Ted Lowery

17
그게 문제입니다. 깨지지 않습니다. 위에서 말했듯이 현재 프로 시저 호출을 종료 (단계 밖으로)하고 호출 프로 시저에서 다음 코드 줄을 실행하기 시작합니다.
Ted Lowery

2
"Just My Code"가 활성화되어 있습니다.
Ted Lowery

19
@TomStudee 나도 같은 문제가 있습니다. 내가 원하는 것은 "Break when unhandled"이지만 내가 얻는 것은 "Break when thrown"입니다. 문제는 "Break when unhandled"를 얻는 방법입니다.
ogggre

1
@TomStudee 방금 처리되지 않은 경우에만 중단되도록 예외를 설정할 수있는 키 설정이 누락 되었기 때문에 필요한 설명을 추가했습니다.
Jerad 로즈

36

나는 같은 문제가 있었고 이것을 통해 이것을 해결할 수있었습니다.

  1. Ctrl+ Alt+ e를 눌러 예외 설정 창 을 불러옵니다 .
  2. 공용 언어 런타임 예외 . 여기에 이미지 설명 입력

그게 다야!

Windows x64 버전을 사용하고 있기 때문에이 게시물 에서 영감을 받았습니다 .


7
그러면 사용자 코드에서 처리하는 예외를 포함하여 모든 예외에서 중단됩니다.
carlin.scott

1
@ carlin.scott, 목록에서 처리되는 예외를 수동으로 선택 취소 할 수 있다고 생각합니다.
Justin XL

6
@JustinXL 문제는 이것이 처리 여부가 아니라 예외 유형별 목록이라는 것입니다. 예를 들어, System.ArgumentException처리되는 경우와 처리되지 않는 경우가 있습니다. 나는 그것이 처리 되지 않을 때만 깨지는 것에 관심이 있습니다.
Jerad Rose

1
@JeradRose 예외가 처리되지 않으면 디버거가 항상 중단됩니다. 내가 말했듯이, 처리 된 예외를 중단하지 않으려면 Break When Thrown 목록 에서 해당 예외 유형을 선택 취소 하면 됩니다.
Justin XL

심지어는 예외에 침입하지 모든 일들을 검사 할 때 : 그냥 종료 /
더글러스 Gaskell

10

예외가 코드와 관련된 경우에만 중단하려는 Google 직원을 위해 Visual Studio 2015에는 옵션-> 디버깅-> 일반-> 내 코드 만있는 옵션이 있습니다. 확인되면 예외가 코드 외부에서 관리 (발생 및 포착) 될 때 중단되지 않도록합니다.


이것은 VS2015가 어떤 이유로 코드 입력을 거부하는 또 다른 상황에서 저를 구했습니다. 코드는 "내 코드"이지만 "내 코드 만"플래그가 트리거되었습니다. 2 개의 VS 인스턴스와 독립형 웹 서버를 실행할 때 어딘가에 버그가 있다고 생각합니다.
LosManos

9

Microsoft는 새 예외 창에서 논리를 미묘하게 변경했습니다.

http://blogs.msdn.com/b/visualstudioalm/archive/2015/02/23/the-new-exception-settings-window-in-visual-studio-2015.aspx 참조

핵심 부분은 다음과 같습니다.

중요 사항

  • 이 새 창에는 이전 모달 대화 상자와 동일한 기능이 모두 포함되어 있습니다. 디버거의 기능은 액세스 할 수있는 방식 만 변경하지 않았습니다.
  • 디버거는 예외가 처리되지 않으면 항상 중단됩니다.
  • 사용자가 처리하지 않은 예외에서 디버거가 중단되는 경우 변경할 설정이 컨텍스트 메뉴 아래로 이동했습니다.
  • 메뉴 위치가 디버그-> Windows-> 예외 설정으로 이동했습니다.

그러나 나처럼 코드에 Global Unhandled Exception Handler 가있는 경우 해당 목록의 두 번째 항목이 핵심입니다. 따라서 저에게는 예외가 실제로 처리되지 않을 것이므로 VS2013과 다른 것 같습니다.

처리되지 않은 예외에서 VS가 중단되는 동작을 되돌리려면 중단하려는 모든 예외 유형을 선택한 다음 두 번째로 "계속하기"에 대한 "추가 옵션"(이 열을 표시해야 할 수도 있음 *)을 확인해야했습니다. 사용자 코드에서 처리되지 않은 경우 "했다 NOT 설정합니다. VS2015 논리 전역 처리되지 않은 예외 처리기 를 "사용자 코드에서 처리" 하는 것으로 간주 하지 않는 것 같으 므로 이러한 문제가 발생합니다. 그래도 잡힌 예외에서 중단되지 않습니다. 이것은 VS2013이 한 것처럼 작동합니다.

* "추가 작업"열 활성화 방법 * "추가 작업"열 활성화 방법


2
이것은 VS2013과 똑같이 작동하지 않습니다. 과거에는 그렇지 않았던 제안한 설정으로 사용자 처리 예외가 중단되기 때문입니다.
carlin.scott

"추가 옵션"열을 어떻게 표시합니까?
UuDdLrLrSs

@DaveInCaz 열 머리글> "열 표시"> "추가 작업"을 마우스 오른쪽 버튼으로 클릭
oatsoda

7

여기서 줄 사이를 올바르게 읽고 있다면 기본 디버거 동작이 처리되지 않은 예외에서 중단 되더라도 예외가 효과적으로 '사라진다'는 문제입니다.

비동기 메서드가있는 경우 작업 연속의 일부로 스레드 풀 스레드에서 포착되지 않은 예외는 처리되지 않은 예외로 간주되지 않기 때문에이 문제가 발생할 수 있습니다. 오히려 그들은 삼켜지고 Task와 함께 저장됩니다.

예를 들어 다음 코드를 살펴보십시오.

class Program
{
    static void Main(string[] args)
    {
        Test();
        Console.ReadLine();
    }

    private async static Task Test()
    {
        await Task.Delay(100);
        throw new Exception("Exception!");
    }
}

기본 디버거 설정 (처리되지 않은 예외에서만 중지)으로이 프로그램을 실행하면 디버거가 중단되지 않습니다. 이는 연속에 할당 된 스레드 풀 스레드가 예외를 삼켜 (Task 인스턴스로 전달) 풀로 다시 해제되기 때문입니다.

이 경우 실제 문제는에서 Task반환 된 항목 Test()이 확인되지 않는다는 것입니다. 코드에 유사한 유형의 '실행 후 삭제'로직이있는 경우 예외가 throw 될 때 예외가 표시되지 않습니다 (메서드 내에서 '처리되지 않은'경우에도). 예외는 대기, 결과 확인 또는 명시 적으로 예외를 확인하여 Task를 관찰 할 때만 나타납니다.

이것은 추측 일 뿐이지 만 이와 같은 것을 관찰하고있을 가능성이 높습니다.


이것은 op의 문제와 관련이 없을 수 있지만 비동기 루틴에서 발생하는 예외에 대해 매우 좋은 점을 제기합니다.
Phil Cooper

예외가 그렇게 저장 되어도 디버거를 중지시키는 방법이 있습니까?
Lucas

@Lucas, 내가 아는 것은 아니지만 일부 코드 변경 사항에 가까워 질 수 있습니다. fire-and-forget 메서드 본문에 try-catch 블록이있는 경우 명시 적 Debugger.Break()호출을 추가 할 수 있습니다 . 다른 방법으로, 당신은 명시 적으로 추가 할 수 있습니다 Debugger.Break()TaskScheduler.UnobservedTaskException여기 단점은 작업이 정리됩니다 때 종료 자 스레드에서 발생하는대로이 원래 예외보다 훨씬 나중에 해고 할 수 있다는 것입니다하지만, 핸들러입니다. 일반적으로 작업 결과를 항상 관찰하거나 적어도 실패시 기록 할 try-catch 블록이 있어야합니다.
Dan Bryant

3

내 경험상 2015의 예외 설정은 변경하면 완전히 엉망이됩니다.

부모 그룹 "CLR"이 될 때까지 처리되지 않은 예외가 발생하지 않아야합니다. 예외가 처리되지 않으면 항상 중단됩니다. 그러나 CLR 그룹이 선택 해제 된 경우 try ... catch 내부의 코드는 단순히 중단을 일으키지 않아야합니다. 그것은 사실이 아닙니다.

솔루션 : 새 예외 설정 도구 상자에서 마우스 오른쪽 단추를 클릭하고 "기본값 복원"을 선택하십시오. 타다 아아아 ... 다시 정상적으로 작동합니다. 이제 그것을 망치지 마십시오.


1

지침을 따르십시오.

  1. 예외 설정 창에서 창을 마우스 오른쪽 버튼으로 클릭 한 다음 열 표시를 선택하여 상황에 맞는 메뉴를 엽니 다. (내 코드 만 해제 한 경우이 명령이 표시되지 않습니다.)
  2. 추가 작업이라는 두 번째 열이 표시되어야합니다. 이 열은 특정 예외에서 사용자 코드로 처리되지 않은 경우 계속을 표시합니다. 즉, 해당 예외가 사용자 코드에서 처리되지 않고 외부 코드에서 처리되는 경우 디버거가 중단되지 않습니다.
  3. 특정 예외 (예외를 선택하고 마우스 오른쪽 단추를 클릭 한 다음 사용자 코드에서 처리되지 않은 경우 계속 선택 / 선택 취소) 또는 전체 예외 범주 (예 : 모든 공용 언어 런타임 예외)에 대해이 설정을 변경할 수 있습니다.

https://msdn.microsoft.com/en-us/library/x85tt0dd.aspx


절대적으로 동의합니다. 기본적으로이 열을 표시하지 않는 것은 끔찍합니다. 그것을 찾기 위해 많은 시간을 보냈습니다. 게다가 " 사용자 처리되지 않은 예외 "가 의미하는 바는 다소 불분명합니다. 작업 취소 (예 :)의 처리기가 있었고 작업의 try { task.Wait(); } catch { ... }OperationCanceledException은 어떻게 든 사용자 코드에서 처리되지 않은 것으로 간주되었습니다.
tsul

1

그것은 모두 약간 혼란스럽고 제 생각에는 이전 예외 대화 상자만큼 좋지는 않지만 어쨌든.

예외가 목록에 있고 체크되면 예외가 발생할 때마다 디버거가 중단됩니다.

예외가 선택 해제되거나 목록에없는 경우 해당 예외 유형이 사용자가 처리되지 않은 경우에만 디버거가 중단됩니다.

예를 들어 아래 스크린 샷에서 디버거는 a System.AccessViolationException가 발생할 때마다 중단 되지만 다른 모든 예외의 경우 예외가 사용자가 처리되지 않은 경우에만 중단됩니다.

Visual Studio 2015 예외 도구 창


1

VS2015로 업그레이드 할 때 예외가 응용 프로그램을 "중단"하는 데 사용되었지만 이제는 무시되고 바로 전달되는 문제도있었습니다. 우리는 우리의 코드를 할 시간이있다 의도적으로 우리가 정지에 코드를 원하는 위치 장소에서 예외를 발생보다는 계속이. 우리는 항상 Throw New Exception("Message")코드를 의도적으로 깨뜨리는 문구 를 사용합니다 .

    If SomethingReallyBad = True Then
        Throw New Exception("Something Really Bad happened and we cannot continue.")
    End If

VS2015에서는 고전적인 "System.Exception"이 우리가 Throw New Exception. 따라서 새로운 예외 설정에서 "System.Exception"체크를 확인해야합니다.

System.Exception 상자 확인

확인되면 코드가 예상대로 작동했습니다.


1

이에 대한 해결책은 당신이 설정하고 있다고 생각하는 것과 의미 상 반대입니다. 사용자 코드에서 처리되지 않은 경우 계속활성화되지 않았 는지 확인해야합니다. 즉 , 예외 설정 탭 의 추가 작업 열에 표시된대로 선택되지 않았는지 확인 해야 합니다. 아래를 참조하십시오.

효과적으로 말하는 코드에서 처리되지 않은 경우 (즉, 휴식을) 계속하지 않습니다

예외 설정 창 (Ctrl + Alt + E)

이것을하기 위해:

  1. 관심 있는 예외 또는 예외 집합을 마우스 오른쪽 단추로 클릭 합니다 (예 : 일반적으로 트리의 맨 위 줄 '공용 언어 런타임 예외').
  2. 사용자 코드에서 처리되지 않은 경우 계속 옵션을 선택합니다 (아래 참조).
  3. 예외가 확인되지 않았 는지 확인하십시오 (아래 참조).
  4. 계속 디버깅

여기에 이미지 설명 입력

그것은 나를 위해 그것을 해냈습니다-다시 행복합니다.

이것은 VS 2015에있었습니다.


0

Visual Studio에는 다시 시작해야하는 문제를 일으킬 수있는 버그가 있습니다. 심지어 VS2015.

나는 단일 스레드 상황이 있었는데 NullReferenceException 그것이 발생했을 때 중단하도록 요청했지만 '외부'처리기 (아직 내 코드에 있음)에 의해 잡히는 이있었습니다.

나는 이것이 '처리 된'예외이고 당신은 '처리되지 않은'예외라는 것을 알고있다. 그러나 나는 IISRESET이 그렇지 않다면 때때로 VS의 빠른 재시작이 이것을 고칠 것이라고 확신한다.


0

Visual Studio 2017은 오류 처리와 잘 작동합니다. 반면에 Visual Studio 2015는 디버그 모드에서 비동기 작업에서 발생하는 모든 예외가 잡히기 때문에 작업으로 오류를 처리하는 데 문제가 있지만 한 단계 넘어 가면 무한정 중단됩니다. 디버깅하지 않고 실행하면 예외가 발생하지 않고 무기한 중단됩니다 !!! 저는 Visual Studio를 좋아하고 1995 년부터 사용해 왔고 2015 년은 2010 년에서 2015 년으로 직접 뛰어 들었지만 훨씬 더 나쁜 버전입니다.이 예외 처리가 성공하지 못하도록 8 시간을 보냈습니다. 집 컴퓨터에서 2017 년에 정확한 코드를 복사했는데 완벽하게 작동했습니다. Microsoft가 2015 년 컴파일러가 제대로 처리 할 수없는 프레임 워크에 작업을 밀어 넣은 것에 매우 짜증이납니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.