예외가 발생할 때마다 스택 추적을 기록해야합니까?

거의 모든 로깅 구현에는 예외 스택 추적을 기록하는 기능이 있습니다.예외가 발생할 때마다 스택 추적을 기록해야합니까?

어떤 예외 (RuntimeException 포함)가있는 경우 스택 추적을 기록해야합니까? 또는 우리가 비즈니스 로직에 의존해야 하는가? 때로는 구성 문제를 나타 내기 위해 또는 다른 목적으로 예외가 발생하기 때문에?

출처

2014-05-21 Shinchan

e.getMessage()도 일부 힌트를 제공하며 전체 스택 추적을 인쇄 할 필요가 없습니다. 또한 개발자의 요구 사항 인 애플리케이션의 트래픽에 따라 다릅니다. –

맞습니다. 그러나 일부 응용 프로그램이 실행되고 있지 않으면 개발자가 스택 추적을 보는 데 사용된다는 철학이 있습니다. 실패의 배경에는 여러 가지 이유가있을 수 있습니다. Offcourse, 우리는 오류 메시지를 기록 할 수 있지만 stacktrace는 응용 프로그램 버그라고 보여줄 것입니다 ..... 이것에 대한 전문가의 견해가 필요합니다 : - $ !!!!!!!! – Shinchan

스택 추적을 로깅하는 것은 완벽하게 허용됩니다. 개발자가 문제를 더 빨리 디버그하는 데 도움이 될 수도 있습니다. 그러나, 매우 엄격하게 고려해야 할 몇 가지 문제가 있습니다.

중요
는 스택 추적에 민감한 세부 사항이 없는지 확인합니다. 예를 들어, 독점 라이브러리의 내부 세부 정보, 사용자 자격 증명 등은 로깅 전에 정리해야합니다.
사용 편의성의 관점에서 볼 때이 기록 된 오류가 실제 UI까지 표시되지 않도록하십시오. 대부분의 고객은 기술 기능 세부 사항의 큰 벽을 보지 않아도됩니다. 로그 파일 또는 오류 보고서의 "고급"섹션으로 제한하십시오.
로그 출력을 필터링하기 위해 로깅 수준을 사용하십시오. 이러한 스택 추적을 낮은 우선 순위 수준 (예 : LogLevel.DEBUG 또는 LogLevel.INFO)에 기록하십시오. 이러한 방식으로 세부 로깅을 쉽게 켜고 끌 수 있으며 로그 파일이 너무 빨리 채워지지 않도록 할 수 있습니다.

출처

2014-05-21 11:07:21 metacubed

"스택 추적 로깅을 완벽하게 수용 할 수 있습니다." 클라이언트가 로그 파일을보고 스택 추적을 찾으면 어떻게됩니까? 그들은 단지 UI 구성에 구성이 있어도 버그라고 가정합니다. 개발자가 로그를 쉽게 볼 수 있도록 도움이되는 것은 사실이지만, 개발 이 완료되면 모든 로그를 보려는 고객이됩니다. 그렇지 않니? – Shinchan

참고 사항 3. 대부분의 로깅 프레임 워크는 외부 적으로 로그 수준을 제어 할 수 있습니다. 정상적인 시나리오에서 로그 출력을 방지하려면이 옵션을 사용해야합니다. 그러나 코드는 여전히 필요할 때 켜지도록 로깅을 가져야합니다. – metacubed

네, 맞습니다 .... !!!! 동의 함 – Shinchan

예외가 발생할 때마다 스택 추적을 기록해야합니까?

답변

관련 문제