Hej,

Jag skulle vilja fråga er utvecklare hur ni använder Try/Catch-block? Jag är inte helt införstådd i hur de fungerar, men efter vad jag har förstått går de att använda på en hel del olika sätt.

Ex:

Public Function EnFunktion()
   Try
      'Hela funktionens kod, där flertalet undantag kan uppstå.
   Catch ex as Exception
      'Felhantering
   Finally
      'Stänga databaskopplingar, etc, etc.
   End Try
End Function

Är detta ett bra sätt att hantera fel och undantag? Är det bättre att göra såhår:

Public Function EnAnnanFunktion()
    'Lite funktionskod, variabeldeklareringar, etc, etc.
    Try
        'en specific metod, som man vet kan generera ett undantag
    Catch ex as Exception
        'undantagshantering
    End Try
    'Mer funktionskod
    Try
        'en annan specific metod, som man också vet kan generera ett undantag
    Catch ex as Exception
        'undantagshantering
    End Try
End Function

Är det helt upp till utvecklaren?

Det som jag tycker är svårt med felhantering i VB.NET är att man inte vet exakt var man ska "skydda" sin kod med Try/Catch-block. Man skulle väl egentligen kunna ha en på varje rad? Finns det några speciella sätt att avgöra när det behövs?

Har också funderat på om man helt enkelt kunde hantera alla fel i Application_OnError i global.asax? Där skulle man kunna logga alla fel i exempelvis en databas, för senare inspektion och visa en felvänlig sida för användaren.

När jag utvecklar vill jag se felen som kommer, och Try/Catch-block börjar jag vanligen inte fundera på förrän min sub eller funktion fungerar som jag vill. Rätt eller fel?

Min primära fråga, eller det primära diskussionsämnet som jag vill driva fram är ändå hur NI gör med ER fel- och undantagshantering? Idéer, förslag, tips, etc?

Tack på förhand!

Generellt tycker jag att en felhantering räcker fint per händelse (t.ex. en felhantering per knapptryck oavsett hur många funktioner som kallas). Det jag brukar göra är att den som är inne på sidan vidaredirigeras till en annan sida där det står att något blivit fel, men ange inte vad som är fel. Sen kallar du på en funktion som skickar felet och vilken sida felet ligger till en databas. Då kan du exlusivt gå in och se, åtgärda och radera? felmeddelandet från DB.

