Exception: try - catch - ELSE ??

Hi,
bin ein ziemlicher newbie in Sachen C#, und nebenbei ist dies mein erster Beitrag im Forum, also erstmal Hallo 😁

Zu meiner Frage:

Wenn ich eine Exception alla 'try - catch' abfange, wie bewerkstellige ich es dass im Fehlerfall bspw. bei einer Datenbankconnection im Anschluss diverse Abfragen nicht ausgeführt werden??

Mit einer Variable 'FehlerAufgetreten == true'
würde das ja gehen, aber gibts da nicht eine bessere programmiertechnisch 'sauberere' Alternative?

bool FehlerAufgetreten = false;
try
{
  Finanzen.DBConnect("SELECT AuszugID, Datum, Betrag, ZweckID, Bemerkung, AktionKnippe, AktionKonto FROM tblAuszug", "Auszug");
}
catch (Exception ex)
{         
  FehlerAufgetreten = true;
  MessageBox.Show(ex.InnerException.Message,ex.Message,MessageBoxButtons.OK,
                             MessageBoxIcon.Error);
}
if (FehlerAufgetreten == false)
{
  DataTable AuszugTabelle = Finanzen.FinanzenDataset.Tables["Auszug"];
  int AnzahlEintraege = AuszugTabelle.Columns.Count;
...
...
...
}

Den kompletten Block unten in den try{}-Block Packen ist ja auch wohl schlecht oder?

Vielen Dank schonmal im voraus!

Hallo andreas-82,

ich würde das so handhaben, dass im Falle eines Fehlers per "return" aus der aktuellen Methode gesprungen wird.

In etwa so:

public DataSet HoleMirDaten()
{
   try
   {
      // DB-Connect Try
   }
   catch
   {
      MessageBox...
      return null;
   }

   // jetzt die Anweisungen, falls kein Fehler aufgetreten ist.
}

Hilft Dir dieser Ansatz?

Gruß
Norman-Timo

An sich packt man logische Einheiten zusammen in einen try-Block, das heisst, kleinere Algorithmen, die einen Sinnzusammenhang haben. Im catch-Block kannst du mit Hilfe der rausgeworfenen System.Exception feststellen, was schief gelaufen ist, und das dementsprechend behandeln.

Extra ne Variable zu setzen und die hinterher mit einer if-Anweisung auszuwerten, ist da irgendwie doppelt gemoppelt. (uebrigens: wenn du ne bool-Variable auswerten willst, ist meiner Meinung nach

if(myBoolean) 

// statt: 
if(myBoolean == true)

später besser lesbar. Aber das nur nebenbei 🙂.

LaTino
PS: das raushuepfen mit return ist eigentlich auch nicht der Sinn eines returns 😉

Hi andreas-82!

Ein Verbesserungsvorschlag:

if (!FehlerAufgetreten)

der Marcel

EDIT: siehe Anfängerfehler == true / == false

EDIT2:

Original von LaTino
PS: das raushuepfen mit return ist eigentlich auch nicht der Sinn eines returns

Weshalb? Ich finde sowas praktisch. 🙂 Aber die das Thema hatten wir schonmal diskutiert g return mitten in einer Methode?

Danke schonmal für die Antworten, das ging ja schnell 🙂

Also:

@norman_timo
Meine Funktion hat keine Rückgabewerte, deshalb funzt das so leider auch nicht.

-> Connecte die Datenbank über einen Methodenaufruf einer externen Klassen;
Dieser soll mit try - catch überprüft werden (OleDBException)

In meiner eigentlichen Klasse wird der Inhalt meiner DB-Abfrage dann in ein DataTable geladen, die Werte ausgelesen und etwas rumgerechnet und anschließend über ein DataGrid ausgegeben. ...

@LaTino
... deshalb wäre der try{} - Block auch ziemlich lang.
Mir gehts ja nur um die Datenbankverbindung, die aufgebaut und überprüft werden soll.

Trotzdem alles rein?

Hatte schonmal ein Close(); dahinter, aber
1.) bringt mich das in Zukunft auch nicht weiter und
2.) hat der Debugger komischerweise ein paar Zeilen weiter trotzdem noch eine unbehandelte Ausnahme gefunden (bei Columns.Count)

