C#은 첫 번째 패스 예외 필터링을 지원하지 않는 이유는 무엇입니까?

C#은 첫 번째 패스 예외 필터링을 지원하지 않는 이유는 무엇입니까?

참고: 이것은 Jeff의 질문을 복제한 것이 아닙니다.

그 질문은 "동일한 것이 동등한가요?"라고 물었습니다.없는 건 알지만, 왜 그런지 알고 싶어요!

제가 질문하는 이유는 그것이 얼마나 중요한지 이제 막 명확해 졌고, 그 결론은 저에게 매우 이상하게 느껴지기 때문입니다.

Microsoft Enterprise Library의 예외 처리 블록은 다음 패턴을 사용하도록 권장합니다.

catch (Exception x)
{
    if (ExceptionPolicy.HandleException(x, ExceptionPolicies.MyPolicy))
        throw;

    // recover from x somehow
}

정책은 XML 파일에 정의되어 있으므로, 고객에게 문제가 있는 경우 고객이 문제를 제대로 처리할 때까지 신속하게 해결할 수 있도록 정책을 수정할 수 있습니다. 즉, 문제가 누구의 잘못인지 타사와 논쟁해야 할 수 있습니다.

이는 기본적으로 실제 애플리케이션에서 예외 유형의 수와 "복구 가능성" 상태는 이러한 기능 없이는 실질적으로 관리가 불가능하다는 단순한 사실을 인정한 것입니다.

한편, MS의 CLR 팀은 이것은 선택사항이 아니며, 그들은 그들이 무슨 말을 하는지 알고 있는 것으로 드러났습니다!문제는 바로 직전에catch블록 런, 임의finally내부에 내포된 블록try블록이 실행됩니다.그래서 그것들은finally블록은 다음 중 하나를 수행할 수 있습니다.

• 프로그램 상태를 무해하게 수정합니다(휴, 행운).
• 프로그램 상태가 알 수 없는 정도로 엉망이 되기 때문에 고객의 데이터에서 중요한 것을 폐기합니다.
• 문제를 진단하는 데 필요한 중요한 증거를 위장하거나 폐기합니다. 특히 네이티브 코드에 대한 호출에 대해 설명하는 경우에는 더욱 그렇습니다.
• 예외를 하나 더 던져 일반적인 혼란과 불행을 가중시킵니다.

참고:using명령문 및 C++/CLI 소멸자는 다음을 기반으로 합니다.try/finally그래서 그들도 영향을 받습니다.

그래서 분명히.catch/throw예외 필터링 패턴이 좋지 않습니다.실제로 필요한 것은 정책을 통해 예외를 실제로 감지하지 않고 필터링하여 실행을 트리거하는 방법입니다.finally예외를 복구하는 데 안전하다는 정책을 찾지 않는 한 차단할 수 있습니다.

CLR 팀은 최근 이에 대해 다음과 같이 블로그에 올렸습니다.

• 캐치, 리스로 및 필터 - 왜 신경을 써야 합니까?
• 캐치(예외)/비어있는 캐치가 나쁜 이유

그 결과 C#에서 이 중요한 기능에 액세스할 수 있도록 VB.NET에 도우미 기능을 작성해야 합니다.문제가 있다는 큰 단서는 BCL에 이를 수행하는 코드가 있다는 것입니다.많은 사람들이 그것을 하는 것에 대해 블로그를 했지만, 그들은 거의 언급하지 않았습니다.try/finally블록, 즉 살인자입니다.

제가 알고 싶은 것은 다음과 같습니다.

• 사람들이 이 주제에 대해 C# 팀으로부터 받은 공개 성명이나 직접 이메일이 있습니까?
• 이를 요청하는 기존 Microsoft Connect 제안이 있습니까?나는 그들에 대한 소문을 들었지만 가능성이 있는 키워드 중 어떤 것도 발견하지 못했습니다.

업데이트: 위에서 언급한 것처럼, 저는 이미 아무것도 찾지 못한 채 Microsoft Connect에서 검색했습니다.저는 또한 (놀랍게도) 구글을 검색했습니다.저는 단지 사람들이 왜 이 기능이 필요한지 설명하거나, VB.NET에서 이점을 지적하거나, 미래 버전의 C#에 추가되기를 희망하거나, 이 기능을 사용하거나, 오해의 소지가 있는 많은 조언을 찾을 뿐입니다.그러나 모든 현재 버전의 C#에서 그것을 생략한 근거에 대한 진술은 없습니다.그리고 제가 기존의 Connect 문제에 대해 질문하는 이유는 (a) 불필요한 사본을 만들지 않고 (b) 관심 있는 사람들에게 만들어야 하는지 말할 수 있기 때문입니다.

업데이트 2: 이전에 C# 팀의 일원이었던 Eric Gunnerson의 흥미로운 오래된 블로그 게시물 발견:

