2009-10-07 2 views
1

다음은이 주제에 관한 이전의 두 질문은 다음과 같습니다C#의 다중 유형 catch 블록에 사용할 수있는 구문은 무엇입니까?

오늘 일하는이 적절한 구문이 기능은 이제까지 C# 언어에 추가해야 될 줄 알았는데 . 누구든지 그것에 대해 의견이 있습니까?

e 유형은 나열된 모든 예외 유형의 기본 유형 또는 인터페이스 여야합니다.

편집 :이 예에서, 캐치 블록 처리 중 또는 ArgumentNullExceptionArgumentOutOfRangeExceptione 및 호출 형 ArgumentException의 변수에 예외 인스턴스를 놓는다. 나열된 두 가지 이외의 다른 유형의 ArgumentException은 처리하지 않습니다. ,as의 연관성에 대해 혼란이 있었다고 생각합니다.

편집 2 :e의 유형의 변수에 대한 모든 업 캐스팅 나열된 예외, 다음 코드는 빠른 (잠재적으로 크게) 현재의 문법보다는 그것을 만드는, 어떤 캐스트 또는 명시 적 유형 검사없이 MSIL로 깨끗하게 컴파일하는 경우 ArgumentException을 붙잡고, 의도 한 두 가지가 아닌 경우 throw;을 붙잡습니다. 문제는 Exception을 잡고 다른 유형 인 경우 처리하고 재실행 할 수있는 두 가지 유형을 확인하는 경우 더욱 분명합니다.

try 
{ 
} 
catch (ArgumentNullException, ArgumentOutOfRangeException as ArgumentException e) 
{ 
} 
+0

downvoters가 왜 이것을 downvoted했는지 말할 수 있습니까? 문제? – Dykam

+1

유일한 질문은 "누구나 그것에 대해 의견이 있습니까?"입니다. 대답은 : "그렇습니다, 우리 중 대부분은 매우 유명한 사람들입니다." "진짜"질문, 또는 GTFO. – abelenky

+0

[다른 종류, 기능적 스타일] (http://community.bartdesmet.net/blogs/bart/archive/2008/01/06/exception-handling-in-functional-style.aspx) : 음, 꽤 깨끗한 것은 아닙니다. ** 그리고 이것은 작동합니다. ** – nawfal

답변

-1

인스턴스 (e)를 선언하지 않은 경우에만 작동합니다. 블록 내부의 e를 참조하면 무엇입니까?

+0

'e'는 명백히'ArgumentException'입니다. 왜냐하면 그 타입이 모든 나열된 예외 처리의 기본 유형 또는 인터페이스 여야하기 때문입니다. catch 블록은'ArgumentNullException'과'ArgumentOutOfRangeException' 이외의'ArgumentException'을 처리하지 않습니다. 나는이 문법이 당신이 언급 한 문제를 해결했기 때문에 실제로이 질문을 실제로 요구했다. –

0

나는 C#에서 매우 자주 이것을 원한다는 것을 알지 못했지만 Java에서는 확인 된 예외를 여러 개 잡아서 다른 예외로 감싸 야하는 다양한 상황이 있음을 발견했습니다. 던지다.

나는 아마도 일부 구문 싶습니다 뭔가 그 : 다시

try 
{ 
} 
wrap (OneException as AnotherException) 
catch (HandleableException e) 
{ 
    // Actual handling for some exception types 
} 

...하지만, 나 자신이 C#에서보다 자바에 더 많은 것을하고 찾을 수가.

는 모든 예외는 System.Exception에서 파생 단지

try{} 
catch(Exception e) 
{} 

때문에, 길, 이것보다 높은 C 번호 :

+0

이것은 모든 ArgumentException을 처리하지 않고 나열된 두 개만 처리합니다. 'as ArgumentException e'는'catch'가 처리하도록 선언 된 가능한 모든 예외와 호환되도록 보장 된 타입을'e'에 제공합니다. –

+0

질문을 편집 했습니까? 아니면 질문을 놓쳤습니까? 나는 그저 전에 세 가지 예외 사항을 열거했다고 맹세 할 수있었습니다. 아 잘 편집했습니다. –

+0

코드를 편집하지는 않았지만, 왜 이것이 현재보다 좋을지 설명하는 두 개의 단락을 추가했습니다. 여러 종류의 예외에 대한 예외 처리가 필요한 일부 API (ASP.NET입니까?)가 있으며 코드를 개선하는 간단한 방법없이 매우 복잡해졌습니다. –

0

이미이 작업을 수행 할 수 있습니다 내 목록 다른 향상된 기능이 있습니다. 그리고 위에서와 마찬가지로 catch 블록 자체에서 예외 유형을 결정할 수 있습니다.

+0

이것은이 기능이 부족한 경우 해결 방법이며, 특별히 제가 추가 한 링크에서 논의되었습니다. 이 사용 사례에 대한 언어 구문을 추가 할 때의 주요 이점 중 하나를 해결하기 위해 ** 편집 2 **를 추가했습니다. –

+0

Wokrarounds가 작동합니다. 언어 기능을 추가하기까지 얼마나 기다려야합니까? 그것은 아마 일어날 것인가? –

+0

하지만이 질문의 핵심은 아닙니다. 나는 이미 상황을 어떻게 처리 할 수 ​​있는지 알고있다. 언어는 시간이 지남에 따라 진화하여 사람들이 생각해내는 특성을 취합니다.아마 이런 일은 결코 일어나지 않을 것입니다 (기능상의 수용률이 매우 낮습니다). 그러나 적어도 저에게는 생각할 가치가 있습니다. :) –

