Hur gör ni?

Använder ni enbart basen Exception för att fånga alla fel eller specificerar ni varje typ:
OlDbException, FormatException o.s.v?

Det beror ju lite på eller hur ? :-)

Jag brukar tänka som såhär: Om ett fel uppstår kommer jag kunna ta hand om det?
Om svaret är ja tar jag reda på vilken exception som FÖRST fångar felet.
Om jag kopplar mot en SQL-server är det en SQL-exception. Kanske servern är nere och jag vill skicka ett mail.

Om svaret är nej så fångar jag en vanlig exception. Om det nu skulle vara så att felet uppstår och ter sig på ett sådant sätt att en annan programmerare vill hantera felet så finns ju "InnerException" som håller det egetliga felet.

Kodexempel:
<code>
Public Fuction GetData() as DataSet
try
'' Kod för att anropa DB
catch sqlex as SQLExcetion
'' Fel i DB-anrop. Skicka mail
MyTools.SendMail("admin", sqlex)
return nothing
catch ex as exception
'' Annat fel
MyTools.WriteToLog(ex)
return nothing
End try
'' Returnera datasettet
End funtion
</code>

Mikael.NET

OK, jag ser även att du kör Return Nothing efter Exception. Själv brukar jag köra Exit Function, vilket sätt är "bäst", eller skall man köra båda?

Jag har för mig att Return ska vara lite snabbare. (högst marginellt säkert men kan ändå vara intressant om du har funktioner som anropas tusentals ggr).
Du behöver aldrig skriva exit efter return som ju betyder returnera/avsluta/exit.
Ola

Om du inte kan hantera ett exception men fortfarande fångar upp det kan ingen annan programmera fånga upp det senare i kedjan med hjälp av InnerException. För att det skall fungera måste du kasta ett nytt exception där du lägger med ursprungs-exceptionet.

Jag brukar skapa en egen (eller flera) exceptionklass som jag kan kasta vidare upp till användargränssnitt så det kan visa upp en snygg text som berättar vad som har gått fel, och det kan loggas på ett bra sätt. Din exceptionklass kan ju också ta hand om loggningen.


// Jarle

Bra idé och lösning om man har ett litet störra proekt.

Jag har kört varianten att man fångar exception för att se om man kan ta hand om det och om man inte kan det kastar man ett nytt av sin egen typ, eller av samma beroende på vad som känns bäst.


Vad gäller ovan med exit function så har jag för mig att kompilatorn tar din Exit Function och ändrar det till ett return.

Saken och skillnaden som jag har märkt (och nu snackar vi subjektiv kodstil här) är att jag numera aldrig sätter ett värde för det som ska returneras från en funktion utan bara kör med return. Att sätta värdet skapar bara förvirring + att du med en return kan hoppa ur funktionen rakt av på en rad istället för två som tidigare.

Nu är vi lååångt från exceptions :-)

Exempel:
<code>
Public function GetData(IsAuthenticated as boolean) as datatable
If isAuthenticated then
return New Datastore().GetData() ' returnerar datatable
End if
End function

Public function GetData(IsAuthenticated as boolean) as datatable
dim dt as datatable()

If isAuthenticated then
dt = New Datastore().GetData() ' returnerar datatable
End if

GetData = dt
End function
</code>

Antalet rader och likande hantering torde framgå i exemplet.

//Mikael.NET