Try catch

Du bør catche der hvor du kan gøre noget fornuftigt ved fejlene.

Jeg tror at der er stor sandsynelighed for at det betyder der hvor
du kalder facade klassens metoder.

Der bør du vide lidt om hvad du er igang med.

Hvorimod nede i facade klassen ved du ikke nødvendigvis ret meget
om hvad du er igang med.


Men der er ikke nogen forgyldt løsning på exception handling.

Bortset fra at den skal være konsistent og dokumenteret.

Den skal jeg lige tygge lidt på :o

Vender tilbage senere

en mulighed var evt. at fange dine fejl i facade-klassen og kaste en ny generisk exception med indholdet af den originale. Dette har jeg selv gjort med success, da jeg ellers skal vide hvilken slags database jeg har med at gøre når jeg kalder metoderne i facade-klassen. Og hvorfor det? Jo, fordi at der findes SqlConnectionException, OleDbConnectionException, MySqlConnectionException osv. osv.

Ja, det giver mening cyberfessor.

Men jeg har et problem - her er udpluk fra en af funktionerne i facade klassen:
OleDbDataAdapter adapter = new OleDbDataAdapter(objCmd);

DataSet ds = new DataSet();
adapter.Fill(ds, "dt");
try
{   
  strTest = ds.Tables["dt"].Rows[0]["test"].ToString();
  return strTest;
}
catch(Exception e)
{
blabla
}

Funktionen returnerer, som det fremgår, en string. Men hvis jeg compiler ovenstående kode siger den: "Not all paths have a return value" (eller noget i den stil).

Det hvor det kan gå galt er der hvor strTemp tilskrives - hvis ds.Tables ikke indeholder noget får man en fejl under runtime med den gule skærm der melder fejl - dvs applikationen går ned (det ønsker jeg ikke). Så det er dette jeg forsøger at fange. Jeg kunne bare skrive return "etellerandet" udenfor try-catch blokken, men jeg ønsker, at det skal fanges hvis strTemp ikke får nogen værdi.

Som i kan høre er jeg ikke helt inde i koncepterne for exception handling. Hvordan kan man løse ovenstående problem?

Mvh

Det her er fejlen, der kommer under runtime:
"Exception Details: System.IndexOutOfRangeException: There is no row at position 0."

Du har vel kun 2 muligheder:

1) catch den exception der hvor du kalder denne kode.

2) returner et eller andet som markerer at der ikke er data f.eks. null

Ok, har lige prøvet med følgende:
try
{
strTest = ds.Tables["dt"].Rows[0]["test"].ToString();
return strTest;
}
catch(Exception e)
{
               
}

return null;

Der kommer stadig den der
"Exception Details: System.IndexOutOfRangeException: There is no row at position 0."

hvis der ikke er noget data. Må lige google lidt :0)

hvad så med at teste for null istedet? det er også hurtigere end at gøre sig afhængig af en try-catch

try
{
strTest = ds.Tables["dt"].Rows[0]["test"].ToString();
return strTest;
}
catch(Exception e)
{
return null;             
}

og et test på null udenfor f.eks.

jeg har besluttet mig for at catche der hvor jeg kalder metoderne fra klient klasserne. dvs der er INGEN exception handling i facade klassen til databasen.

hvad nu hvis databasen fx ikke eksisterer? den fanger jeg også fra klientklasserne som det er nu - håber ikke det er helt forkert :-)

på ingen måde forkert... bare pas på du ikke ender med at catche f.eks. SqlConnectionException dine klientklasser, da hele ideen med facadeklassen så ryger sig en tur

ok så skal jeg bare lade være med at fange database specifikke exceptions?

det giver god mening det du siger, for jeg kører pt med access men skal over på ms sql og ideen er jo at man kan nøjes med at udskifte facade klassen...

i så fald skal du finde en mindste fællesnævner. Efter at have kigget i dokumentationen ser det ud til at det ikke helt er tilfældet.

OleDbException arver fra ExternalException, da der nok bliver lavet en del COM-kald tilbage til det gamle ADO, mens at SqlClient er skrevet i fuld managed code, og derfor arver direkte fra SystemException.

Så, enten skal du fange SystemException i dine klientklasser, hvilket ikke er særlig optimalt da ideen med try-catch jo netop er at man kan gøre noget forskelligt, alt efter hvilken exception der bliver kastet, eller du kan bruge det her trick:

en ny exception:

using System;

namespace MPAConsult.ToolBox.Data
{
    /// <summary>
    /// Summary description for DataStoreException.
    /// </summary>
    public class DataStoreException : System.SystemException
    {
        public DataStoreException(string message, Exception exc) : base(message, exc)
        {
        }

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

        public DataStoreException() : base()
        {
        }
    }
}

kast af den i facadeklassen:

public void Open()
        {
            if (conn.State == ConnectionState.Closed)
            {
                try
                {
                    conn.Open();
                }
                catch (OleDbException exc)
                {
                    throw new DataStoreException(exc.Message, exc);
                }
            }
        }

og en anden:

        public void Open()
        {
            if (conn.State == ConnectionState.Closed)
            {
                try
                {
                    conn.Open();
                }
                catch (MySqlException exc)
                {
                    throw new DataStoreException(exc.Message, exc);
                }
            }
        }

og en tredie:

        public void Open()
        {
            if (conn.State == ConnectionState.Closed)
            {
                try
                {
                    conn.Open();
                }
                catch (SqlException exc)
                {
                    throw new DataStoreException(exc.Message, exc);
                }
            }
        }



på den måde kan du teste for DataStoreException i din klientclass, og være sikker på at fange evt. db-fejl, ligemeget hvilket facadeklasse du bruger.

bemærk, at de tre Open()-metoder er fra tre forskellige facadeklasser :)

Kom med svar :-) Tak for hjælpen.

hvem ?

arne_v: dig og burningice.

OK

(lang tid siden vi har set burningice her)

det har du ret i arne... får dog stadigvæk emailnotifikationer, og selvom min pingtid kan være lidt lang (der er jo langt til Grønland), så kommer jeg da forbi i ny og næ :)

Takker.