Hej
Håller på att lära mig felhantering men har några frågor.
Har lagt en alertruta i en catch-funktion och i alertrutan ska ett Exceptionmeddelande stå. Men jag får inte meddelandet att dyka upp i rutan.
Sen undrar jag i allmänhet om felhantering. Används try - catch ofta? I kodexempel ute på nätet ser man inte så ofta dessa, tycker jag.
Finns det funktioner där try - catch bör användas flitigare än andra?
Är det befogat att använda det i mitt enkla exempel ovan eller är det overkill?
MVH// Micke
Sen undrar jag i allmänhet om felhantering. Används try - catch ofta? I kodexempel ute på nätet ser man inte så ofta dessa, tycker jag.
Det är för att det är en grundläggande funktion i programmering att man skall ha felhantering i sin kod. Inte föklarar man OOP i varje exempel med klasser och objekt. Felhantering är underförståd att du använder om man fokuserar på det som exemplet skall visa.
Finns det funktioner där try - catch bör användas flitigare än andra?
På alla ställen där du kan tänka dig att ett runtimefel kan uppstå som du vill hantera. (plus många ställen till :))
Är det befogat att använda det i mitt enkla exempel ovan eller är det overkill?
Ditt exempel är ett bra exempel när try-catch skall användas. Dels så kan du inte med kod säkra dig att det har gått bra att spara till fil, det finns för många faktorer som kan göra att det uppstår fel.
Dels så vill du inte att din applikation skall dö för att man inte kunde spara till en fil, så därför hanterar du denna felkälla med en try-catch kod.
Till ASP.NET som exemplet är i är det dock lite annorlunda då di din webapplikation inte "dör" på samma sätt som en winapplikation gör så får ett ohanterat fel. Så till en ASP.NET applikation så ser min felhantering lite annorlunda ut. Har skrivit om det tidigare så om du är intresserad så kan du säkert söka fram det inlägget.
För att utåergå till din fråga, så precis som Emisson sa, så har du blandat 2 teknoliger i samma linje kod, utan att särskilja dem åt:
Tack till er båda (eller bägge?).
Jo, jag är medveten om att det är server respektive klientkod jag arbetar med, men gissade på att javascriptet körs samtidigt med catchsatsen och därmed borde min alertruta fungera.
Men jag visste däremot inte hur syntaxen för att blanda de två såg ut. Nu vet jag. Har gjort ett snabbt test men får det inte att fungera dock.
Ska kolla mer noga ikväll vad det beror på....
Ska oxå söka rätt på ditt tidigare inlägg, Gladh, och med intresse se vad där står. Tack så länge...
Jo, jag är medveten om att det är server respektive klientkod jag arbetar med, men gissade på att javascriptet körs samtidigt med catchsatsen och därmed borde min alertruta fungera.
Nej, riktigt så fungerar det inte. Det enda som kommer till klienten är det som ASP.NET skickar via Response-strömmen, och där finns inga variabler eller objekt, utan det är bara en ren sträng.
En viktig sak att tänka på när man hämtar ut värden till javascript är att stränger man får ut kan råka innehålla tecken som får javascript-koden att bli felaktig (enkelfnuttar, script-taggar, annan javascript-kod etc). Dessutom ska man inte använda sig av Response.Write i ASP.NET, utom i synnerligen ovanliga undantagsfall. Man går nämligen förbi hela Response-strömmen då, och ditt script kommer att hamna längst upp på sidan (före <html>). Använd Page-klassens RegisterClientScriptBlock-metod i stället.
Ahh, jag tackar allra ödmjukast för svaren...
Jag var bekant med RegisterClientScriptBlock-metoden (och den liknande RegisterStartupScript-metoden. Skillnaden är så vitt jag förstår var i form-blocket scriptet skrivs ut) men trodde att de var tvungna att ligga i Page_Load för att "registreras".... på nått sätt...
Nåväl, läste lite i webForum om hur man kan använda try - catch, samt även finally och tror jag har lite mer kött på benen nu.
Som sagt, jag är tacksam...
// Micke
Angående try-catch, hur brukar ni använda det i sammanband med att ni hämtar information från databas? Lägger ni alltid databasanslutningar/frågor i ett try-catch-block, med tanke på att databasen kan kasta fel eller till och med vara nere. Eller är det inte motiverat jämfört med den prestanda som det kräver?
Huruvida det är motiverat eller inte kan man bara avgöra själv. På något sätt bör man hantera att det blir fel, men den hanteringen kan ju vara så enkel som att man visar felmeddelandet på webbsidan. Beträffande databasanslutningar så lägger jag alltid dessa i using-block, så vet jag att kopplingen stängs ner, oavsett vad som händer.
Man ska dock inte använda felhantering som en kontrollstruktur. T.ex. är det en bra idé att kontrollera om en fil finns, innan man öppnar den, och inte förlita sig på en catch av en IOException.
Hur är det att använda finally för att stänga dbanslutningar? Tyckte Gladh skrev om det i ett tidigare inlägg..
Finns andra exempel på vanliga tillfällen när finally används?
Finally används när du vill att samma kod skall köras både om något går bra eller dåligt. Om man då lägger koden i finally blocket så behöver man bara skriva koden på ett ställe
Att stänga databaskopplingar i "finally" går alldeles utmärkt, men jag vill nog ändå förespråka using-block. Normalt sett blir nettoresultatet det samma, men ett using-block ger databasanropet en naturlig omgivande struktur, och det är bra att få in vanan.
Är inte helt hemma med using-blocket. Vad gör det, läste lite kort på msdn. Har jag uppfattat det rätt som att ett using-block alltid stänger objektet efter sig, även om det blir fel? Finns det någon annan felhantering, eller blir det ett vanligt asp.net error?
Bör man stänga objektet själv som i exemplet eller gör using() det när det är klart?
MySqlConnection conPub = new MySqlConnection(...);
using(conPub) {
conPub.Open()
// gör saker med con
// det blir fel
conPub.Close()
}
// conPub är stängd och disposed
Ett using-block kan man använda på alla klasser som implementerar interfacet IDisposable. När using-blocket "tar slut" så körs Dispose-metoden på objektet, och i fallet med databaskopplingen så innebär det att den också stängs. Självklart får man stänga själv om man vill, men man behöver inte. Kodexemplet skulle jag skriva om så här:
using(MySqlConnection conPub = new MySqlConnection(...))
{
conPub.Open()
// gör saker med con
// det blir fel eller rätt
}
// conPub är stängd och disposed
251 ms totalt · 4 externa anrop · v20260731065814-full.86ec41c2
