asp.net 개발에서 흔히 볼 수 있는 공공 포획 이상 방식 총결산(부원 코드)

본문의 실례는 asp.를 총결하였다.net 개발에서 흔히 볼 수 있는 공공 포획 이상 방식.여러분에게 참고하도록 공유하겠습니다. 구체적으로는 다음과 같습니다.
앞에서 말한 바와 같이 실제 개발 과정에서 한 응용 시스템에 있어 자신의 성숙한 이상 처리 구조를 가지고 이상이 발생할 때 통일된 처리 스타일을 얻어 이상 정보를 개발자와 사용자에게 우아하게 피드백해야 한다.우리 모두 알고 있는데..net의 이상 처리는'이상 체인'의 방식에 따라 밑바닥에서 고위층으로 층층이 던지는 것이다. 만약에 이상이 발생하는 경계를 가능한 한 빨리 판단하고 이상을 포획하지 못하면 CLR은 자동으로 우리를 도와 처리한다. 그러나 이런 시스템의 비용은 매우 크기 때문에 이상 처리의 중요한 원칙은'조기 발견 조기 던지기 조기 처리'이다.그러나 본고에서 정리한 서비스 측의 공공 포획 이상 처리는 표현층의 조작으로 광범위하게 볼 수 있고 특정한 층의 특정한 이상을 포획해야 하며 토론 범위에 있지 않다.
1. BasePage 클래스 처리 방식
페이지의 공통 기본 클래스에서 OnError 이벤트를 다시 작성합니다.앞의 에서 루저는 이미 코드를 붙여서 더 이상 힘들지 않게 되었다.경험에 따르면 많은 사람들이 개발할 때 거의 이렇게 쓰는데 디버깅과 유지보수에 도움이 된다.설명이 필요한 것은 페이지가 새로 추가될 때마다 해당 클래스는 BasePage 클래스 예외 처리를 계승해야 작동합니다.
2、Global.asax 처리 방법
1에서 말한 바와 같이 BasePage 클래스의 이상 처리는 모든 aspx 클래스 파일을 계승해야 하기 때문에 적용성과 성능이 분명히 떨어질 것이다.글로벌.asax 파일은 asp.를 정의합니다.net 응용 프로그램의 모든 응용 프로그램 대상이 공유하는 방법, 속성, 이벤트는 BasePage 처리 방식을 사용하지 않고 Global에서 처리할 수 있습니다.asax에서 Application 구현Error 이벤트를 처리하고 처리할 수도 있습니다.다음은 BasePage 클래스의 예외 처리 방법을 본떠서 다음과 같이 수행합니다.

/// 

///     :   ,         
/// 
/// 
/// 
protected void Application_Error(object sender, EventArgs e)
{
  if (Server.GetLastError() == null) return;
  Exception ex = Server.GetLastError().GetBaseException();
  string error = this.DealException(ex);
  DotNet.Common.Util.Logger.WriteFileLog(error, HttpContext.Current.Request.PhysicalApplicationPath + "LogFile");
  if (ex.InnerException != null)
  {
    error = this.DealException(ex);
    DotNet.Common.Util.Logger.WriteFileLog(error, HttpContext.Current.Request.PhysicalApplicationPath + "LogFile");
  }
  this.Server.ClearError();
  this.Response.Redirect("/Error.aspx");
}
/// 

///     ，               
/// 
/// 
/// 
private string DealException(Exception ex)
{
  this.Application["StackTrace"] = ex.StackTrace;
  this.Application["MessageError"] = ex.Message;
  this.Application["SourceError"] = ex.Source;
  this.Application["TargetSite"] = ex.TargetSite.ToString();
  string error = string.Format("URl：{0}
       ：{1}
    ：{2}
    ：{3}
",
    this.Request.RawUrl, ex.TargetSite, ex.Message, ex.StackTrace);
  return error;
}

