Catching Exception innerhalb Verwendung der Anweisung

Question

Ich weiß, dass Using Anweisung das Objekt, das erstellt wird. Wie, wenn ich wollte, so etwas tun:

Using(SqlConnection conn = new SqlConnection(connString)) 
    { 
     //some code 
     //How to show the users if conn is not opened up or generated some kind of error? 
    } 

Wie die Benutzer zeigen, wenn conn nicht geöffnet oder irgendeine Art von Fehler generiert?

Answer 1

using bietet keine Backdoor in die catch.

einfach erweitern Sie es manuell (kein Punkt die try/catch in der Verwendung von IMO in mit):

SqlConnection conn = null; 

try 
{ 
    conn = new SqlConnection(""); 
} 
catch ... 
{ 

} 
finally 
{ 
    if (conn != null) 
     conn.Dispose(); 
} 

Ich bevorzuge diese über die using in einem try-catch Einwickeln oder eine try-catch im using meisten der Einbettung Zeit zu vermeiden, dass der Code mit einem verschachtelten try-catch einmal kompiliert endet. Wenn Sie nur eine sehr kleine Teilmenge eines großen Stück Code in einem using abdecken müssen, würde ich jedoch granularer sein und es einbetten.

Answer 2

Es gibt nichts besonderes über Code in einem using Block geschrieben - verwenden nur try.catch Ausnahmen zu behandeln:

using(SqlConnection conn = new SqlConnection(connString)) 
{ 
    try 
    { 
     conn.Open(); 
     // do more stuff here...... 

    } 
    catch(SqlException sqlEx) 
    { 
     // log error and possibly show to user in a MessageBox or something else 
    } 
} 

Der using(...) { ... } Block selbst entworfen ist nur, um sicherzustellen, dass die Ressource/Objekt, das es „verkapselt“ wird ordnungsgemäß entsorgt, wenn es nicht mehr benötigt wird. Es gibt nichts, was Sie mit der using-Anweisung selbst tun können, um Fehler zu vermeiden.

Also, wenn Sie erwarten, dass nur das Objekt erstellen könnte scheitern, dann würden Sie den gesamten using Block innerhalb des try ... catch Block oder fallen zurück auf einen try ... catch ... finally Block setzen müssen und gewährleisten die ordnungsgemäße Entsorgung selbst (als Adam schlug in seinem Antworten).

Answer 3

Das ist genauso, wie Sie es ohne tun würden.

using(SqlConnection conn = new SqlConnection(connString)) 
{ 
    try{ 
    //some code 
    } 
    catch(SqlException e) 
    MessageBox.Show(e.Message); 
} 

Answer 4

Gerade in gewohnter Weise:

Entweder

try 
{ 
    using(SqlConnection conn = new SqlConnection(connString)) 
    { 
     //some code   
    } 
} 
catch (Exception exc) 
{ 
    //handle error 
} 

oder

using(SqlConnection conn = new SqlConnection(connString)) 
{ 
    try 
    { 
     //some code 
    } 
    catch (Exception exc) 
    { 
     //handle error 
    }     
} 

Answer 5

Sie tun es nicht innerhalb der using

try 
{ 
    using(SqlConnection conn = new SqlConnection(connString)) 
    { 
     // Some code for when "conn" is succesfully instantiated 
    } 
} 
catch (SomeSpecificConnectionInstantiationException ex) 
{ 
    // Use ex to handle a bizarre instantiation exception? 
}  

Answer 6

class SqlConnection 
{ 
    using(sqlConnection) 
    { 

    } 
} 

class Consumer 
{ 
    try 
    { 

    } 
    catch(SqlException) 
    { 

    } 

} 

Es liegt an dem Verbraucher der Klasse zu entscheiden, was mit Ausnahme zu tun ist.

Answer 7

Wie andere Antworten angegeben haben, fügen Sie einfach einen normalen Versuch/Fang hinzu.

Aber ich möchte hinzufügen, dass dies die falsch Ort, setzen try/catch, besonders wenn Ihr Ziel „zeigen die Benutzer“ ist eine Nachricht. Lassen Sie die Ausnahme auf dieser Ebene passieren und erlauben Sie, dass der Stack in Code aufsteigt, der besser in der Lage ist, zu wissen, wie Sie darauf reagieren sollen.

Mit anderen Worten, lassen Sie Ihr Codebeispiel wie es ist. Fügen Sie nichts Neues hinzu ... zu dieser Methode. Aber vielleicht sollte der Code, der diese Methode aufruft, darüber nachdenken, wie man eine Ausnahme behandelt ... irgendeine Ausnahme ... von der Datenbank.

Answer 8

Es empfiehlt sich, try {} catch() {} in der using-Anweisung zu verwenden, wenn Sie eine Ausnahme abfangen wollen, die vom Code im using-Block ausgelöst wird. Betrachten Sie nun die folgenden zwei Beispiele - das erklärt, warum der try-catch-Block in der using-Anweisung eine gute Übung ist.

Beispiel 1

 try{ 
      using(SomeObject so = new SomeObject){ 
       // Perform some tasks 
      } 
     }catch(SomeException objSomeException){ 
      // Perform some actions, if exception occurs 
     } 

Beispiel 2

 using(SomeObject so = new SomeObject){ 
      try{  
       // Perform some tasks 
       }catch(SomeException objSomeException){ 
        // Perform some actions, if exception occurs 
       } 
     } 

Nun, wenn eine Ausnahme während auftritt einige Aufgaben innerhalb der using-Anweisung durchgeführt wird, werden beide haben beispielsweise die gleiche Ergebnisse. Die einfache Antwort ist Nein, Grund ???

Wenn in Beispiel 1 eine Ausnahme auftritt, wird sie vom catch-Block abgefangen - ohne das Ende des using-Blocks zu erreichen. Daher wird das ameObject in Beispiel 1 nicht ordnungsgemäß entsorgt. Selbst wenn CLR großzügig ist (auf das Sie nicht zählen sollten) - der von dem someObject in Beispiel 1 verwendete Speicher wird nicht wiederhergestellt (oder wird maximal in der GC-Sammlung der Generation 2 landen).

Im Fall von Beispiel 2 befindet sich der catch-Block in der using-Anweisung. Das bedeutet, dass die Ausführung das Ende des Verwendungsblocks erreicht. Daher wird Ihr Objekt entsorgt und Sie müssen sich keine Gedanken über das Speicherleck machen (Verderb,

Answer 9

) Wenn Sie den using() -Block in einen try/catch einbetten, garantiert der using() - Block tatsächlich, dass Dispose Wenn jedoch nicht verwalteter Code irgendwo innerhalb Ihres using-Blocks eine Ausnahme auslöst, wird using() nur essen und es wird Ihren Catch nicht erreichen. Verwenden Sie try/catch innerhalb des using() -Blocks, überspringen Sie using() Versuchen Sie/try/catch/finally, oder benutzen Sie die seltsame Syntax "using() try" mit einem catch-Block (was Sie mit einer ungeraden Anzahl von Klammern belässt und wahrscheinlich die Programmierer der mittleren Ebene verwirren wird, die später darauf stoßen es