2010-03-19 4 views
1

그래서 우리는 정말로 불안정한 서버와 통신하는이 제품을 개발 한 몇 명의 사람들입니다. 종종 매우 이상하고 손상된 데이터를 반환합니다. 테스트하는 동안 발생하는 크래시를 크게하기를 원합니다. 그러나 격일로 우리는 잠재 고객을 위해 제품을 시연해야합니다. 고객에게 우리가 단지 그들을 삼키면 오류는 알려지지 않을 것입니다. 나는 빨리 예외를 삼키는과 충돌 사이를 전환하기 위해 주위의 모든 서버 통신 같은 것을 구현에 대해 생각하고 :정적 부울에 의해 예외가 삼키는 경우를 제어

try { 
    apiCall(); 
} catch (Exception e) { 
    if(!SWALLOW_EXCEPTION) { 
     throw e; 
    } 
} 

이는 멋진 아이디어인가, 또는 그것은 더 나은 방법으로 할 수 있는가?

+6

비 윤리적 태그가 있습니까? –

+0

두 번째 try/catch 블록은 무의미합니다. 그냥'e.printStackTrace()'를 직접 호출 할 수 있습니다. –

+0

지금 있습니다. :-) –

답변

6

SLF4J, java.util.logging 또는 Log4j과 같은 로거 사용을 권장합니다. '디버깅 중'이지만 여전히 추적하려는 로그 메시지의 심각도에 따라 DEBUG, INFO 또는 WARN 수준을 설정할 수 있습니다. '오류'수준으로 저장할 수있는 실제 오류.

고객에게 데모를 할 때 로그 수준을 오류로 설정하면 모든 것이 표시되지 않습니다. 정상적으로 실행 중일 때 필요한 로깅 수준을 캡처 할 수있는 수준으로 설정하십시오.

삼키는 예외는 결코 좋은 습관이 아닙니다. 로거를 사용하면 너무 많은 세부 사항을 제공 할 경우 로거를 숨길 수 있습니다. 다시 컴파일하지 않고도 필요할 경우 언제든지 액세스 할 수 있습니다.

+0

고마워, 나는 이것을 시험해 보겠다. – pgsandstrom

2

이것은 좋지 않습니다. 최상위 레벨을 구현하는 것은 어떨까요?

0

코드를 만들려고 했습니까?

try { 
     apiCall(); 
    } catch (Exception e) { 
     if(!SWALLOW_EXCEPTION) { 
     throw e; 
     } else { 
     e.printStackTrace(); 
     } 
    } 

그렇다면 문제는이 API가 호출되는 유일한 장소 인 경우, 그만큼 당신이 생각하는대로 변경 사항을 적용하려면 다시 컴파일해야합니다, 나에게 좋아 보인다. 당신은 로깅 프레임 워크가이 같은 재 컴파일없이 끝내야 남용 수 :

if (logger.isInfoEnabled()) { 
     throw e; 
    } else { 
     logger.error(e.getMessage(), e); 
    } 

하지만 이러한 코드 조각을 찾는 대부분의 사람들은 매우 당황 할 거라고 생각해. 재 컴파일을 피하려면 System 속성을 사용하십시오.

if (Boolean.getBoolean("development")) { 
     throw e; 
} else { 
     e.printStackTrace();//you should really use a logging framework anyway and not this. 
} 
관련 문제