웹 애플리케이션의 경우 오류는 불가피하므로 예방 조치를 취하고 발생할 수 있는 오류에 대해 적절한 처리를 제공해야 합니다. 실제로, 좋은 오류 처리 메커니즘은 웹 애플리케이션의 품질을 측정하는 중요한 기준입니다. 사용자가 실수로 브라우저에 잘못된 URL을 입력했거나 사용자가 프로그램 오류를 일으키는 일부 정보를 제공했을 때 이러한 상황을 처리하지 않으면 404 또는 500 오류 페이지 또는 심지어 오류까지 허용합니다. 사용자 앞에 표시되므로 의심할 여지 없이 일부 사용자는 겁을 먹게 됩니다. 따라서 웹 애플리케이션을 개발할 때 오류 처리 메커니즘을 완전히 이해해야 합니다.
ASP.NET으로 돌아가서 모두가 생각해 볼 수 있는 두 가지 질문을 해보겠습니다. ASP.NET은 몇 가지 오류 처리 메커니즘을 제공합니까? 여러 오류 처리 메커니즘을 동시에 사용하는 경우 이들 사이에 특정 우선순위가 있습니까?
<?xml version="1.0"?>
을 먼저 살펴보겠습니다
.
<구성>
<시스템.웹>
<customErrors mode="On" defaultRedirect="GenericErrorPage.htm">
<error statusCode="403"redirect="Error403.htm" />
<error statusCode="404"redirect="Error404.htm" />
</customErrors>
</system.web>
</구성>
<customErrors> 설정 항목에 대해서는 더 이상 말씀드릴 필요가 없을 것 같습니다. 자세한 내용은 MSDN을 참고하시기 바랍니다. 첫 번째 오류 처리 메커니즘 - Web.Config의 <customErrors> 구성 항목을 사용하는 것이 가장 일반적으로 사용되는 메커니즘입니다.
다음으로, 매우 일반적으로 사용되는 또 다른 파일인 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 이벤트 처리 방법과 매우 유사합니다. 발동되는 시점이 다릅니다. 다음은 두 가지 구체적인 예입니다.
<script 언어="C#" runat="server">
protected void Page_Load(객체 전송자, EventArgs e) {
this.ErrorPage = "ErrorPage.htm";
}
</script>
protected void Page_Error(객체 전송자, EventArgs e) {
예외 objErr = Server.GetLastError().GetBaseException();
Response.Write("오류:" + objErr.Message);
Server.ClearError(); //이 코드 사용에도 주의하세요.
}
이제 네 가지 오류 처리 메커니즘이 모두 나타났으며 이제 순위를 매길 차례입니다. 높은 우선순위에서 낮은 순으로 정렬: Page_Error 이벤트 처리 방법 > ErrorPage 속성 > Application_Error 이벤트 처리 방법 > <customErrors> 구성 항목. 순위는 이렇지만 순위 간에는 미묘한 관계가 존재합니다. 먼저 ErrorPage 속성이 작동하려면 <customErrors> 구성 항목의 모드 속성을 "On"으로 설정해야 합니다. 그러나 Server.ClearError() 메서드가 다음과 같은 경우 Page_Error 이벤트 처리 메서드가 먼저 순위가 지정됩니다. 누락된 경우 우선순위가 낮은 오류 처리가 계속 트리거됩니다. 이는 Application_Error 이벤트 처리 방법에도 해당됩니다. 순서는 정해져 있지만 순서가 가장 중요한 문제는 아니기 때문에 이 4가지 처리 메커니즘을 혼합하지 못하는 경우가 많기 때문에 큰 의미가 없는 문제라고도 할 수 있습니다. 가장 중요한 문제는 이러한 오류 처리 메커니즘을 선택하는 방법이라고 생각합니다. 이 문제에 대해서는 경험이 많은 친구들이 의견을 공유할 수 있기를 바랍니다.
자, 이제 ASP.NET의 네 가지 오류 처리 메커니즘을 소개하고 내 느낌에 대해 이야기할 차례입니다. ASP.NET의 설계자들은 실제로 개발자의 관점에서 철저한 고려를 하여 우리가 선택할 수 있는 오류 처리 메커니즘을 최대 4개나 제공하고 있는데 이는 칭찬할 만한 일입니다. 그러나 광고 슬로건을 바꿔 말하면 너무 많으면 혼란스럽습니다. 또한 너무 많은 오류 처리 메커니즘으로 인해 약간 어지러울 수도 있습니다. J2EE 분야의 오류 처리를 비교해 보면 비교적 간단하다는 것을 알 수 있습니다. 첫 번째는 <customErrors>에 해당하는 설정입니다. J2EE 프로젝트에서 가장 일반적으로 사용되는 web.xml 파일에서도 유사한 구성 항목을 찾을 수 있습니다. 두 번째로 J2EE 분야에서 페이지는 중요한 엔터티가 아니며 이벤트 드라이버 모델이 필요하지 않기 때문에 Application_Error 및 Page_Error 메소드에 해당하는 처리 메커니즘을 실제로 찾을 수 없습니다. 마지막으로 J2EE 분야에서는 일단 논리적 처리에서 오류가 발생하면 요청 및 응답이 더 강조됩니다. , RequestDispatcher를 통해 해당 오류 처리 모듈에 요청을 쉽게 배포할 수 있습니다. 실제로 이는 매우 유연한 처리 방법입니다. 관심 있는 친구는 이에 대해 배우고 싶어할 수도 있습니다.