Wie kann denn das schon wieder?

@der Marcel
Danke, werde mir das mit dem == true / false mal abgewöhnen 😉

@all
Echt Klasse, hier lernt man ja richtig was 🙂

Nur fehlt noch die richtige Lösung... 🤔

nabend

ich könnte mich täuschen aber meiner meinung nach folgender ablauf

try{
     //connection öffnen
     // Daten in DataSet oder DataTable oder sonstwas
}catch{
     //error behandlung
}finally{
     //connection schliessen
}
//nur noch mit DataSet DataTable oder sonstwas arbeiten 

kannst natürlich abfragen ob darin daten enthalten sind und dann rest überspringen
oder (was nicht meiner meinung entspricht!!!!!) mit return rausspringen

Anmerkung: kein rückgabewert das könnte bei dieser Sache auf ein nicht optimales Design hindeuten

mfg

Original von andreas-82

Meine Funktion hat keine Rückgabewerte, deshalb funzt das so leider auch nicht.

[..]

-> Connecte die Datenbank über einen Methodenaufruf einer externen Klassen;
Dieser soll mit try - catch überprüft werden (OleDBException)

... deshalb wäre der try{} - Block auch ziemlich lang.
Mir gehts ja nur um die Datenbankverbindung, die aufgebaut und überprüft werden soll.

Na, das riecht nach unzureichender Kapselung 😉. Aber den Ansatz hast du ja schon: du weisst doch ganz genau, was du machen willst - "Verbindung aufbauen und prüfen". Mer sollte die Methode nicht machen.

@Marcel: ich weiss, daher der Smiley 😁 Wir stimmen aber überein, dass "return null" eine denkbar ungeeignete Art des Methodenabbruchs ist?

LaTino

Etwas noch zum Thema Exception Handling.

Die Dinger sind dazu da, (unvorhergesehene) Ausnahmen abzufangen und das Programm trotz einer Unregelmäßigkeit weiterlaufen zu lassen.

Wenn man in einer Situation ist, wo man einen fest damit rechnen kann, dass es in einer bestimmten Situation zu einem Abbruch des Algorithmus kommt, dann muss man prüfen - das ist nicht dasselbe wie ein try/catch/finally: es ist immer besser, die Methode gar nicht erst in einen Fehler laufen zu lassen, als die entstandene Ausnahme zu behandeln.

Sich mit exception handling darum zu drücken, die Abläufe und Abhängigkeiten seines Programmes gründlich zu durchdenken, bevor man mit dem coden loslegt, ist ein unsauberer Programmierstil und führt früher oder später gegen die Wand.

Genug doziert 😉.

LaTino

@ Latino

Recht hast du schon dann poste doch mal deine Datenbank abfrage

in meinen qt wirste auch mittlerweile kaum try/catch/finally finden

aber in diesem fall mach ich es immer so da ich keine lust habe alle möglichkeiten abzufangen

denn dieser try catch wird in den anwendungen sehr sehr sehr selten geworfen

mfg

Original von andreas-82
Meine Funktion hat keine Rückgabewerte, deshalb funzt das so leider auch nicht.

Dann springe nur mit einem return raus.

try
{
    MessageBox.Show("Exception wird ausgelöst.");
    throw new Exception();
}
catch (Exception ex)
{
    return;
}
MessageBox.Show("Wird nicht erreicht.");

Posten wird schwierig, unsere entsprechenden Klassen befinden sich aus naheliegenden Gründen nicht auf privaten Rechnern 😉.

Im wesentlichen hat die Klasse ganz aehnlich wie die SqlCommand-Klasse die Connection als Property. Beim setzen dieser Property wird alles denkbare durchgeprüft und eine andere Eigenschaft gesetzt, die eine Enumeration ist (eben die Fehlermeldungen oder halt, dass das ok aussieht).

Im Einsatz kann der Programmierer nach dem Setzen des Connectstrings also prüfen, wie der absehbare Status der Verbindung ist, und dies im Vorfeld behandeln. Sobald er ein Kommando ausführt, kann er, wenn er uns nicht ganz traut 😉, selber noch ein exception handling einsetzen. Das wäre dann aber wirklich eine echte Ausnahme, wenn das catch anspringt 😉. Hab' ich jedenfalls noch nicht erlebt, und die Bibliothek erlaubt alle möglichen Sorten von Datenzugriffen.