위의 방식의 장점은 코드를 한 번 쓰면 응용 프로그램에서 발생하는 대부분의 이상을 포착하여 처리한다는 것이다.루저는 이곳에서 진심으로 감개무량함을 표합니다. ms가 우리에게 이렇게 우수한 틀을 제공해 주셔서 감사합니다. 너무 편리하죠.
3. IHttpModule 인터페이스 처리
1과 2의 처리 방식은 모두가 매우 익숙하다. 루저는 실제 개발에서 기본적으로 위의 두 가지 묘사법을 따랐다. 그리고 루저는 2의 이런 크기로 통식하는 처리 방식이 생겨서 심지어 ms에게 감동적으로 감사를 표했다.하지만, asp.net 프로그램이 스레드를 호출하여 비동기 처리를 할 때 백엔드 스레드나 스레드 탱크에서 쉽게 발생하는 이상이 1 또는 (과)2에 완전히 포착되지 않습니다. 이것은 asp.net에서 이상 처리가 포착되지 않았습니다.즉, 루저가 이전에 했던 많은 크기 항목 중 이상 처리가 완비되지 않았다는 것이다.이것은 설마 nc루 돼지가 국가가 심은 악과에 먼저 감사하지 않은 것입니까?국가 감사, ms 감사, 블로그 감사, 사심 없는 xdjm 감사, 자신 감사...
asp.net에서 예외가 발견되지 않은 처리 단계는 다음과 같습니다.
(1) IHttpModule 인터페이스를 구현하는 클래스 만들기

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Text;
namespace DotNet.Common.WebForm
{
  using DotNet.Common.Util;
  /// 

  ///           
  /// 
  public class AspNetUnhandledExceptionModule : IHttpModule
  {
    static object syncObj = new object();
    static bool isInit = false;
    public AspNetUnhandledExceptionModule()
    {
    }
    #region IHttpModule Methods
    public void Init(HttpApplication context)
    {
      lock (syncObj)
      {
        if (!isInit)
        {
          AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(OnUnhandledException);
          isInit = true;
        }
      }
    }
    public void Dispose()
    {
    }
    #endregion
    #region OnUnhandledException
    void OnUnhandledException(object o, UnhandledExceptionEventArgs e)
    {
      if (e.ExceptionObject == null) return;
      Exception ex = e.ExceptionObject as Exception;
      string error = string.Format("       ：{0}
    ：{1}
    ：{2}
",
              ex.TargetSite, ex.Message, ex.StackTrace);
      Logger.WriteFileLog(error, AppDomain.CurrentDomain.BaseDirectory + "LogFile");
    }
    #endregion
  }
}

(2)、web.config 노드 구성

마지막으로 테스트 코드를 붙여 넣습니다.

protected void Page_Load(object sender, EventArgs e)
{
  if (!IsPostBack)
  {
    System.Threading.ThreadPool.QueueUserWorkItem(new System.Threading.WaitCallback(Test), null);
  }
}
protected void Test(object state)
{
  int[] numArr = new int[100];
  numArr[100] = 100; //  
}

설명이 필요한 것은 스레드나 스레드 탱크를 통해 처리하는 프로그램은 이상이 발생할 때 모든 스레드는 자신의 독립된 상하문이 있기 때문에 HttpContext 대상은 가능한 한 이상 처리 단계에 적게 나타나야 한다.
매듭: 이상 처리가 코드에 있다고 생각하는 구두가 얼마나 많은지...catch, 이상을 던지고 끝낼까?만약에 있었다면 허허, 그 당시 누각돼지는'천성적으로 완전무결한 사람은 없다'는 말로 자신을 위로했다.당연하지,try...catch도 안 되는 것은 아니다. 우리가 이상을 대하는 태도가 너무 경솔하다는 것을 설명할 뿐이다.우리의 전공과 전면적인 모습을 보이기 위해 다른 이상처리 전문성 문장을 참고하여 한 번 연구해 보십시오. 이상처리의 핵심 사상(이상처리의'대지혜')에 비해 이 문장이 정리한 (이상처리의'작은 기교')는 초보자들에게도 오도작일 수 있으니 반드시 유의하여 선별해 주십시오.
온전한 실례 코드 코드는 여기를 클릭하여 본 사이트에서 다운로드하십시오.
본문에서 서술한 바와 같이 여러분의 asp.net 프로그램 설계에 도움이 되었습니다.