Skriva ut felmeddelande från obunden cs fil?

Låt bli att catcha utan använd i stället de inbyggda metoderna i ASP.NET för att fånga dessa, http://www.developer.com/net/asp/article.php/961301

Hej renholm, tack för svaret.. :) har läst artikeln nu... jo, lite coolt att man kan logga direkt till event viewern... : )

Ska nog tillämpa detta och även använda mail såsom de sa att man kunde göra.. fast det smidigaste hade varit om man kunde redirecta till en sida som visade felen (om man t.ex. är inloggad som admin).. (av bekvämlighetsskäl tycker jag : )

du vet inte om det går...?

I annat fall är jag nöjd med att göra som i artikeln du visade :)

Hej igen.. :)

vet inte om jag missuppfattade, men om jag lägger in EventLog entries under Application_Error i global.asax så ska alla unhandled exceptions (om jag tar bort try/catch som du sa) då komma i EventViewer (jag kör XP.. artikeln sa ju Win 2000 log, men det borde väl funka iaf..?)

Nån som vet...?

I catch skulle jag vilja göra en Response.Redirect till en error.aspx sida och skickar med ex.message etc i querystring där jag skriver ut vad som blev fel... men jag får inte Response.Redirect att fungera oavsett vilken úsing-statement jag använder... nån som vet hur man gör?

Det är en extremt dum ide, din db-klass skall inte ha något med hanteringen av felen att göra, den skall bara kasta felet uppåt i kjedjan.

Det finns en väldig bra anledninge till det, förutom det själklara att din db-klass inte har något med felhantering att göra, och det är att din db-klass antagligen är/bör/skall var så generell så att den kan återanvändas i andra projekt och lösnignar. Det betyder att du då kommer att få problem när du vill använda din db-klass i en windowsapplikation eftersom den inte har någon response.redirect.

Mitt tips till dig blir att kasta felet vidare uppåt så överliggande program/komponent avgör hur det skall loggas. Och är det så att man vill logga annan information, typ trace/debug information så är mitt förslag att din db-klass har ett event som aktiveras när du vill logga något annant än ett fel. På det visset så avskiljer du logging och själva funktionen i din klass.

- M

Hej Gladh, tack för svaret..

Det är en extremt dum ide, din db-klass skall inte ha något med hanteringen av felen att göra, den skall bara kasta felet uppåt i kjedjan.

hehe.. oki, a det är sant som du säger ang. att det heller inte går att flytta till en win.app.. hmm.. okay, så jag kanske gör en Exception klass istället då och anropar den eller..? fast då måste ju även den vara.. "oberoende"... och gå att flytta etc

Mitt tips till dig blir att kasta felet vidare uppåt så överliggande program/komponent avgör hur det skall loggas.

Mina programmeringskunskaper är rätt så begränsade så när du säger "kasta felet vidare uppåt" så är jag inte med på riktigt hur du menar...? Ska DB-klassen ha en metod som returnerar eventuella fel, och om ja, vem ska anropa den metoden osv...? :)

Ska DB-klassen ha en metod som returnerar eventuella fel, och om ja, vem ska anropa den metoden osv...?

Nope. Alternativ 1 är att du inte har någon som helst felhantering I din db-klass, alltså ingen try-catch kod, då kommer felet automatiskt att "kastas uppåt I kjedjan" och fångas I en try-catch I den komponent/applikation som kallar på db-klassen.

Alternativ2 är att du har en try-catch I din db-klass men att du I ditt cachblock enkelt bara skriver throw vilket då kastar felet vidare upp I kjedjan.

try{
  //-- lite kod som sysslar med db-hantering
}catch(Exception ex){
  throw;
}finally{
  //-- städa upp efter db-hanteringen.
}

- M

aha.. det är det som menas med "uppåt i kedjan"..

jo, okay.. om jag gör så, så löser ju det mitt ursprungliga problem iofs.. för då kan jag ju göra min Response.Redirect från gui.cs filen...

typ

try
{
   //anropa db klassen
   dbConn.InsertProcedure(spName, parameters);
}
catch(...)
{
   Response.Redirect(....);
   //... och registrera i eventviewer om det går + skicka mail :)
}

fast.. det är bara om jag använder ditt alternativ 2 som jag kan göra transaction.commit/rollback i try/catch.. eller så är det kanske bättre arkitektur (om om man nu kan tala om nåt sånt : ) att flytta så mycket som möjligt av databas hanteringen till själva SP i sql-server och lägga commit/rollback där.. nåja, spelar kanske inte så stor roll...? om nån har synpunkter får ni gärna skriva.. annars tackar jag för svaren jag fick med EventViewer och uppåt i kejan :)

ska testa ikväll o se