LaTino

Also wo soll ich anfangen.

Erst vielleicht nochmal kurz zur Verdeutlichung:

Ausschnitt aus Klasse für die Connection:

/* Stellt die Verbindung zur Datenbank über einen Adapter her 
       * und füllt das globale Dataset 'FinanzenDataset':
       * ----------------------------------------------------------
       * Eingabewerte:
       * - SQL-String
       * - Name für den aufgerufenen Datensatz zur Identifizierung
       * 
       * Rückgabewert:
       * - OleDBConnection
       */
public class CFinanzen
  {
    //Attribute
    public DataSet FinanzenDataset = new DataSet();
    private const string DBPfad = "daten\\sf-daten.mdb";
    private const string DBProv = "Microsoft.Jet.OLEDB.4.0";
    
public OleDbConnection DBConnect(string SqlString, string DatasetTableName)
    {
      string DBConnectString = "PROVIDER=" + DBProv + ";DATA SOURCE=" + DBPfad;

      OleDbConnection DBConnect = new OleDbConnection(DBConnectString);

      try
      {
        OleDbDataAdapter DBAdapter = new OleDbDataAdapter(SqlString, DBConnect);
        DBAdapter.Fill(FinanzenDataset, DatasetTableName);
      }
      catch (OleDbException innerEx)
      {
        throw new Exception("Fehler im Datenbankaufruf!", innerEx);
      }
      return DBConnect;
    }

}

Klasse für Form_Load

private void DataGridFuellen()
      {
        System.Collections.ArrayList list = new System.Collections.ArrayList();

        try
        {
//HIER DER KLASSENAUFRUF!
          Finanzen.DBConnect("SELECT * FROM tblAuszug", "Auszug");
        }
        catch (Exception ex)
        {          MessageBox.Show(ex.InnerException.Message,ex.Message,MessageBoxButtons.OK,MessageBoxIcon.Error);
        //return; ???
        }

//DAS ALLES NUR MACHEN, WENN KEINE AUSNAHME AUFGETRETEN IST:

        DataTable AuszugTabelle = Finanzen.FinanzenDataset.Tables["Auszug"];
[...]
        int AnzahlEintraege = AuszugTabelle.Columns.Count;
        
[...]
        /* Schleife in der die Datenbank ausgelesen wird
         */
        for (int i = 0; i < AnzahlEintraege; i++)
        {
          /* Werte werden für jede Zeile 'i' ausgelesen
           */
          AuszugID = (Int32)AuszugTabelle.Rows[i]["AuszugID"];
          Datum = (DateTime)AuszugTabelle.Rows[i]["Datum"];
          Betrag = Convert.ToDouble(AuszugTabelle.Rows[i]["Betrag"]);
          Bemerkung = AuszugTabelle.Rows[i]["Bemerkung"].ToString();
          AktionKonto = (bool)AuszugTabelle.Rows[i]["AktionKonto"];
          AktionKnippe = (bool)AuszugTabelle.Rows[i]["AktionKnippe"];
[...]
          DTfuerDataGrid.Rows.Add(Datum, Bemerkung, Betrag, ZwischenbetragKonto, ZwischenbetragKnippe);
        }
        DataGrid.DataSource = DTfuerDataGrid;      
      }

@LaTino:

Na, das riecht nach unzureichender Kapselung

Was genau meinste damit?

Im wesentlichen hat die Klasse ganz aehnlich wie die SqlCommand-Klasse die Connection als Property. Beim setzen dieser Property wird alles denkbare durchgeprüft und eine andere Eigenschaft gesetzt, die eine Enumeration ist...

Gut, also prinzipiell bsp. vorher den Pfad der Datei abfragen, die Connection abfragen, etc.
Dann kann man sich das mit dem try-catch sparen, wenn ich das richtig verstanden habe 😉

Nur wie dann den Aufruf

Finanzen.DBConnect("SELECT * FROM tblAuszug", "Auszug");

... auf gültigkeit abfragen?

Irgendwie über .state?

Bin etwas ratlos im Moment, aber will ja mal irgendwann gescheiten Code schreiben... 😭

