-1

Wir haben eine sehr große komplizierte Anwendung, die einen ThreadException-Handler beim Start initialisiert hat, und Ausnahmen von der Anwendung, die nicht sofort behandelt werden, werden von diesem ThreadException-Handler in einheitlicher Weise behandelt.Application.ThreadException wird falsch Win32Exception-Typ

Das funktioniert meistens ... aber wir haben einige benutzerdefinierte Ausnahmetypen, die wir mit diesem Ausnahmebehandler behandeln möchten, und aus irgendeinem Grund werden diese Ausnahmetypen im ThreadException-Handler immer nur als System.ComponentModel.Win32Exception-Typen angezeigt , anstelle unserer benutzerdefinierten Typen.

Ich habe alles versucht, was mir bei der Fehlersuche in den Sinn kommt. Dazu gehört auch, dass unsere benutzerdefinierten Ausnahmeklassen alle empfohlenen Konstruktoren implementieren, einschließlich eines Serialisierungskonstruktors.

Zusätzliche Informationen ... Wenn ich eine neue Ausnahme nur mit der Nachricht von der vorhandenen Ausnahme erstellen, kommt dies als System.Exception durch. Zum Beispiel:

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

funktioniert einwandfrei und wird im Ausnahmehandler als System.Exception abgefangen.

Allerdings, wenn ich versuche, so etwas wie:

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

Dann wird der Ausnahme-Manager fängt die oben System.ComponentModel.Win32Exception statt nur ein System.Exception.

Nur der Vollständigkeit halber, was ich will, ist so etwas wie:

   throw new MSCSqlException(sqlQuery, sqlParams, sqlException); 

und haben die Application.ThreadException Handler einen richtig getippt MSCSqlException erhalten.

Irgendwelche Ideen, wie man das umgehen kann? Gibt es eine Eigenart der Application.ThreadException, die ich im Zusammenhang mit benutzerdefinierten Fehlertypen vermisse?

Unsere benutzerdefinierte Ausnahmeklasse:

[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; 
    } 
} 

Antwort

0

Wir dies endlich herausgefunden ... das Problem ist ein Bug oder Feature, wie .Net Ausnahmen behandelt in einem Hintergrund-Arbeiter Completed-Ereignis ausgelöst. Aus irgendeinem Grund scheint es, dass in diesem Fall die .Net-Laufzeit die innerste Ausnahme von der Stack-Ablaufverfolgung an den ThreadException-Handler statt der erwarteten äußersten Ausnahme übergibt. Diese innerste Ausnahme, wenn eine SQLException ausgelöst wird, ist eine Win32Exception.

Weitere Informationen zu diesem hier:

Application.ThreadException is getting incorrect Win32Exception type

Verwandte Themen