웹 애플리케이션의 경우 오류는 불가피하므로 예방 조치를 취하고 발생할 수 있는 오류에 대해 적절한 처리를 제공해야 합니다. 실제로, 좋은 오류 처리 메커니즘은 웹 애플리케이션의 품질을 측정하는 중요한 기준입니다. 사용자가 실수로 브라우저에 잘못된 URL을 입력했거나 사용자가 프로그램 오류를 일으키는 일부 정보를 제공했을 때 이러한 상황을 처리하지 않으면 404 또는 500 오류 페이지 또는 심지어 오류까지 허용합니다. 사용자 앞에 표시되므로 의심할 여지 없이 일부 사용자는 겁을 먹게 됩니다. 따라서 웹 애플리케이션을 개발할 때 오류 처리 메커니즘을 완전히 이해해야 합니다.
ASP.NET으로 돌아가서 모두가 생각해 볼 수 있는 두 가지 질문을 해보겠습니다. ASP.NET은 몇 가지 오류 처리 메커니즘을 제공합니까? 여러 오류 처리 메커니즘을 동시에 사용하는 경우 이들 사이에 특정 우선순위가 있습니까?
을 먼저 살펴보겠습니다
.
<구성>
<시스템.웹>
다음으로, 매우 일반적으로 사용되는 또 다른 파일인 Global.asax를 살펴보겠습니다. 이 문서를 언급하면 어떤 생각이 드시나요? 예, 두 가지 주요 웹 애플리케이션 개체(애플리케이션 및 세션)와 관련된 이벤트입니다. 이러한 이벤트 중에는 Application 카테고리 - Error에 속하는 오류 관련 이벤트가 있으며 해당 이벤트 처리 방법은 Application_Error입니다. 이름에서 알 수 있듯이 이 이벤트 처리 메서드는 애플리케이션 수준 오류가 발생할 때 호출되므로 아래와 같이 이 메서드에 코드를 추가하여 오류를 처리할 수 있습니다.
protected void Application_Error(object sender, EventArgs e) {
예외 objErr = Server.GetLastError().GetBaseException();
Response.Write("오류:" + objErr.Message);
서버.ClearError();
}
여기서 모두가 코드 마지막 줄에서 Server.ClearError() 사용에 주의해야 합니다. 왜 이 코드 줄을 사용해야 합니까? 사용하지 않으면 어떻게 되나요? 여기서 다시 한번 시도해 보겠습니다. 음, 두 번째 오류 처리 메커니즘인 Global.asax의 Application_Error 이벤트 처리 방법도 첫선을 보였습니다.
위의 두 가지 오류 처리 방법은 전역적이라고 할 수 있습니다. 하나는 응용 프로그램 구성 파일에서 파생되고, 다른 하나는 응용 프로그램 루트 디렉터리에 배치되어야 하는 Global.asax 파일의 이벤트 처리 방법입니다. 전역의 반대는 로컬이므로 자연스럽게 궁금해집니다. 로컬(특정 페이지)에 적용되는 오류 처리 메커니즘이 있습니까? 대답은 "예"입니다. ErrorPage 특성을 사용하는 방법과 Page_Error 이벤트 처리 방법을 사용하는 방법이 있습니다. 첫 번째 메커니즘의 경우 거의 언제든지 ErrorPage 속성을 설정하여 페이지에 오류가 발생할 때 리디렉션될 페이지를 결정할 수 있습니다. 두 번째 메커니즘의 경우 이는 다음을 제외하고 Application_Error 이벤트 처리 방법과 매우 유사합니다. 발동되는 시점이 다릅니다. 다음은 두 가지 구체적인 예입니다.
protected void Page_Error(객체 전송자, EventArgs e) {
예외 objErr = Server.GetLastError().GetBaseException();
Response.Write("오류:" + objErr.Message);
Server.ClearError(); //이 코드 사용에도 주의하세요.
}
이제 네 가지 오류 처리 메커니즘이 모두 나타났으며 이제 순위를 매길 차례입니다. 높은 우선순위에서 낮은 순으로 정렬: Page_Error 이벤트 처리 방법 > ErrorPage 속성 > Application_Error 이벤트 처리 방법 >
자, 이제 ASP.NET의 네 가지 오류 처리 메커니즘을 소개하고 내 느낌에 대해 이야기할 차례입니다. ASP.NET의 설계자들은 실제로 개발자의 관점에서 철저한 고려를 하여 우리가 선택할 수 있는 오류 처리 메커니즘을 최대 4개나 제공하고 있는데 이는 칭찬할 만한 일입니다. 그러나 광고 슬로건을 바꿔 말하면 너무 많으면 혼란스럽습니다. 또한 너무 많은 오류 처리 메커니즘으로 인해 약간 어지러울 수도 있습니다. J2EE 분야의 오류 처리를 비교해 보면 비교적 간단하다는 것을 알 수 있습니다. 첫 번째는