LaTino schrieb:
An sich packt man logische Einheiten zusammen in einen try-Block, das heisst, kleinere Algorithmen, die einen Sinnzusammenhang haben. Im catch-Block kannst du mit Hilfe der rausgeworfenen System.Exception feststellen, was schief gelaufen ist, und das dementsprechend behandeln.

andreas-82 schrieb:
... deshalb wäre der try{} - Block auch ziemlich lang.
Mir gehts ja nur um die Datenbankverbindung, die aufgebaut und überprüft werden soll.

Trotzdem alles rein?

Zwar wird dein try-Block etwas länger, wenn du alles da rein stopfst, allerdings verlierst du andersrum einen Vorteil bei der Verwendung von Exceptions, nämlich getrennte Logik und Fehlerbehandlung. Egal ob du deine Methode frühzeitig mit einem return abbrichst, oder ein Flag innerhalb setzt, irgendwo muss das geprüft werden, um zum Beispiel dem Benutzer mitzuteilen, dass etwas schief gelaufen ist. Erinnert bereits etwas an das ständige Überprüfen von Return-Codes aus früheren Zeiten.

Der try-Block wird auch um einiges kleiner, wenn man nicht versucht Model, View und Controller in eine Klasse zu "quetschen".

Hallo zusammen,

anstatt einem vorzeitigen return kann man auch so agieren:

public DataSet HoleMirDaten()
{
   try
   {
      // DB-Connect Try
   }
   catch
   {
      MessageBox...
   }

   if (DBConnected)
   {
      // jetzt die Anweisungen, falls kein Fehler aufgetreten ist.
   }

   return;
} 

Aber was ändert das? Das was der Rechner machen muss, ist zusätzlich noch eine if-Abfrage auswerten, bevor er die Methode verlässt. Ich denke es ist durchaus legitim im Falle einer Ausnahme früher als geplant aus der Methode auszusteigen.

Regulär würde ich das auch nicht machen, aber bei Exceptions??

Gruß,
Norman-Timo

Ganz unabhängig von deiner eigentlichen Problematik: "Universelle" Exception-"handler" à la

catch (Exception ex) {
  MessageBox...
  return;
}

sind gefährlich. Du solltest nur das abfangen, womit du rechnest und was du dann auch dementsprechend an der entsprechenden Stelle behandeln kannst. Hier böte sich etwa eine OleDBException an. Es könnte passieren, dass ein Fehler auftritt, der weitaus größere Folgen für dein Programm hat und der dann nicht einfach mit einer MessageBox behandelt werden kann.

Zu deinem Problem:

Du könntest auch das, was nach dem Verbindungsaufbau kommt in eine eigene Methode auslagern und dann sowas machen:

void DieMethode() {
  try {
    Finanzen.DBConnect("SELECT * FROM tblAuszug", "Auszug");
    GridFüllen();
  } catch (OleDBException ex) {
    MessageBox.Show(...
  }
}

Grüße,
Andre

Ich hab' auch nix gegen frühe returns - wenn in einem Zweig der Methode das Ergebnis feststeht, dann muss man da nicht noch weiter drinhocken. Ich habe nur was gegen "return;" oder "return null;". Das sagt der aufrufenden Methode nämlich genau gar nichts.

public enum QueryStatus { notSet, ok, unkownHost, unknownDatabase, unknownTable, invalidConnectString, [...] };

public QueryStatus FillDataset() {
[tue dinge...]


//Erfolg
if(blubb) {
     this.myDataset = ergebnis;
     return QueryStatus.ok;
}

if(bla)
   return QueryStatus.unknownHost;

[etc.]

return QueryStatus.unknownError;
}

}

Das ist jetzt noch nicht besonders schön, aber ich wollte auch nur verdeutlichen, was ich meine 🙂.

LaTino

Danke nochmal für die Antworten 🙂

Mache das ganze jetzt per

if (Finanzen.FinanzenDataset.Tables["Auszug"]!=null)
{
//Hier DB-Abfragen rein
}

und einem Close(); im catch{}-Block, weil das Programm bei falscher Datenbank sowiso nicht arbeiten kann.

Hoffe das ist so legitim 😉

Nochmal eine kurze Form-Frage:

