.NET Framework - 예외 디자인 원칙에 대한 자세한 설명

Frontline

예외 설계 지침은 Microsoft msdn을 참조하고, 과거 개발에서 자신의 이해와 예외 오류 처리를 결합하고, 소프트웨어 개발 아키텍처를 요약하고, 더 나은 디자인 예외 오류 지침 세트입니다.

가이드라인 소개

실행 실패 개념

실행 실패의 의미: 실행 실패는 구성원이 수행할 수 없는 작업을 할 때마다 발생합니다. 예를 들어 OpenFile 메서드가 열린 파일 핸들을 호출자에게 반환할 수 없으면 실행 실패로 간주됩니다.

번역:

작업 실패의 의미: 구성원 모듈이 예상 작업을 완료하지 못할 때마다 작업 실패가 발생했다고 합니다. 예를 들어 OpenFile 메서드는 열린 파일에 대한 핸들을 호출자에게 반환할 수 없습니다. 이는 작업 실패입니다.

프레임워크에서 예외 처리

프레임워크에서는 실행 오류를 포함한 모든 오류 조건에 예외를 사용합니다.

번역:

프레임워크에서는 실행 오류를 포함한 모든 오류 조건을 처리하기 위해 예외를 사용합니다.

요약 지침

Exception을 설계할 때 어떤 방법을 금지해야 하는지, 주저 없이 해야 하는지, 고려해야 할 사항은 아래 표와 같습니다.

编号	方法	做法
1	返回错误代码	禁止
2	执行错误，要抛出异常；如OpenFile()未返回文件句柄	建议
3	假如代码再继续执行就变得不安全时，考虑是调用System.Environment.FailFast终止进程还是抛异常。	考虑
4	如果有可能的话，在正常的控制流处，抛异常，见下面的分析	禁止
5	抛异常对性能的影响。	考虑
6	协定中纳入异常处理部分	建议
7	将异常作为返回值返回	禁止
8	使用异常生成器方法，为避免代码膨胀, 用helper方法创建异常和属性.	考虑
9	异常筛选器中抛出异常.	禁止
10	从finally 块中显示地抛出异常	禁止

　
　항목 4에 대한 설명:

일일 코딩에서는 관련 성능 문제를 피하기 위해 일반적인 시나리오에서 예외를 던질 수 있는 멤버에 대한 Tester-Doer 패턴을 고려하세요. Tester-Doer 패턴은 예외를 테스터와 Doer라는 두 부분으로 나누어 호출합니다. 테스터는 Doer가 예외를 발생시킬 수 있는 상태에 대한 테스트를 수행합니다. 테스트는 예외를 발생시키는 코드 바로 앞에 삽입되어 예외로부터 보호됩니다. http://blog.csdn.net/troubleshooter/article/details/18401491

코드:

테스터와 실행자는 각자의 역할을 수행하여 예외 발생을 완벽하게 줄이고 성능을 향상시킵니다.
Doer: 위 상태 모니터링이 양호하면 DoProcess()로 처리할 수 있으며, false이면 DoProcess()에 DoCheck() 로직이 포함되어 있으면 예외가 발생합니다. 하지만 이렇게 하면 분리 후에 DoProcess()는 예외를 발생시키지 않습니다!

if(DoCheck()==true)//这是Tester:状态监测
    DoProcess();

소프트웨어 개발 시 일반적인 예외 및 처리 방법(자체 요약)

1 UI 계층에서 노출되는 작업 인터페이스는 try로 래핑하는 것이 좋습니다.{} catch{} 블록, catch에서 디스크에 발생한 예외를 씁니다.

2 UI 레이어에서 타이머를 사용할 때 카운터의 콜백 함수에서 예외가 발생하면 타이머를 중지하여 오류 로그가 UI 레이어에 기록되지 않도록 해야 합니다. 파일.

3 최하위 계층에서 try{}catch{} 블록을 래핑하지 않는 것이 좋습니다 try{} 및 예외를 직접 발생시키려면 throw를 사용하는 것이 좋습니다. catch{} 블록은 UI 레이어에 래핑되어 있으므로 이러한 레이어에 작성할 필요가 없습니다.

4 throw는 향후 작업을 직접 중단하고 외부 스택 try{} 및 catch{}, 즉 UI 계층으로 점프합니다. 일반적으로 함수에서 수행하는 것이 좋습니다. 오류 코드를 반환하지 않습니다.

5 일괄 가져온 데이터를 처리하는 동안 로컬 예외가 발생했습니다. Excel은 인력, 장비, 계획, 자재, 프로세스 등을 가져옵니다. 특정 데이터 행이 규칙을 위반하는 경우 지금은 예외를 발생시키지 않는 것이 좋습니다. 다음 행은 가져올 수 없으며 가져온 데이터는 더티 데이터가 됩니다.
일반적으로 두 가지 접근 방식이 있습니다. 특정 행에 불법 데이터가 나타나 로그 파일에 기록됩니다. 나중에 이 파일을 기반으로 데이터를 가져오지 않은 것으로 확인되면 이 데이터를 별도로 처리할 수 있습니다. ; 가져오기 전에 직접 확인하세요. 모든 행의 데이터가 유효한지 확인한 후 을 하나씩 가져오세요. 그렇지 않으면 프롬프트가 뜨고 데이터베이스에 데이터가 기록되지 않습니다. 일반적으로 후자의 접근 방식을 권장합니다. 이 접근 방식을 Tester-Doer 예외 모드라고 하며 Microsoft에서도 권장합니다.

6 대시보드 표시 데이터를 처리하는 중 로컬에서 예외가 발생했습니다. 이 처리 방식은 5와 다릅니다. 일반적으로 이때 예외가 발생하면 전자의 5 방식을 채택하는 경우가 많습니다. 올바른 데이터를 표시하고, 잘못된 데이터는 검토를 위해 로그에 기록합니다; 그러나 표시된 인터페이스의 기본 데이터가 존재하지 않으면 예외가 직접 발생하여 로그에 기록되고 로그를 통해 해결될 수도 있습니다. 따라서 데이터의 이상 심각도에 따라 처리해야 합니다.

7 개발 문서, 로그, 분석을 바탕으로 특정 기능이 구현되지 않는 이유를 찾아보세요. 먼저, 개발 문서를 보관하고 현재 사용자 요구 사항이 개발 문서의 요구 사항과 일치하는지 확인하십시오. 일관성이 있으면 이때 로그의 역할이 표시됩니다. 예를 들어 일주일 동안의 모든 프로세스 완료를 요약하는 파이 차트가 없으면 해당 파이 차트가 존재하지 않을 수 있습니다. 개발 프로세스가 체크되어 있다고 해서 프로세스가 있다는 의미는 아니며, 프로세스가 발견되지 않으면 예외가 발생할 수 있으며, 로그에 기록하면 그 이유를 알 수 있습니다. 따라서 이러한 유형의 문제도 로그에 기록해야 합니다. 오류는 아니지만 예외로 분류될 수 있습니다.

8 이 함수는 후속 로직에서 참조되는 메서드와 속성이 포함된 개체를 반환합니다. 이것은 불가피합니다! 그리고 대부분의 기능의 구현은 이것에 달려 있습니다. 반환된 객체는 나중에 참조되므로 은 null 비교를 수행하는 것이 좋습니다. null인 경우 UI 레이어로 전달되어야 하며 메시지 프롬프트가 표시되거나 예외가 직접 발생합니다. UI 레이어는 상황에 따라 처리 후 로그에 기록합니다.

위 내용은 .NET Framework - 예외 디자인 원칙에 대한 자세한 설명의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!