메르세데스' blog

C# 예외 처리에서 Exception, catch, finally의 역할과 사용 기준을 실제 코드로 설명합니다. 오래된 예제의 의미는 살리되 현재 기준에서 잘못 적용하기 쉬운 부분을 함께 고쳤어요. 아래 순서대로 확인하면 단순한 화면 복사보다 실제 판단에 도움이 됩니다. 기존 글의 예외 발생 예제입니다. 실제 코드에서는 구체적인 예외 형식을 먼저 처리하는 편이 좋습니다. Exception으로 받으면 무엇이 달라질까 System.Exception 은 대부분의 일반적인 .NET 예외가 이어받는 기본 형식이에요. 그래서 catch (Exception ex) 는 여러 오류를 한곳에서 받을 수 있습니다. 편해 보이지만, 복구 방법이 다른 오류까지 같은 방식으로 처리하게 된다는 문제가 생겨요. 파일이 없을 때는 경로를 다시 확인할 수 있지만, 메모리 부족이나 프로그램 상태 훼손은 같은 안내문으로 넘길 일이 아닙니다. 예상 가능한 예외는 FileNotFoundException , FormatException 처럼 구체적으로 받고, 가장 바깥 경계에서 기록이 필요할 때만 Exception 을 마지막에 두는 편이 읽기 쉽습니다. finally는 성공과 실패에 상관없이 실행된다 finally 는 try 블록이 정상 종료되거나 예외가 발생해도 실행됩니다. 파일, 네트워크 연결, 잠금처럼 반드시 돌려놓아야 하는 자원을 정리할 때 쓰는 이유예요. 다만 최신 C#에서는 IDisposable 자원에 using 을 적용하면 정리 의도가 더 분명해집니다. try { int number = int.Parse(input); Console.WriteLine(number); } catch (FormatException) { Console.WriteLine("숫자 형식을 확인하세요."); } finally { Console.WriteLine("입력 처리가 끝났습니다."); } 예외를 잡은 뒤 조용히 버리지 않는다 빈 c...

C# 제네릭 메서드는 동작은 같고 데이터 형식만 다른 코드를 한 번 작성하게 해줍니다. 호출 인수만으로 형식을 알 수 있으면 컴파일러가 T를 추론하고, 특정 기능이 필요한 형식만 받으려면 where 제약 조건을 붙이는 것이 핵심이에요. 2015년 작성한 제네릭 메서드 예제입니다. 꺾쇠괄호의 T가 호출 시 실제 형식으로 결정됩니다. 기존 예제의 실행 결과 화면입니다. 현재 .NET에서도 형식 추론 원리는 같습니다. 먼저 확인할 답 C# 제네릭 메서드는 동작은 같고 데이터 형식만 다른 코드를 한 번 작성하게 해줍니다. 호출 인수만으로 형식을 알 수 있으면 컴파일러가 T를 추론하고, 특정 기능이 필요한 형식만 받으려면 where 제약 조건을 붙이는 것이 핵심이에요. object 대신 형식 매개변수를 쓰는 이유 object 매개변수는 어떤 값이든 받을 수 있지만, 꺼낼 때 형식 변환이 필요하고 잘못된 변환은 실행 중에야 드러납니다. 제네릭 메서드는 호출 시점에 실제 형식을 정하므로 컴파일러가 입력과 반환 형식을 검사해요. 값 형식의 불필요한 박싱도 줄일 수 있습니다. 메서드 이름 뒤의 는 아직 정해지지 않은 형식 자리입니다. T value처럼 매개변수에 쓰거나 T를 반환 형식으로 사용할 수 있어요. 형식 매개변수 이름은 짧은 예제에서 T를 쓰지만 역할이 여러 개라면 TKey, TValue처럼 의미를 드러내는 이름이 낫습니다. 형식 인수는 생략할 수 있지만 언제나 가능한 것은 아니다 Print(10)을 호출하면 인수 10을 보고 T를 int로 추론합니다. 반면 반환값에만 T가 등장하고 입력 매개변수에는 단서가 없다면 컴파일러가 형식을 정할 수 없어요. 이때는 MethodName ()처럼 형식 인수를 직접 적어야 합니다. 추론은 반환받는 변수의 형식만 보고 결정되지 않습니다. 오버로드가 여러 개면 변환 규칙과 제약 조건까지 함께 작용하므로, 호출이 모호해졌다면 형식 인수를 명시하거나 메서드 이름과 매개변수 설계를 단순하게 바꾸세요. where 제약은 메서드 안에서 ...