Jag la ett jätte långt svar här men då pelle la om sidan till att var avstängd försvann allt :-(
Så vad jag kan göra för att ge dig allt jag sa plus lite till är en länk till denna artikel från PAG teamet som är rätt ok.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/exceptdotnet.asp

Mvh Johan

Generellt sett brukar jag göra så här:

<code>
Public Function OnButtonClick()
Try
' Så Lite kod som möjligt. T.ex. anropa en metod i någon klass som ligger utanför GUI:t

Catch ex As Exception
' Visa felet
End Try
End Function
</code>

I de klasser som anropas finns
Try
'här kan det uppstå oväntade fel..
Finally
'stäng saker
End Try

alltså ingen catch.


Men detta varierar mycket.
Vilken grad av felhantering som behövs varierar från fall till fall.
I vissa situationer kan man "strunta i" att det blir ett fel och låta programmet fortsätta
(exebtuellt med info om vad som hände)
I andra lägen måste man rätta till och backa sådant som har hänt när det blev fel.
Det är alltså inte någon bra idé tycker jag att alltid göra felhanteringen på samma sätt utan man bör överväga det från fall till fall vad som är lämpligt.

Man bör alltid skriva kod för att undvika exceptions, t.ex.
If Not o Is Nothing Then Return o & "_1"
I stället för att "hoppas på" att o är en sträng eller annars fånga felet.

Tack allihop, och ni andra - kom gärna med fler synpunkter!

Synd att ditt inlägg försvann Johan, du brukar tillföra intressanta vinklar annars. MSDN-länken var givetvis bra, men det är alltid kul att få läsa lite mer personliga synpunkter.

Fortsätt skriva!

ola,

"I vissa situationer kan man "strunta i" att det blir ett fel och låta programmet fortsätta
(exebtuellt med info om vad som hände) "

ajaj... Försök att inte göra så. Det du gör då är att du rubbar balanser in koden. Om ett fel uppstår skall du alltid hantera felet inte låta det vara, många roliga saker kan hända då. Tänk på att felen i sig är inte farliga, de är där för att hjälpa dig som bygger att se till så du inte skapa dem. Att då undanvara dem så kan saker längre upp i kedjan få konstiga konsekvenser...

Det finns ett enda fall då jag inte kastar en exception och det är när APIet jag nyttjar inte kan ge mig ett true eller false värde. En metod i Vsios API GetPage ger inte Null om sidan inte finns utan ett exception, så när jag vill ha en IfPageExist(string page) metod så var jag tvungen att returnera en false när i catchen... men då har jag ändå en hantering på det hela. Falsen i sig nyttjar jag sen för att informera at sidan inte fanns.

Mvh Johan

Johan, en liten fråga: Kör du en try per funktion, eller brukar du ha flera i varje funktion?

Jonas,

Jag brukar ha en, beror på. Det är väldigt väldigt sällan jag har flera. Men det beror oxå på att jag gör mina metoder rätt små och rensa samt självbeskrivande. Tar bort så kallat smelly-code,
duplicerad och ful kod och ser till så den blir renare och mer funktionell etc... Min syn är att om du måste använda två så har du smutsig kod, se då till så att du bryter ut denna kod till två metoder med var sin try.

Mvh Johan

Vilka kodavsnitt som skall omslutas beror helt på situationen. Ofta kan raderna i en metod grupperas i delar som utför olika deluppgifter. En sådan grupp kan vara lämplig att placera i ett try-block. Men först måste vi ställa oss en fråga: Vad skall hända om ett undantag uppstår i en viss sådan grupp? Skall variabler få default-värden och exekveringen av metoden sedan fortsätta? Skall metoden avslutas normalt men med ett speciellt returvärde? Skall undantaget fortsätta uppåt till anropande metoder men viss upprensning krävs innan metoden avslutas? Svaret berättar om vi skall ha catch- och finally-block och vad som skall ske i dessa.

I Firefox-tillägget Pellekod ([Firefoxtillägg]) har jag ett antal rader kod (JavaScript) som hämtar text från Urklipp. Om detta misslyckas (Urklipp är tomt), använder jag tomma strängen i stället och kör vidare. Jag valde att omsluta alla de rader som hör ihop med hämtningen av texten från Urklipp med ett try-block och ha ett catch-block som fångar alla undantag. För mig spelade det ingen roll i vilken av raderna undantaget uppstår.

Att sätta alla rader i en metod inom ett try-block gör att man kan missa möjligheter att gå vidare efter problem. I mitt fall hade det gjort att markerad text inte kunde formatteras om Urklipp var tomt. Och att göra varje enskild rad till ett try-block gör dels att det blir stökigt/plottrigt, men försvårar också om man vill fortsätta körningen. Uppstår ett undantag i den första raden i mitt block, är det meningslöst att köra de övriga raderna i blocket. Hur skall jag hoppa förbi dem om jag har fångat undantaget redan efter rad 1?

Johan:
----------------------------------------------------------------------------------
"ajaj... Försök att inte göra så. Det du gör då är att du rubbar balanser in koden....... /../

Det finns ett enda fall då jag inte kastar en exception och det är när APIet jag nyttjar inte kan ge mig ett true eller false värde."
----------------------------------------------------------------------------------



Precis..... Det är ett exempel på ett sådant tillfälle där man alltså vill ignorera ett exception.
Det var precis ett sådant exempel jag menade, så det är helt onödigt att du försöker lära mig varför man ska felhantera... Men det är säkert bra för andra läsare att du är så grundlig.. :)

Ola L,

aaaa ok. Tyckte inte det framgick så tydligt, tolkade din text mer att du ibland struntade i att ta emot ett fel för att det var onödigt. Så jag tänkte bara vara förtydligande ang att man då bör returnera nått annat värde, du kunde vaktiskt lika gärna menat en void metod :-)

Bra att du sa till.

Mvh Johan

Grundregeln är att man bör göra allt som står i ens makt för att undvika exceptions överhuvudtaget.
Ett undantag tar mycket CPU som man bör försöka undvika. Exempel:

Mindre bra
function Dela(a; b: int):float;
try
result := a/b;
catch
bla bla
----------------
Bättre:
function Dela(a; b:int):float;
if b = 0 then
result := a;
else
result := a/b;


Dåligt exempel kanske men ni fattar galoppen. I vissa lägen går det inte att undvika (I/O t.ex) men detta är grundregeln jag lärt mig. Läs mer på http://www.eggheadcafe.com/articles/20030816.asp

Fredrik,

Absolut. Man skall inte tvinga en exception om det inte behövs. Samma gäller med Hastables etc.
Bättre att kolla Contains än att köra en try och catch.

Dock stör jag mig så på alla som säge,r undvik kasta exception för de är krävande? SO what? Meningen är att nått skall gå fel eller hur? så hur krävande det än är så är det ett måste. Att undvika en exception hantering för en sådan sak är ett rätt dumt argument om jag får tycka till.

Dock behöver man ju inte try och catcha allt utan försöker casta ett där det verkligen sker och som ger tillräckligt med info. ex.


PL - BOL - DAL - DataAccess
Säg att man har 10 anrop i varje lager och att man här ändå från DataAccess kör en try och catch och kastar ett exception från DataAccess till DAL metoderna dessa catchar och gör en nye trhow, som i sin tur i den metoden som ropade på den gör en ny catch och throw.

Har sett fall där ledet kan bli.

ArgumentNullException i DataAccess till DAL där man gör en DalException och nestlar ArgumentNull... där man sedan i en metod ex Connect gör en ny ConnectionException nestlar DalException och sedan ett steg upp gör en ny catch där man kanske gör en DataBaseException och nestlar ConnectionException och håller på så tills man når PL (presntations lagret) sedan där i får man kolla efter ett fel som man redan specat rätt bra i DataAccess...
Helt onödigt. Det är mer detta man menar att man skall undvika och lite vackert skrämmer en med att dessa trown är så krävande.

Kan blivit rörigt det här, jaja, ni förstod nog. Skäll på mig annars :-)

mvh Johan

Jag vet inte vad du menar med "Meningen är att nått skall gå fel" men man kan se det på 2 olika sätt.

En del använder exceptions främst för att hantera oväntade fel i applikationen, t.ex I/O fel etc. eller att databasuppkopplingen går ned.

Andra använder exceptions som en del i programflödet vilket jag menar är onödigt, eftersom det kan undvikas ganska lätt (ytterligare ett dåligt exempel 8-))

try
variabel := Session['HEJSAN']
catch
variabel := 0;

jämfört med

if Assigned(Session['HEJSAN'] then
variabel = Session['HEJSAN']
else
variabel := 0;

Fredrik,

Med "Meningen är att nått skall gå fel"

Menar jag att man skall skcka ett fel om det är ett fel.

Har sett utveklare som gär så här.

public void SetByKey(string key,object value)
{
try
{
this._hashTable.Add[key] = value;
}
catch(Exception e)
{}
}

där add skulle ge fel om nyckel redan fanns... meningen är alltså att här skall det bli fel och det skall
vi som använder SetByKey få reda på. Man skall inte kunna skriva över en nyckel av misstag, kan hända
sååå lätt... Bäst är då att faksitk ge felet till användaren.


Detta var ett lätt exmpel men innanför try hade man lätt kunnat använda andra saker som ger fel långt ner i stegen men som vi inte får tag i och aldrig får veta vart felet uppstod.

Inte ens detta fall är godtagbart.

public bool SetByKey(string key,object value)
{
try
{
this._hashTable.Add[key] = value;
}
catch(Exception e)
{
return ( false );
}

return ( true );
}

Detta är egentligen inte heller godtagbart.

public bool SetByKey(string key,object value)
{
if(this._hashTable.Contains(key)
return ( false );

this._hashTable.Add[key] = value;
return ( true );
}

För vem vet att man skall kolla dess returvärde? Denna metod säger inte så mkt. Det du ser som utvecklare av interfacet är

public bool SetByKey(string key,object value)

Istället för detta gör jag

public void SetByKey(string key,object value)
{
this._hashTable[key] = value;
}

Men bara i de fall jag struntar i om värdet uppdateras då jag vet att det inte påverkar applikationen negativt.

Mvh Johan

Tack allihop!