Also unser Lehrer hat gesagt, dass man den Code aus Klassen, mit dem Code eines Formulars trennen soll, damit man die Klasse z.B. einer Windows-Anwendung auch für eine ASP-Anwendung benutzen könnte.

Soweit klar, aber wenn ich z.B. ein simpeles Formular habe dessen Werte ich einer Methode einer Klasse übergebe,
wie läuft dann die Fehlerbehandlung, bzw. Berichterstattung für den User von statten, der fehlerhafte Werte einträgt?

Per "if(wertfalsch) - then MessageBox("Falscher Wert")" in der Klasse ist ja schlecht, weil ich dann keine Trennung habe.

Und try-catch soll ja anscheinend nur 'im Notfall' benutzt werden, wenn ich euch richtig Verstanden habe. ?(

Die Eingabeüberprüfung vor dem Methodenaufruf anstatt innendrin zu machen ist doch auch dämlich...

Danke schonmal für Antworten 8)

@andreas-82

an dieser stelle möchte ich doch mal das stichwort delegates in den raum werfen

mfg

hi!

Original von blackcoin
@andreas-82

an dieser stelle möchte ich doch mal das stichwort delegates in den raum werfen

mfg

was meinst du damit? 🙂

@andreas-82:

Richtig ist natürlich die eigentliche Anwendungslogik von der GUI-Logik zu trennen, so dass deine Anwendungsklassen universell einsatzfähig sind.
Du könntest doch zum Beispiel klasseneigene Fehlerevents (blackcoin, meintest du die Delegaten in bezug zu Events?) schreiben, an die sich die GUI dranhängen und den Fehler entsprechend behandeln kann, wenn die Events ausgelöst werden.
Zu dem Try-Catch: An erster Stelle sollte bei der Programmierung auf jeden Fall Fehlervermeidung stehen, das ist richtig. try-catch ist aber immer notwendig um unvorhergesehene Ausnahmen abzufangen. Durchaus kann man an manchen Stellen try-catch auch zur direkten Problemlösung verwenden. Ein Beispiel (aus net1.x, aber mir fällt so schnell kein besseres ein 🙂 ): Du möchtest wissen, ob ein stringinhalt einer Zahl entspricht. So kannst du den String versuchen zu parsen und wenn die Exception kommt, wars halt keine Zahl 🙂 Für den speziellen Fall hält Net2.0 aber TryParse bereit 😉

der Marcel

@der Marcel
Ja genau das meinte ich

mfg

LaTino schrieb:

  
public enum QueryStatus { notSet, ok, unkownHost, unknownDatabase, unknownTable, invalidConnectString, [...] };  
  
public QueryStatus FillDataset() {  
[tue dinge...]  
  
  
//Erfolg  
if(blubb) {  
     this.myDataset = ergebnis;  
     return QueryStatus.ok;  
}  
  
if(bla)  
   return QueryStatus.unknownHost;  
  
[etc.]  
  
return QueryStatus.unknownError;  
}  
  
}  
  

Das ist jetzt noch nicht besonders schön, aber ich wollte auch nur verdeutlichen, was ich meine 🙂.

LaTino

So würde ich es nur machen, wenn ich eine Sprache verwenden würde, die keine Exceptions anbietet. Wie willst du zum Beispiel 3 Ebenen nach oben mitteilen, dass ein falscher Connection String verwendet wurde? Man kann hier noch weitere Argumente aufzählen, warum man Return Codes nicht verwenden sollte, denn das, was du hier empfiehlst, sind Return Codes. Man kann es eben in zweierlei Hinsicht übertreiben mit dem Einsatz von Exceptions ..

Soweit klar, aber wenn ich z.B. ein simpeles Formular habe dessen Werte ich einer Methode einer Klasse übergebe, wie läuft dann die Fehlerbehandlung, bzw. Berichterstattung für den User von statten, der fehlerhafte Werte einträgt?

Klarerweise wird die Überprüfung ausgelagert in eigene Objekte, bzw. wenns ist, kannst das auch dem Model überlassen. Ansonsten google einfach nach dem Stichwort Validator oder ähnlichem.

Original von der Marcel
Du möchtest wissen, ob ein stringinhalt einer Zahl entspricht. So kannst du den String versuchen zu parsen und wenn die Exception kommt, wars halt keine Zahl 🙂

