Kör finally när man kör return inuti try

Ja.

- En sak att tänka på är att instansieringen av din DBAccess bör ligga inom try-catch eftersom det kan inträffa fel när den skall skapas.

- Dessutom så bör du kontrollera så att db är skillt från null innan du kallar på .Dispose().

- Close() och Dispose() skall båda göra samma sak, så det räcker att man kallar på den ena av dem. Jag brukar alltid ta som vana att anropa på Dispose() där det finns en sådan metod, och close() när det inte finns en Dispose() metod.

- M

Varför skulle db.Close() köras? return betyder ju att funktionen lämnas, vilket i detta fall sker i try och catch, alltså innan finally körs. Visserligen har jag itne provkört koden, men om inte ASP är helt vrickat konstruerat borde svaret vara nej!

nitro2k01 skrev:

Varför skulle db.Close() köras? return betyder ju att funktionen lämnas, vilket i detta fall sker i try och catch, alltså innan finally körs. Visserligen har jag itne provkört koden, men om inte ASP är helt vrickat konstruerat borde svaret vara nej!

För att finally alltid körs oavsett om du har en return eller inte. Det är inget specifikt för ASP utan gäller i C++, Java, C#, osv.

Och för att förtydliga så kommer först return att göras och sedan kommer metoderna i finally köras.

Gladh skrev:

- En sak att tänka på är att instansieringen av din DBAccess bör ligga inom try-catch eftersom det kan inträffa fel när den skall skapas.

- Dessutom så bör du kontrollera så att db är skillt från null innan du kallar på .Dispose().

- Close() och Dispose() skall båda göra samma sak, så det räcker att man kallar på den ena av dem. Jag brukar alltid ta som vana att anropa på Dispose() där det finns en sådan metod, och close() när det inte finns en Dispose() metod.

- M

Visa gärna lite exmepl på hur du brukar anroppa databaser. Om jag lägger öppningen av DB inom try satsen så kan jag ju inte stänga den i finally?

Addeladde skrev:

Visa gärna lite exmepl på hur du brukar anroppa databaser. Om jag lägger öppningen av DB inom try satsen så kan jag ju inte stänga den i finally?

Jo, det borde väl gå om du deklarerar variabeln utanför try/catch, men instansierar innanför?

Men Gladh har säkert bättre tips!

Är det inte meningen att objekt som har Close()- samt Dispose()-metoder ska inslutas i en using-sats? Då behöver man inte tänka på såna här triviala saker.

using(SqlDataAdapter da = new SqlDataAdapter()) {
   ...
}

Man behöver alltså inte anropa da.Close() eller da.Dispose() i det här fallet.

Precis som invecklaren skriver så skapar du din variable utanför try-catch, men själva instansieringen sker inom try-catch. Du måste dock sätta den till NULL i din deklaration, annars kommer kompilatorn gnälla på dig att din variabel inte är instanserad.

DBAccess db = null;
try
{
 db = new DBAccess;
 ...

}catch(SPECIFIK_EXCEPTION e)
{
 ...
}
finally
{
 if(db != null)
    db.Dispose();
}

Och precis som Spin säger så är det bättre att använda sig av using än en try-catch om det är så att du bara vill vara säker på att saker och ting stängs ner på ett korrekt sätt. Men det finns ju tillfällen då man faktiskt vill att olika saker skall ske om man får ett oväntat fel, och då måste man använd sig av try-catch...

- M

SPiN skrev:

Är det inte meningen att objekt som har Close()- samt Dispose()-metoder ska inslutas i en using-sats?

Det är inte nödvändigtvis meningen, men det är ett snyggt, tydligt och effektivt sätt. Det ersätter inte eventuellt specific catch-hantering man gör, utan motsvarar ett try-finally-block, utan catch.

using (DBAccess db = new DBAccess())
{ 
       //gör saker
}

Det förutsätter dock att DBAccess anropar Close i Dispose, eftersom det bara är Dispose som anropas i slutet av en using.