"네, 캐치에 조건을 붙일 수 있는 것이 직접 테스트를 작성하는 것보다 다소 더 편리하지만, 그것이 실제로 새로운 것을 할 수 있게 해주지는 않습니다."

그것은 내게 제대로 설명되기 전까지 내가 가졌던 것과 같은 가정이었습니다!

기존의 연결 버그에 대해서입니다.다음 호에서는 예외 플리터에 대해 설명합니다.사용자는 실행 시점의 의미에서 실제 필터가 되기를 원한다고 명시적으로 말하지 않았지만 IMHO는 논리에 의해 암시됩니다.

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=401668

하지만 그 문제 외에 당신이 찾고 있는 것과 관련된 문제를 찾거나 알 수 있는 문제는 없습니다.저는 VB에 대한 요구를 명시적으로 제기하는 별도의 이슈가 있는 것이 좋을 것 같습니다.넷 스타일 예외 필터입니다.

기존의 문제를 찾기 위해 실사를 조금만 해봤다면 중복 질문을 도입하는 것에 대해 크게 걱정하지 않을 것입니다.만약 속임수가 있다면, Mads는 그에 따라 그것을 속이고 당신을 주요 요청에 연결할 것입니다.

C# 팀으로부터 공식적인 응답을 받는 부분에 대해서는 1) 연결 버그를 제출하거나 2) 메인 버그에 속았을 때 얻을 수 있을 것입니다.저는 지금 밖에 공식적인 이유가 있는지 정말 의심스럽습니다.

이 문제에 대한 제 추측은 다음과 같습니다.제 생각에 이 기능은 원래 C# 1.0 기능 세트에 없었던 것 같습니다. 그 이후로 언어로 변환할 수요가 충분하지 않았습니다.C# 및 VB 팀은 매 선박 주기 시작 시 언어 기능의 순위를 매기는 데 엄청난 시간을 소비합니다.우리는 때때로 매우 어려운 삭감을 해야 합니다.수요가 충분하지 않으면 기능이 언어로 변환될 가능성은 거의 없습니다.

최근까지 VB의 차이를 이해하는 10명 중 1명을 찾기가 힘들 것이라고 확신합니다.Net의 Try/C# 캐치 블록에서 일반 오래된 if 문을 사용할 때와 사용할 때.최근에는 사람들이 좀 더 신경 쓰는 것 같아서 아마도 미래 버전의 언어로 만들 것입니다.

예외 필터 주입을 사용하는 것이 대리자 해결 방법을 사용하는 것보다 쉬울 수 있습니다.

당신의 질문에 대한 진정한 답변을 위해서는 앤더스 헤일스버그 또는 원래 디자인 회의에 참석했던 사람의 답변이 필요할 것입니다.다음에 C# 디자인팀이 면접을 볼 때 채널 9 면접관의 질문을 받을 수 있는지 확인해 볼 수 있습니다.

원래 결정이 내려졌을 때 예외 필터는 득보다 실이 많을 수 있는 불필요한 합병증으로 간주되었습니다.이 인터뷰에서는 확인된 예외를 지원하지 않기로 한 결정에 대해 입증되지 않은 기능에 대해 '침묵'으로 일관하고 싶다는 열망을 분명히 볼 수 있습니다.선택한 예외에 대한 문제입니다.

저는 사후 진단 시나리오가 언어의 예외 필터에 대한 액세스를 제공해야 한다고 강하게 주장한다고 생각합니다.그러나 그러한 시나리오는 그 당시에 명확하게 설명되지 않았을 수 있습니다.또한 이러한 시나리오에는 V1에서는 제공되지 않았던 적절한 툴링 지원이 필요합니다.마지막으로 이 기능을 추가하는 것에 대해 우리가 고려하고 있지 않은 큰 부정적인 점이 있을 수 있습니다.

연결 버그가 없으면 해당 버그를 입력하고 다른 사용자에게 투표하도록 권장해야 합니다.[언어에 맞는 CLR 기능을 설계하는 것보다 CLR 기능에 대한 액세스 권한을 요청하는 것이 좋습니다.]

저는 자바에도 필터 옵션이 있다고 생각하지 않습니다.만약 그렇다면, 우리는 C#에서도 하나를 볼 수 있을 것이라고 추측합니다. VB 팀이 깨끗한 슬레이트로 시작했다는 점을 감안할 때 VB.net 은 우연히 하나를 볼 수 있을 것입니다.

C#의 미래 버전에서 이 옵션을 사용하는 한 사용자에게 유리하게 작용할 수 있는 한 가지는 C#과 VB.net 의 미래 버전에서 언어 기능 간의 동등성을 유지하려는 Microsoft의 명시된 목표입니다.저는 그것을 근거로 제 주장을 내세울 것입니다.