Auaaaaa. Hast recht, ist ein schlechtes Beispiel. Grad für sowas, wenn es die Sprache nicht von sich aus bietet, baut man sich eben eigene Methoden, die das übernehmen. Der Wiederverwendungswert ist ziemlich hoch.

Klar programmiert es sich mit try...catch erst einmal schneller, aber daher kommt ja auch der Spruch "quick and dirty". Was machst du, wenn du mal in 'ner Sprache programmieren musst, die kein Exception handling kennt? (Sag nicht, das passiert nicht - Murphy lauert 😉 )

char tryParseString(char *input) {
   int i = 0;   
   while(*(input + i) != '\0') 
		if(*(input + i) >= '0' && *(input + i++) <= '9')
			return 1;
   return 0;
}

LaTino
EDIT: intellisense fehlt wirklich 😉

Original von Bernhard
So würde ich es nur machen, wenn ich eine Sprache verwenden würde, die keine Exceptions anbietet. Wie willst du zum Beispiel 3 Ebenen nach oben mitteilen, dass ein falscher Connection String verwendet wurde? Man kann hier noch weitere Argumente aufzählen, warum man Return Codes nicht verwenden sollte, denn das, was du hier empfiehlst, sind Return Codes. Man kann es eben in zweierlei Hinsicht übertreiben mit dem Einsatz von Exceptions ..

*grins*
Lies nochmal. Das war eine Alternative zu "return null", nicht zum exception handling.

Grüße,

LaTino

Original von LaTino
*grins*
Lies nochmal. Das war eine Alternative zu "return null", nicht zum exception handling.

Grüße,
LaTino

Ich hab deine Beiträge sehr gut gelesen, und nein, Return Codes sind keine Alternative zu einem "return null". Grundsätzlich braucht man sich doch nur die Frage stellen, ob der Aufrufer Fehlerursachen erfahren muss, bzw. soll oder nicht. Keine der beiden Methoden lässt sich meiner Meinung nach durch die andere ersetzen, wodurch du Return Codes auch nicht als Alternative zu "return null" sehen kannst.

Du meintest, dass es vielleicht nicht ganz dumm ist, dem Aufrufer mitzuteilen, warum die Verbindung zur Datenbank nicht hergestellt werden konnte, was ja auch nicht schlecht ist, nur stellt sich dann die Frage, warum Return Codes und nicht Exceptions?

Jetzt wirst du vielleicht wieder sagen wollen, das du Return Codes gar nicht mit Exceptions vergleichen willst. Wenn man allerdings "return null" als Alternative zu Exceptions und Return Codes als Alternative zu "return null" anbietet, ergibt sich aber zwangsweise der Vergleich zwischen Exceptions und Return Codes ..

Original von Bernhard
Grundsätzlich braucht man sich doch nur die Frage stellen, ob der Aufrufer Fehlerursachen erfahren muss, bzw. soll oder nicht.

Da haste wahr. Möglicherweise ist meine Denke da etwas festgefahren, da ich die meiste Zeit Klassen entwickle, von denen ich weder weiss, wer sie benutzen wird, noch, wofür sie (später) noch benutzt werden können/sollen (ausser für die Anwendung, für die ich sie entwickle).

Und da ist es 'ne schöne Sache, wenn die Klasse möglichst Fehler von vornherein verhindert, und ausführliche Informationen darüber liefert.

Grüße,

LaTino

Hallo LaTino!

Ich weiß, dass mein letztes Beispiel wirklich die Holzhammermethode gefrei dem Motto "Wenns kaputt geht, wars nicht in Ordnung" darstellt. Sowas wende ich meistens nur dann an, wenn ich schnell ein Grundprinzip programmiere, bei dem ich hinterher noch die Ecken ausputze, um die schnelle Funktion zu testen. Bei meinem Beispiel möchte man ja vielleicht auch das störende Zeichen aus dem String entfernen, wofür try-catch schon vonherein ungeeignet ist. Mir ging es lediglich darum zu zeigen, wofür try-catch nötig ist und wofür man es benutzen kann, da andreas-82 allgemein geschrieben hatte, man solle es nur im Notfall anwenden. 🙂

der Marcel