2012-03-20 3 views
2

저는 ASP.NET 웹 응용 프로그램을 만들고 있습니다. 전체 응용 프로그램에 대한 로깅 프레임 워크를 구현하고 있습니다.ASP.NET 일반적인 오류 페이지 유용한 정보

웹 응용 프로그램은 약 7-8 페이지가 있으며 간단한 CRUD 작업 웹 응용 프로그램입니다.

Azure에서 호스팅하는 응용 프로그램입니다. 다음은 로깅 및 예외 처리를 위해 내가 따르는 접근법입니다.

1) Try ... Data Access Layer 및 Click 이벤트에 블록 잡기를 추가했습니다.

2) 오류가 발생하면 Globabl.asax 레벨까지 예외를 전파하고 Application_Error 이벤트에서 오류를 이벤트 로그 및 추적 로그에 기록합니다.

3)이 후 Global.asax 파일에서 오류 페이지로 이동하여 사용자에게 친숙한 메시지를 표시하고 실패한 페이지에 연결합니다.

4) 이렇게하는 것이 좋은 방법인지 여부를 알고 싶었습니다.

감사합니다.

답변

0

왜 ASP.NET 사용자 정의 오류 페이지를 사용하지 않습니까? 각 상태 코드에 대해 각 오류 페이지를 지정하거나 기본 리디렉션을 지정할 수 있습니다.

웹 구성에서이를 구성 할 수 있으며 모두 설정됩니다.

<customErrors defaultRedirect="GenericError.htm" mode="On"> 
      <error statusCode="404" redirect="notfound.htm"/> 
</customErrors> 

당신은 모든 사용자에게 또는 단지 등 원격 사용자에게 사용자 지정 오류 페이지를 보여주는 구성 할 수 있습니다 ..

http://aspnetresources.com/articles/CustomErrorPages

나는 완전히 당신이 당신의 catch 블록에있는 모든 오류를 기록한다 동의 그것을 로그에 기록하십시오.

1

실제로 DAL에서 예외를 처리하고 있습니까 (예 : 로깅, 수정 시도 등)? 그렇지 않다면 try catch는 회전주기 이외의 다른 용도로 사용되지 않습니다. 클릭 이벤트에 대해서도 마찬가지입니다. 사용자가 추악한 오류 페이지에서 자신의 친숙한 메시지로 전환하기 때문에 진정으로 아무것도하지 않더라도 UI에서 오류를 처리하는 것은 나쁜 습관은 아닙니다 .

실제로 발생한 예외를 처리 할 수없는 경우 단일 오류 페이지가 제대로 작동합니다. 사용자가보기 흉한 메시지를 보지 않도록 소중한 작은 코드를 작성하면 시간이 절약됩니다. 단점은 사용자가 컨텍스트를 놓친다는 것입니다. 난 정말 하나의 크기에 백업을 제외하고 모든 예외 처리기에 맞는 아니에요 (나는 내 ​​첫 번째 라인 처리기 과거있어 상상하지 못한 오류가).

HTTP 상태를 기반으로 처리하고 config를 사용하는 경우 일반적인 오류 페이지가 변형됩니다.

또 다른 패턴은 사용자 자신의 기본 페이지를 설정하고 오류 처리기로 작동하도록하는 것입니다. 그런 다음 오류가 발생할 때 채울 컨테이너를 따로 설정할 수 있습니다. 이 접근법은 사용자가 계속 페이지의 일부를 보았으므로 오류 메시지를 표시하므로 상황이 잘못되었다는 것을 알기 때문에 컨텍스트를 추가 할 때 적합합니다. 이 패턴은 오류가 발생했을 때 컨테이너에 추가 된 사용자 정의 컨트롤과 함께 사용되지만이 코드는 표시 할 코드 테이블과 적절한 메시지를 설정해야하므로 조금 더 많이 호출됩니다 (버그가있을 수 있음). 그리고 그 자체의).

0

휠을 재발 명한 듯합니다. ASP.NET에는 이미 원하는 결과를 얻는 데 도움이되는 것들이 포함되어 있습니다. 오류가 발생하여 정리 작업을 수행 할 논리가 필요하지 않다면 try catch 블록을 사용하지 않을 것입니다. 로깅 오류에 대해서는 ASP.NET Health Monitoring Overview을보십시오. 사용자 정의 오류 페이지를 표시하는 한 How to create custom error reporting pages in ASP.NET by using Visual C# .NET을 참조하십시오.

+0

아니, 노력 아니라고하지만 단지 예를 들어 DB 연결이 시간 초과되는 경우에는 내가하지 않으면, 모든 표준 400 + 내가 ASP.NET 사용자 지정 오류 페이지를 사용하고 500 오류 데이터 액세스 레이어에서 CATCH를 시도해보십시오. 거기에서 흥분이 일어나는 것을 어떻게 알 수 있습니까? – sqlnewbie

+0

그래서 DBException 같은 사용자 지정 예외를 구현하고 Global.asax 수준까지 똑같이 던져서 유형에 따라 사용자에게 서버의 DB 연결에 대한 몇 가지 문제를 말하는 메시지를 표시합니다. 관리자에게 알려주십시오. Click 이벤트에 문제가있는 경우 입력에 문제가 있습니다. 다시 시도하거나 관리자에게 문의하십시오. 좋은 접근 방법입니까? – sqlnewbie

+0

사용자 지정 예외에서 예외를 래핑하는 것은 예외에 대한 추가 정보를 전달할 때 완벽하게 수용 할 수있는 방법입니다. 그러나 사용자는 왜 실패했는지 알 필요가 없으며이를 전달할 것으로 예상해서는 안됩니다. 사용자를 직접 다뤘다면 항상 메시지가 어쨌든 말한 것을 잊어 버리는 것입니다. 그래서 표준 오류 페이지 및 상태 모니터링을 제안합니다. 오류 세부 사항을 기록하도록 상태 모니터링을 구성 할 수 있습니다. 또한 예외가 발생할 때 전자 메일을 보내도록 상태 모니터링을 구성 할 수 있습니다.이 기능을 사용하면 전자 메일을보다 신속하게 처리 할 수 ​​있습니다. – JamieSee

0

나는 예외 처리를 사용할 필요가 없다고 생각합니다. 프레젠테이션 계층과 비즈니스 로직 계층/DataAccess 계층이 있다고 가정합니다.

비즈니스 로직에서 오류가 발생하면 호출 기능으로 돌아 가지 않고 Application_Error 이벤트 아래의 Glogal.asax.cs 파일로 직접 이동합니다. 여기


HttpContext.Current.Server.GetLastError().InnerException.StackTrace 
HttpContext.Current.Server.GetLastError().InnerException.Message 
HttpContext.Current.Server.GetLastError().InnerException.Source 
HttpContext.Current.Server.GetLastError().InnerException.TargetSite.DeclaringType.FullName 
HttpContext.Current.Server.GetLastError().InnerException.TargetSite.DeclaringType.Name 
HttpContext.Current.Server.GetLastError().InnerException.TargetSite.DeclaringType.Namespace 

이제 웹 구성에 당신은 아래와 같은 몇 가지 기본 페이지에 사용자를 리디렉션하는 코드를 작성할 수 있습니다 .... 아래와 같은 오류 메시지를 기록 할 수 있습니다.

<customErrors defaultRedirect="ErrorPage.htm" mode="On"> 
    <error statusCode="404" redirect="ErrorPageNotFound.htm"/> 
</customErrors> 
관련 문제