try catch를 사용하는 n-layer

Question

나는 n-tier 응용 프로그램에서 작업 중이며 내 프레젠테이션 계층에서만 try/catch를 수행하고 있습니다. 데이터 계층이나 비즈니스 계층에서 오류가 발생하면이 오류는 내 프레젠테이션 계층의 try/catch에서 캡처됩니다. 이게 좋은가요, 아니면 각 레이어의 모든 메소드를 잡으려고 노력해야합니까?

Answer 1

당신은 모든 수준에서 피하고 싶은 내용은 다음과 같습니다 모두가 같이 방법의 무리 :

void method() 
{ 
    try 
    { 
     // some code here that may potentially throw an exception 
    } 
    catch (/* anything here */) 
    { 
     // code right here to handle that exception 
    } 
} 

그건 당신이있어 무엇 경우 VB에서 예전의 On Error Goto 시스템으로 돌아갈 수 있습니다. 아무 것도 얻지 못했기 때문입니다. 예외는 오류 처리에 두 가지 주요 이점을 제공합니다. 서로 다른 유형의 오류를 다양한 방식으로 쉽게 처리 할 수있는 기능과 오류가 프로그램의 호출 스택에서 더 많이 발견 될 수있는 기능입니다. 여기에서 두 번째 이점이 있습니다.

우리는 예외가있는 이유의 큰 부분이기 때문에 상위 레이어로 예외를 "버블 업 (bubble up)"하도록하고 싶습니다.하지만 항상 프리젠 테이션 레이어에서 예외를 처리하고 싶습니까? ? 아니, 더 잘할 수있어. 경우에 따라 데이터 영역의 특정 예외에 대응하는 방법에 대한 비즈니스 규칙이있을 수 있습니다. 때로는 데이터 레이어 자체가 그 위의 레이어에 경고하지 않고 예외를 처리하고 복구 할 수 있습니다.

반면에 예외의 장점은 오류 처리 코드에 대한 프로그램 실행의 정상적인 흐름에서 더 적은 수의 중단으로 더 낮은 계층에 간단한 코드를 작성할 수 있다는 것입니다. 이는 프레젠테이션 계층에 더 많은 try/catch를 배치하는 대신에 발생합니다. 다시 말하지만, 프레젠테이션 계층이 프레젠테이션 계층을 처리 할 수있는 유일한 곳이라는 의미는 아니지만 프레젠테이션 계층을 포착하지 못하도록하기위한 노력입니다. 다른 곳에서는 처리 할 수없는 경우 프레젠테이션 계층에서 해당 정보를 캐치하여 사용자에게 친숙한 방식으로 보여줄 수있는 방법이 필요합니다. 또한 동일한 메커니즘을 사용하여 예외를 기록하거나보고하면 응용 프로그램이 실패한 위치에 대한 좋은 측정 항목을 얻은 다음 해당 정보를 사용하여 응용 프로그램을 개선 할 수 있습니다.

마지막 도랑 예외 처리기 안에 있다는 점에 도달하면 응용 프로그램 종료를 고려할 수도 있습니다. 처리되지 않은 예외로 인해 프레젠테이션 계층을 통과하는 예기치 않은 일이 실제로 발생하는 경우 프로그램을 계속 실행하는 것이 좋지 않을 수 있음을 시사하는 올바른 생각이 있습니다. 그러나이 경우에도 예외를보고하고 가능한 한 정상적으로 충돌하려고합니다.

Answer 2

일반적으로 코드가 잠재적으로 문제를 수정/수정/대응할 수있는 곳에서 예외를 잡는 것이 좋습니다. 이 "무언가를"하는 것은 상황에 달려 있습니다. 예를 들어 실패한 서비스 계층 호출이있는 경우 서비스가 너무 바쁠 수 있으므로 호출을 다시 시도 할 수 있습니다. 반면에 스토어드 프로 시저가 손상된 경우 재 시도 횟수와 상관없이 데이터베이스에서 논리가 수정 될 때까지 손상됩니다.

로그 오류 만 남기고 싶다면 오류가 발생한 곳과 가까운 곳에서 오류를 잡는 것이 덜 유용합니다.

내가 작업 한 모든 프로젝트에는 응용 프로그램의 모든 레이어에 try-catch 개의 블록이있었습니다.

try-catch에 대한 추론 (읽기 : 시간, 일, 주, 월 또는 작업의 몇 년 후) 일반적으로 생산성 증가를 디버깅하는 시스템이 아니라, 즉시 천천히 실패에 실패 할 때 말한다 Fail Fast의 개념입니다. 위로 직선 캐스트는 다음과 같이 (int)를 사용하여 대

.NET Framework의 빠른 실패의 좋은 예 Convert.ToInt32()의 사용이다 : SomeSettingString은 다음 int 값으로 변환 할 수 있습니다

int? settingValue = Convert.ToInt32(SomeSettingString); 

if(settingValue == null) 
{ 
    // Do something here 
} 
else 
{ 
    // Do something else here 
} 

경우 로 설정되고 Do something else 논리가 실행됩니다. 지금부터 1 년 후에 설정이 바뀌고 변환이 실패하기 때문에 null이 반환됩니다. 갑자기 Do something here 로직이 실행되고 갑자기 발견 될 경우이 상태가 발생한다는 것을 알 수있는 디버깅 어드벤처입니다. 이와 같은 대부분의 문제는 DEV가 아닌 PRODUCTION에서만 발생하는 것으로 보입니다.

이제 같은 일을보고 있지만,이 같은 빠른 실패로하자 : 설정 문자열이 int 실패로 변환이 발생하는 즉시

이

try 
{ 
    int settingValue = (int)SomeSettingString; 
} 
catch(Exception ex) 
{ 
    // Fail fast and throw exception 
    throw new Exception("Fail fast"); 
} 

이제 예외가 발생합니다.

참고 : 예외가 "먹는"빈 블록 catch에 의해 실패 속도가 저하 될 수 있습니다. try 블록이 비어있는 경우 catch 블록은 피해야하며 예외적으로 "먹는"예외 시나리오가 발생합니다.

이 작업을 수행하지 마십시오

여기

try 
{ 
    // Exception waiting to happen here 
} 
catch(Exception ex) 
{ 
    // Catch-all, because all exceptions derive from Exception class 
    // So this will eat exceptions and pretend like they never happened 
}