3

이 참조 :
Cool or Stupid? Catch(Exception[NamingException, CreateException] e)

그 질문에 대한 내 대답은 사용 블록처럼 그들을 "스택"을하도록해야한다는 것입니다 :

try 
{ 
} 
catch (ArgumentNullException e) 
catch (ArgumentOutOfRangeException e) 
catch (ArgumentException e) 
{ 

} 

을 당신이 위한거야 볼 수 있지만 또는이 아닌입니다. 개인적으로는 접근법이 매우 유용한 것으로 보이지 않습니다. 왜냐하면 이미 실제 인터페이스가 아닌 예외 유형으로 제한되어 있고 이중 상속이 없기 때문입니다.

+0

나는 case 문을 스택하는 방법을 모방하므로이 접근법을 좋아한다. 코더가 필요에 따라 catch 블록에서 유형을 기꺼이 판별하는 한. –

+0

두 가지 편집 내용을 확인하십시오. 또한 'e'유형의 문제를 해결하지 못합니다. –

+0

나는 이것이 효과가있을 것이라고 생각하지만 매개 변수의 변수 이름은 아마도 고유해야합니다. –

0

ArgumentNullExceptionArgumentOutOfRangeException이 서로 다른 인터페이스를 가지고 있다면 올바르게 캐스팅하는 데 어려움이 있습니다.

예를 들어 ArgumentOutOfRangeExceptionActualValue 속성을 갖습니다. 당신이 그것을 사용했다, 당신 같은 뭔가 겁니다 :

try { 
    return klass.newInstance(); 
} catch (InstantiationException | IllegalAccessException e) { 
    throw new AssertionError(e); 
} 

편집 :

이 기능의

if(e is ArgumentOutOfRangeException) 
{ 
    // use e.ActualValue 
} 
else 
{ 
    // use e.Data 
} 
+0

catch 블록의 대부분 또는 모든 코드가 처리 된 예외 유형 각각에 대해 공유되는 경우를위한 것입니다. –

1

포함은 다음 구문과 자바 7에 대한 planned입니다 내가 의도라고 생각합니다 e의 정적 유형이 나열된 예외 중 가장 특수한 공통 수퍼 클래스가되도록합니다. (Java에서는, java.lang.Throwable 클래스의 인스턴스 만이 Throw 될 수 있기 때문에 예외적으로 예외를 다시 던질 수 없기 때문에 공통의 슈퍼 인터페이스를 잡는 것이 제한된 유틸리티입니다.)

+0

그 제안은 정적으로 유효한 타입을 변수'e'에주는 주된 문제를 다루지 않기 때문에 잘못 정의되었습니다. 처리 된 예외 목록 (내 게시물에서','및 Java 제안에서'| '로 구분됨)은 예외 변수 선언 유형과 분리되어야합니다. 광산에서는 두 가지를 명확하게 구분하기 위해 'as'를 사용합니다. Java 제안서는 예외 목록의 각 유형을'VariableType'으로 형변환 할 수있는 * 요구 사항과 함께'as' 또는'catch (InstantiationException | IllegalAccessException : VariableType e)'를 사용할 수 있습니다. –

관련 문제