2009-11-18 7 views
0

웹 응용 프로그램에서 처리되지 않은 예외를 처리 할 수있는 코드가 있습니다. 세부 정보를 기록하는 고급 사용자 정의 오류 페이지로 넘어갑니다. 그러나 사용자 정의 오류 페이지 내에 처리되지 않은 예외가있는 경우에는 어떻게해야합니까?예외 처리 코드에서 예외를 처리하는 방법은 무엇입니까?

일반적인 예외 처리기에서 Request.CurrentExecutionFilePath이 내 사용자 정의 오류 페이지와 동일한 지 확인하여 루프를 피할 수있는 조치를 취할 수 있습니다. 그러나 이러한 단계가 수행해야하는 아이디어는 - 죽음의 노란색 화면으로 돌아가서 정적 사용자 정의 오류 페이지로 넘어가십시오.

아니면 그냥 내 맞춤 오류 페이지 코드를 try {...} catch {}에 넣고 걱정하지 않으셔도됩니다.

+0

예외 로깅 코드 자체는 빈 catch 블록 { // 여기 아무것도하지 않고} 시도 { } 캐치 (예외 예)에 넣어해야합니다. 때때로 예외 로깅 코드에서 "미친 문제"가 발생할 수 있습니다. – PRR

답변

0

try {...} catch {doSomethingThatCannotPossiblyFail()} 구문에 사용자 정의 오류 코드 페이지를 래핑하십시오.

+0

나중에 누군가가 따라 와서 파일의 모든 주석을 무시하고 catch {...} 블록이나 try {...} catch {...} 외부에서 예외를 throw 할 수있는 코드를 추가한다고 가정합니다. 어쩌면 나는이 가능성에 대해 방어하기에는 너무 멀어지고있다. – noj

+0

이 접근법의 문제점은 예외가 지금까지 (예 : 500 페이지) 다음에 가능한 것으로 생각되는 경우, 이 단계에서 예외를 삼키는 것은 결코 좋은 생각이 아닙니다. 그 이상은 원정대를 기록하는 것보다 커스텀 500 페이지의 실패를 사용자에게 알려주는 것보다 – Sheff

+0

jdt199 : 그 이유는 catch 블록이 내 대답에서 비어 있지 않은 이유입니다 .-) 완전히 삼키는 것은 나쁜 생각입니다. –

2

.net 사용자 정의 오류 프레임 워크를 사용하고 정적 HTML 파일을 500 오류의 대상으로 설정합니다. 커스텀 500 페이지를 갖는 나쁜 생각은 이미 io 명령이 실패했을 (데이터베이스 또는 파일 액세스와 같은) 실패 할 수있는 일을합니다.

사용자 정의 500 페이지를 단순 html 파일로 유지하고 응용 프로그램 global.asax의 Application_Error 이벤트를 통해 모든 예외 로깅을 수행하는 것이 좋습니다. 예외가 throw되도록 허용 한 다음 .net 사용자 정의 예외 처리기를 사용하여 사용자 정의 페이지.

편집 : 여기에 설명 된 패턴과 관련된 기사가 있습니다. 유일한 차이점을 참고 내가 모든 로깅 메커니즘의 변동성에 따라 달라 솔직히 정적 HTML 500 페이지를

http://devhood.com/tutorials/tutorial_details.aspx?tutorial_id=237

0

를 사용하는 방법과 심하게 각 오류를 기록 할 것입니다. 프로그램이 작동하는 외부 (예 : 데이터베이스 사용 가능, 로그 파일에 대한 액세스 권한, 이벤트 로그가 가득 참 없음 등)에 기반하기 때문에 로깅이 실패 할 가능성이 항상 있습니다. 사용자에게 엄청난 불쾌한 오류를 표시하는 것을 막을 다른 이유가 없다면 try catch 블록에 로깅해야합니다.

개인적으로 저는 여러 로깅 경로를 사용합니다. 아마도 첫 번째 데이터베이스 (비록 개인적으로 DB에 로깅 오류가 마음에 들지 않지만 로그 파일을 선호합니다) 및 이벤트 로그에 두 번째로 뭔가 잘못되었다는 내용의 전자 메일을 보내려합니다. 외부 소스에 대한 내 로깅이 절대 실패하지 않는다고 말하는 확실한 방법은 없지만 그 가능성을 최소화하고 최종 사용자가 어떤 일이 발생하더라도 치명적인 오류가 발생하지 않았는지 확인하십시오.

관련 문제