C# 오류 검사 클래스 만들기?

저는 OOP를 처음 접해 보았습니다. 프로그램에서 저는 일반적인 방법을 포함하고있는 Utilities 클래스를 가지고 있습니다. Utilities 클래스에서 오류를 검사해야합니까? 아니면 오류 검사를 위해서만 새로운 클래스를 만들어야합니까?C# 오류 검사 클래스 만들기?

출처

2010-05-18 sooprise

"오류 검사"란 무엇을 의미합니까? ? – Jack

유틸리티 클래스에 대한 오류를 검사하고 있습니까? 아니면 일반적인 오류 검사 코드입니까? – Rusty

필요한 것은 AOP입니다! 하하하하! – Will

"유틸리티"클래스는 괴물이되는 괴로운 습관이 있습니다. 오류 검사 코드를 별도로 유지하십시오.

출처

2010-05-18 14:30:24

정확히 무엇을하고 싶은지 잘 모르겠지만, 오류 검사 클래스 이 (가)을 유틸리티 클래스에 포함해서는 안됩니다. 오류 처리는 자신의 클래스를 보장하는 기능 클래스입니다.

또한 OOP는 기능 및 루틴을 클래스에 넣는 이 아니고임을 기억하십시오. OOP는 사물을 나타내는 클래스를 만들고 있습니다. 가능한 한 "유틸리티"수업을 피하십시오.

출처

2010-05-18 14:30:28

일반적으로 말해서 코드를 작성하는 곳의 오류를 처리하거나 발신자가 오류를 처리하도록합니다 (예 : 예외가 호출 스택을지나 가게합니다). 유틸리티 기능인지 여부는 중요하지 않습니다.

public static class Utility 
{ 
    public static string GetSomeString(string someOtherString) 
    { 
     try 
     { 
      // something 
     } 
     catch (exception ex) 
     { 
      // handle error 
     } 
     return result; 
    } 
}

출처

2010-05-18 14:31:26

pls하지만 거기에 던지기 전 .. 예외가 일어나고있는 이유에 대해 고려하지 않고 예외를 삼키려는 시도를 몇 번이나 볼 까봐 두렵다. –

@MrTortoise : 예외를 재발행하는 것은 나쁜 습관이라고 말해주는 사람이 있습니다. '// handle error'는 의도를 명확하게해야합니다. 어쨌든'throw ex'를 사용하여 다시는 결코 돌아 오지 않습니다. 그것은 호출 스택을 clobbers. 대신'throw '를 사용하십시오. http://winterdom.com/2002/09/rethrowingexceptionsinc –

idd 전적으로 동의 - 통화 스택을 잃는 것은 범죄입니다. 나는 새로운 예외를 생성하는 경향이있다. 왜냐하면 나는 데이터를 잡아 내고 innerException에 기존의 에러를 넣고 싶다면 추가하고 싶은 데이터가 종종있다. 그렇지 않으면 try catch를 사용할 필요가 없다. - 나는 깨닫지 못했다. 그냥 throw를 사용하여 호출 스택을 유지하지만 ... 나는 결코 그것을 시도하지 않을거야. –

나는 생각합니다. 오류는 일반적으로 예외인데,이 클래스는 자체 클래스이며 처리 방법을 알고있는 곳에서 정확히 처리됩니다.

로깅 또는 유사한 작업을 찾으려면 Log4Net과 같은 완성 된 프레임 워크를 사용하거나 PostSharp에서 제공 한 것과 같은 AOP를 사용해야합니다.

출처

2010-05-18 14:32:54 Lucero

오류 검사에서 이러한 입력 유효성 검사는 검사해야 할 대상과 함께 수행해야합니다. 다소 복잡한 경우가 아니면 확인중인 개체의 클래스에서 별도의 메서드로 이동해야합니다. 여전히 너무 복잡한 경우 유효성 검사에만 사용되는 별도의 클래스를 만들어야합니다. 유효성 검사 클래스는 기본 클래스 내에 중첩되어 있거나 internal으로 표시되어야합니다.

출처

2010-05-18 14:33:18 Tesserex

Global.asax 파일에서 Application_Error 이벤트를 사용하면 어떨까요? 응용 프로그램에서 처리되지 않은 오류가 발생하면 해고됩니다.

출처

2010-05-18 14:35:07

당신이 EG 문자열 일반적인 검사를 찾을 때 ... 오류 코드에서 그것을 할 jsut 유효 ID의 의미에서 검사를 의미하는 경우

오류 검사의 다른 형태는, 어쩌면 정규 표현식의 길이가있다 있습니다 ... int는 범위를 가지고 있습니다 ...하지만이 테스트에서는 고정 클래스로 끝납니다.하지만 이는 단순히 리팩토링입니다. 나는

단위 테스트

이 다시 메인 코드를 다른 프로젝트에있을 것입니다 단순히 방법의 범위를 정의 할 ... 방법에 도착 하위 정적 클래스와 정적 클래스와 끝까지.

오류 검사.

디버깅하는 동안 가정을 테스트하기 위해 일반적인 오류 검사를 위해 상점 전체에 debug.assert 문을 사용하는 경향이 있습니다. 이러한 테스트를 약한 형태의 단위 테스트로 사용하는 경향이 있습니다.

예외 관리 이것은 당신이 작업하고있는 지역에 따라

. 백엔드에서 예외가 프런트 엔드에 비해 매우 다른 관리 시나리오가 있습니다.

iinstance WCF에는 예외 인터페이스가 있습니다. IErrorHandler iirc 올바르게,하지만 거기에 아무것도 거기에 불과 몇 가지 결함이 건너 갈 수 있습니다. 백엔드에서 이러한 결함은 모든 수준에서 데이터에 첨부 된 많은 예외가있는 예외로 인해 발생할 수 있습니다. 데이터가 프런트 엔드에 도달하는 것을 원하지는 않지만이를 기록해야합니다. 결과적으로 프론트 엔드에서의 예외는 단순히 실제 예외의 껍데기에 불과합니다 ... 요점은 유틸리티 클래스가 거대하게 될 것이므로 그 클래스를 여러 클래스로 분해하기를 원할 것입니다 .

그러나 이것은 예외가 별도의 프로젝트에 있어야하는 이유입니다. 그런 다음 예외를 다시 참조하고 다시 사용할 수 있습니다.

나는 오류 처리에 포함시키는 경향이있는 프로젝트가있다. 또한 WCF 서비스를 설정 했으므로 예외를 발생시킬 수 있습니다.이를 신고 할 경우에는 타겟 버그 수정에 대해 생각하십시오.

상황이 어떻게 성장하는지에 대한 예는 오류 및 모든 데이터를 직렬화 할 수 있어야한다는 것입니다.

그래서 나는 하나의 유틸리티 클래스를 부끄럽게 생각합니다. 하나의 메소드로 시작하는 것들은 일반적으로 범위 크립이 시작되면 놀라 울 정도로 커집니다.

이런 종류의 것은 OOP를 뛰어 넘는 구조적인 질문으로 - 코드를 유틸리티 클래스로 옮기고 싶은 이유를 알 필요가 있습니다. 그런 다음 간단히 말해서 충분하다고 생각하면됩니다. 그것을 옮기는 것이 좋지만 더 나아가서 오류 관리를 전체 솔루션으로 생각해야합니다. SOA 스타일의 솔루션 (또는 적어도 프로젝트)을 구걸하고 있습니다. .... 일반적인 애플리케이션뿐만 아니라 불변 인 것들 중 하나입니다 ....

출처

2010-05-18 14:42:01

C# 오류 검사 클래스 만들기?

답변

관련 문제