그 동안 몇 명의 신출내기들이 쉽게 범하는 전형적인 결함(C#을 겨냥한)을 정리하는 데 시간이 좀 걸렸지만 개인의 힘은 유한한 결함의 범위가 비교적 좁고 일부 결함의 묘사도 정확하지 않다. 여기에 먼저 붙여서 생각을 모으고 더 많은 전형적인 결함을 정리할 수 있는지 알아보자.목표는 입문하기를 바라는 것이다.NET의 초보자는 보고 나서 굽은 길을 좀 줄일 수 있다.

1 리소스 여유 확보

CLR 위탁 관리 환경은 쓰레기 회수 역할을 하기 때문에 이미 만든 대상이 차지하는 메모리를 현저하게 방출할 필요가 없습니다.그러나 이것은 당신이 사용한 모든 대상을 소홀히 할 수 있다는 것을 의미하지는 않는다.많은 대상들이 다른 유형의 시스템 자원을 봉인했다. 예를 들어 디스크 파일, 데이터 연결, 네트워크 포트 등이다.이러한 자원의 사용 상태를 유지하면 시스템의 자원을 급격히 소모하고 성능을 약화시키며 결국 프로그램 오류를 초래할 수 있다.파일, 네트워크 포트, 데이터 연결을 열 때, 이 자원을 더 이상 사용하지 않을 때, 가능한 한 빨리 이 자원을 현시적으로 방출해야 한다.또한 자원에 대한 조작은 일반적으로 이상포획처리(Try.Catch)를 증가해야 하는데 이때finally에서 자원을 방출하는 것을 잊지 마세요. 이상을 포획할 때도 자원을 정상적으로 방출할 수 있도록 하세요.

2 다중 스레드를 올바르게 중지합니다.

FileStream fs = File.Open(…);
Try{…} Finally{ fs.Close;}

만약 위 코드가 작업 라인에서finally에 이미 진행되었다고 가정하면, 이때 UI 라인이 이 라인의Abort () 방법을 호출하면 fs가 될 가능성이 높다.Close가 실행되지 않았을 때, 작업 라인이finally 코드 블록에서 튀어나왔습니다.이렇게 하면 너의 fs는 영원히 클로즈되지 않을 것이다.대부분의 경우,finally는 영원히 실행되지만,Thread 호출은 포함되지 않습니다.Abort로 인한 ThreadAbortException 이상은 이 이유를 감안하여 Abort를 사용하는 것을 권장하지 않습니다.호출자가 어떤 행동을 취했는지 (Thread.Abort () 를 직접 사용하지 말고, 작업 라인이 호출자의 정지 요청에 주동적으로 응답할 수 있는지에 의존하십시오.대체적으로 스레드가 정지되어야 한다면 스레드 자체가 호출자에게 Cancel의 인터페이스를 개방하는 것을 책임져야 한다.

3 유형 변환 관련

데이터베이스에서 어떤 값을 읽으면 데이터가 있을 때 int 형식이고 데이터가 없으면 null을 얻을 수 있으며 형식이 강전되면 이상합니다.그래서 일반적으로 강전을 거의 사용하지 않기 때문에 사용하려면 반드시 이상 포획을 해서 프로그램의 이상을 피해야 한다.

강전이 좋지 않은 상황에서 TryParse 방법을 사용하는 것을 권장합니다. 이 방법은 이미 Parse 방법에 대해 이상 처리를 했습니다.

컨버트도 가능하며 마찬가지로 이상 포획이 필요합니다.사실 유형 전환, 서열화 등 조작과 관련된 곳은 모두 이상을 포착해야 한다.

질문

문자열 작업에서 결합이 많은 경우 StringBuilder를 사용하는 것이 좋습니다.String을 사용하면 성능이 크게 저하됩니다.왜냐하면string 대상은 매우 특수한 대상이기 때문에 일단 값을 부여받으면 바꿀 수 없다.실행할 때 String 클래스의 모든 연결 작업 (예를 들어 값 부여, '+' 등) 을 호출하면 메모리에 새 문자열 대상을 만들고, 이 대상에 새 메모리 공간을 할당해야 한다는 것을 의미합니다.

5 const 상수 수정으로 인한 문제

프로그램이 다른 dll의const 상수를 인용할 때 특히 주의해야 합니다.이 dll의 const 상수를 수정한 후, 이 dll의 이 const 상수를 인용한 모든 프로그램을 다시 컴파일해야 합니다. 그렇지 않으면 프로그램에서 사용하는 이 상수 값은dl의 것과 일치하지 않습니다.또한 const 대신readonly를 사용하면 이 문제를 해결할 수 있습니다. 다시 컴파일할 필요가 없습니다. const는 컴파일링 상수이고,readonly는 실행 시 상수이기 때문입니다.

6 C# 컴파일 대상 플랫폼 문제

프로그램이 의존하는 dll의 컴파일링 목표 플랫폼이 X86이면 프로그램 자체의 컴파일링 목표 플랫폼도 반드시 X86이어야 한다. 그렇지 않으면 64비트 컴퓨터가 실행될 수 없다.

7 스레드 간 액세스 제어

인터페이스 프로그램을 개발할 때 시간이 많이 걸리는 작업이 발생할 수 있습니다. 프로그램의 우호성을 위해 우리는 보통 작업 라인에서 시간을 소모하는 작업을 수행하고 실행 정보를 메인 UI 라인에 표시합니다.작업 스레드에서 주 UI 스레드의 컨트롤을 직접 조작하면 이상이 발생하기 쉽습니다. "다른 스레드에서 컨트롤 스레드를 만드는 값을 수정할 수 없습니다."컴파일러가 크로스 스레드에 대한 접근을 금지하는 것을 설정하면 오류가 발생하지 않지만 예측할 수 없는 문제가 발생할 수 있습니다.이때 위탁 또는 익명 위탁의 방식으로 실현하는 것을 건의합니다.

8 이상을 다시 던지는 정확한 방법

try
{
    //do something
}
catch(Exception ex)
{
    throw;
}

정확한 쓰기 방법은throw입니다.throw ex를 사용하지 마십시오. 그렇지 않으면 Stacktrace가 비어 진정한 이상 코드의 위치를 찾을 수 없습니다.