예외 및 성능

예외와 관련된 일반적인 문제 중 하나는 정기적으로 실패하는 코드에 예외를 사용하는 경우 구현 성능이 허용되지 않는다는 것입니다. 이는 유효한 우려입니다. 멤버가 예외를 throw하면 성능이 크게 저하될 수 있습니다. 그러나 오류 코드 사용을 허용하지 않는 예외 지침을 엄격하게 준수하면서 좋은 성능을 얻을 수 있습니다. 이 섹션에서 설명하는 두 가지 패턴은 이 작업을 수행하는 방법을 제안합니다.

❌ 예외가 성능에 부정적인 영향을 줄 수 있다는 우려 때문에 오류 코드를 사용하지 마세요.

성능을 향상시키려면 다음 두 섹션에 설명된 Tester-Doer 패턴 또는 Try-Parse 패턴을 사용할 수 있습니다.

Tester-Doer 패턴

때로는 멤버를 둘로 나누어 예외를 발생시키는 멤버의 성능을 향상시킬 수 있습니다. Add 인터페이스의 ICollection<T> 메서드를 살펴보겠습니다.

ICollection<int> numbers = ...
numbers.Add(1);

컬렉션이 읽기 전용이면 메서드 Add 가 throw됩니다. 이는 메서드 호출이 자주 실패할 것으로 예상되는 시나리오에서 성능 문제가 될 수 있습니다. 문제를 완화하는 방법 중 하나는 값을 추가하기 전에 컬렉션이 쓰기 가능한지 여부를 테스트하는 것입니다.

ICollection<int> numbers = ...
...
if (!numbers.IsReadOnly)
{
    numbers.Add(1);
}

조건을 테스트하는 데 사용되는 멤버입니다. 이 예제에서 속성 IsReadOnly은 테스터라고 합니다. 잠재적으로 throw 작업을 수행하는 데 사용되는 멤버인 예제의 Add 메서드를 doer라고 합니다.

✔️ 예외와 관련된 성능 문제를 방지하기 위해 일반적인 시나리오에서 예외를 throw할 수 있는 멤버의 Tester-Doer 패턴을 고려합니다.

Try-Parse 패턴

매우 성능에 민감한 API의 경우 이전 섹션에서 설명한 Tester-Doer 패턴보다 훨씬 빠른 패턴을 사용해야 합니다. 패턴은 멤버 이름을 조정하여 잘 정의된 테스트 사례를 멤버 의미 체계의 일부로 만들도록 요구합니다. 예를 들어 DateTime은 문자열 구문 분석이 실패할 경우 예외를 throw하는 메서드를 Parse 정의합니다. 또한 구문 분석을 시도하는 해당 TryParse 메서드를 정의하지만 구문 분석이 실패하면 false를 반환하고 매개 변수를 사용하여 out 성공적으로 구문 분석한 결과를 반환합니다.

public struct DateTime
{
    public static DateTime Parse(string dateTime)
    {
        ...
    }
    public static bool TryParse(string dateTime, out DateTime result)
    {
        ...
    }
}

이 패턴을 사용하는 경우 try 기능을 엄격한 용어로 정의하는 것이 중요합니다. 멤버가 잘 정의된 try 이외의 다른 이유로 실패하는 경우 멤버는 여전히 해당 예외를 throw해야 합니다.

✔️ 예외와 관련된 성능 문제를 방지하기 위해 일반적인 시나리오에서 예외를 throw할 수 있는 멤버의 Try-Parse 패턴을 고려합니다.

✔️ 이 패턴을 구현하는 메서드에서는 "Try" 접두사와 Boolean 반환 형식을 사용하는 것이 좋습니다.

✔️ 각 멤버에 대해 예외를 발생시키는 멤버를 제공할 때, Try-Parse 패턴을 사용하십시오.

Microsoft Corporation의 일부 저작권 2005, 2009. 모든 권리 보유.

프레임워크 디자인 지침에서 Pearson Education, Inc.의 권한으로 재인쇄 : 재사용 가능한 .NET 라이브러리에 대한 규칙, 관용구 및 패턴, Krzysztof Cwalina 및 Brad Abrams의 제2판, Microsoft Windows 개발 시리즈의 일환으로 Addison-Wesley Professional이 2008년 10월 22일 출판했습니다.

참고하십시오

• 프레임워크 디자인 지침
• 예외에 대한 디자인 지침