http://www.chriseargle.com/post/2009/01/Parity-Between-Languages.aspx

첫 번째 질문과 관련하여, 만약 공개적인 성명이 있었다면, 그것은 웹 어딘가에 올려졌을 가능성이 높으며, 이 경우 구글은 (존재하는 경우) 무언가를 찾아야 합니다.

C# 팀과의 직접 이메일이라면 NDA 하에 있을 가능성이 높기 때문에 게시할 수 없습니다.

두 번째 질문에서는 새 제안을 입력하기 전에 사용하라는 메시지를 표시하는 Microsoft Connect 검색 기능이 있습니다.만약 당신이 그것을 찾을 수 없다면, 아마도 없을 것입니다.

제가 추천하는 것은 제안을 넣은 다음, 다른 사람들이 그것에 대해 고려하도록 홍보하는 것입니다.

제가 이해하기로는, 재투입 순간에 내부 함수의 핸들러가 실행되고 그것이 여러분에게 문제를 야기합니다.

그러나 실제로 다시 던지지 않고 예외를 통과시키는 예외 필터가 있다고 가정해 보겠습니다.당신은 여전히 어딘가에서 어떻게든 그것을 처리해야 할 것이고, 당신은 그곳에서 같은 종류의 문제(최종적인 영향)에 부딪힐 것입니다.

따라서 제가 오해하고 있는 것이 아니라면, 언어 지원 예외 필터를 사용해도 큰 이득이 없습니다.

C#에서 예외 필터링이 없는 이유를 두 가지 이상 생각할 수 있습니다.

1. 예외 필터를 허용하면 프로그래머가 1차 통과 예외 처리 중에 작업을 수행하도록 권장할 수 있으며, 이는 '캐치' 또는 '최종적으로' 안전하게 수행될 수 있음에도 불구하고 그 당시에는 안전하지 않을 수 있습니다.예를 들어, "try" 블록 내의 코드가 잠금을 획득하고 잠금이 유지되는 동안 예외를 던지면 잠금은 외부 예외 필터 실행 중에 유지되지만 외부 "catch" 또는 "finally" 블록이 실행되기 전에 해제됩니다.또한, 적어도 마지막으로 확인했을 때 예외 필터 내에서 발생하고 예외 필터 내에 포함되지 않은 예외는 조용히 억제되었습니다. 즉, 추악한 상황이었습니다.
2. C#의 구현자들은 그들의 언어를 '프레임워크 불가지론적'으로 만드는 비전을 가지고 있습니다.C#이 .net first-pass 예외 필터링을 지원하는 경우 해당 기능을 사용한 프로그램은 예외를 다르게 처리하는 프레임워크에서 사용할 수 없습니다.이것은 C#이 프로그램이 'Object'를 재정의하는 것을 금지하는 것과 같은 이유입니다.마무리()dije'오브젝트'를 둘러싼 추리가 진행되는 동안.Finalize()'에 결함이 있습니다(destrator를 올바르게 사용하려면 다른 플랫폼별 메서드를 사용해야 하므로 'Object'에 대한 destrator 구문을 사용해야 합니다).final()'은 결함이 있는 소프트웨어의 작성을 장려하기 위해 t77을 제외하고는 아무것도 수행하지 않습니다.) 예외 필터와 관련하여 추론은 어느 정도 일리가 있습니다.반면에 이 문제를 해결하는 올바른 방법은 예외 필터를 직접 노출하지 않았더라도 일부 예외 필터 관련 기능을 노출하는 것입니다.

C# 및 vb에서 꼭 보고 싶은 기능 중 하나는 예외 필터를 구현해야 하지만 예외 필터를 직접 노출할 필요는 없는 옵션입니다.Exceptiona에 대한 매개 변수finally블록. 이 매개 변수는 다음과 같습니다.null탐지되지 않은 예외가 발생하지 않는 경우, 그렇지 않으면 문제의 예외가 유지됩니다.이것은 프로그램이 예외가 발생했을 때 무언가를 하고 싶어하지만 실제로는 그것을 "처리"하지 않는 상황을 허용할 것입니다.대부분의 경우,Exception매개 변수는 확인하는 것 외에는 어떤 것에도 사용되지 않을 것입니다.null(즉, 기능이 노출되는 것과 같습니다.fault블록), 그러나 정리 중에 예외가 발생하는 경우에는 이점을 제공합니다.현재, 만약 예외가 발생하는 동안finally블록, 그것을 억누르거나 둘 중 하나가 필요합니다.finally-예외를 차단하거나 기존 예외를 덮어씁니다.이전 예외를 사용할 수 있는 경우finally블록 코드를 사용하면 랩을 하거나 로그를 기록할 수 있습니다.

언급URL : https://stackoverflow.com/questions/602066/why-doesnt-c-sharp-have-support-for-first-pass-exception-filtering