-1

시작시 초기화 된 ThreadException 핸들러가있는 매우 큰 복잡한 응용 프로그램이 있으며 즉시 처리되지 않는 응용 프로그램에 의해 던져진 예외는이 ThreadException 핸들러에 의해 통합 방식으로 처리됩니다.Application.ThreadException이 올바르지 않습니다. Win32Exception 유형

대부분이 작동하지만 우리는이 예외 핸들러로 처리하기를 원하는 몇 가지 사용자 정의 예외 유형이 있으며 어떤 이유로 이러한 예외 유형이 항상 System.ComponentModel.Win32Exception 유형으로 ThreadException 핸들러에 표시됩니다 , 대신 사용자 정의 유형.

나는 우리의 맞춤 예외 클래스가 serialization 생성자를 포함한 모든 권장 생성자를 구현하는지 확인하는 것을 포함하여 문제를 해결하기 위해 생각한 모든 것을 시도했다.

추가 정보 ... 기존 예외의 메시지만으로 새 예외를 만들면 System.Exception이 발생합니다. 예를 들어 :

   MSCSqlException msx = new MSCSqlException(sqlQuery, sqlParams, sqlException); 
       throw new Exception(ex.Message); 

잘 작동하고 System.Exception 같은 예외 처리기에 걸려있다. 내가 좋아하는 뭔가를하려고하면

그러나 :

   MSCSqlException msx = new MSCSqlException(sqlQuery, sqlParams, sqlException); 
       throw new Exception(ex.Message, ex); 

을 다음 예외 관리자 대신 단지 System.Exception의 위 System.ComponentModel.Win32Exception을 잡는다. 그냥 완전성에 대한

는, 내가하고 싶은 같은 것입니다 :

   throw new MSCSqlException(sqlQuery, sqlParams, sqlException); 

을하고 Application.ThreadException 핸들러가 제대로 입력 MSCSqlException를받을 수 있습니다.

아이디어를 얻는 방법에 대한 아이디어가 있으십니까? Application.ThreadException의 일부 변종이 사용자 정의 오류 유형과 관련이 없습니까?

우리의 사용자 정의 예외 클래스 : 우리는 마침내 알아 낸

[Serializable] 
public class MSCSqlException : Exception 
{ 
    public string SqlCommand { get; private set; } 
    public object[] SqlParameters { get; private set; } 

    public MSCSqlException() 
    { 
    } 

    public MSCSqlException(string message) 
     : base(message) 
    { 
    } 

    public MSCSqlException(string message, Exception inner) : base(message, inner) 
    { 
    } 

    public MSCSqlException(string command, object[] parameters, SqlException sx) : base(CreateUsefulMessage(sx, command, parameters), sx) 
    { 
     SqlCommand = command; 
     SqlParameters = parameters; 
    } 

    protected MSCSqlException(SerializationInfo info, StreamingContext context) : base(info, context) 
    { 
     SqlCommand = info.GetString("SqlCommand"); 
    } 

    [SecurityPermission(SecurityAction.Demand, SerializationFormatter = true)] 
    public override void GetObjectData(SerializationInfo info, StreamingContext context) 
    { 
     if (info == null) 
     { 
      throw new ArgumentNullException("info"); 
     } 

     info.AddValue("SqlCommand", SqlCommand); 
     base.GetObjectData(info, context); 
    } 

    public static string CreateUsefulMessage(SqlException sx, string sqlCommand, object[] sqlParameters) 
    { 
     string message = sx.Message + Environment.NewLine; 

     if(sqlParameters != null && sqlParameters.Count() > 0) 
     { 
      message = message + "Parameters:" + Environment.NewLine; 
      foreach(object sp in sqlParameters) 
      { 
       message = message + "\t" + sp.ToString() + Environment.NewLine; 
      } 
     } 

     message = message + "SQL Statement:" + Environment.NewLine; 
     message = message + sqlCommand; 

     return message; 
    } 
} 

답변

0

는 ... 문제는 닷넷은 백그라운드 작업자 완료 이벤트에 던져 예외를 처리하는 방법에 버그 나 기능입니다. 어떤 이유로 든이 경우 .NET 실행 시간이 스택 추적의 가장 안쪽 예외를 예상 된 가장 바깥 쪽 예외 대신 ThreadException 처리기로 전달하는 것으로 나타납니다. SQLException이 throw 될 때이 가장 안쪽 예외는 Win32Exception입니다. 이 여기에

상세 정보 :

Application.ThreadException is getting incorrect Win32Exception type

관련 문제