där det verkade som att alla typer av fel ändå fångades upp.. stämmer det.. hos mig fungerar det inte..? Som personen skrev fångades vissa fel upp men inte andra, hos mig t.ex. inte SqlException.. om en Session är tom händer heller inte någonting.. det gick iofs att lösa genom att i Session_Start kolla om den aktuella session var tom, köra en redirect (för att be användaren logga in igen t.ex).
Antingen kunde jag ju ta bort try/catch eller köra en throw(ex) och jag trodde att Global.asax skulle fånga felet.. men det funkar inte.. (jag provade t.ex. att ändra i web.config så att databasen inte hittades) sen provade jag att, i Global.asax, lägga in protected void Page_Error (det stämmer eller?)
Så jag undrar alltså om det stämmer att Global.asax ska fånga ALLA unhandled exceptions eller bara vissa..?
(Även om FormsAuthentication tvingar tillbaka användaren till login sidan ska väl Global.asax fungera som vanligt o kolla om db-kopplingen fungerar?)
Tror det beror på var Exceptions kastas, har dock inte kommit på hur det fungerar mer än att det inte verkar vara några problem att skriva en egen HttpModule som tar hand om felen.
Är ganska säker på att alla fel som du inte hanterar själv fångas av Application_Error() har inte haft några som helst problem med det.
Dock skall man låta bli att lägga så mycket kod logik i global.asax, utan man bör, ta emot felet och sedan skicka det vidare till en annan sida. Så här ser min felhantering ut i global.asax.
//-- Get exception
Exception ex = Server.GetLastError();
//-- clear response
HttpContext.Current.Response.Clear();
//-- transfer to error page
Server.Transfer("/EnterpriseGateway/WebForms/error.aspx");
Och sedan i felsidan så tar man emot felet och behandlar det:
//-- Get the last exception
Exception exception = Server.GetLastError();
if(exception.InnerException != null)
exception = exception.InnerException;
//-- Log error
WriteExceptionMessageToLogger(exception);
//-- Write exception message to page
WriteExceptionMessageToPage(exception);
Det fungerar hur bra som helst, tyvärr har man då låst sin felhantering så att man inte kan slå på/av den i web.config men det kan man säkert överleva...
Hejsan (fick möjlighet att svara först nu) aha.. det var intressant.. så om du kör Server.Transfer istället för Response.Redirect får du alltså med dig, på nåt sätt, det/de Exception som fångades av Global.asax?? Själv sparade jag Message, TargetSite etc i variabler som jag sen skickade med QueryString till error.aspx.. men det där blev ju mycket renare kod som du hade... (om det fungerar såsom jag tror : )
aha.. du menar också att saker som just står i Global.asax inte kan påverkas från web.config, o därför inte kan slås på/av? oki..
Men okay, apropå själva frågan.. hmm.. bra att den ska fånga alla fel.. i så fall är det jag som måste kodat fel nånstans.. ska felsöka lite till.. tack för all input :)
aha.. du menar också att saker som just står i Global.asax inte kan påverkas från web.config, o därför inte kan slås på/av? oki..
Det finns ju felhanterings attribute i web.config, där man ställer in vilken sida man skall gå till osv osv. Denna information kommer inte att fungerar tillsammans med koden i Application_Error().
Du kommer helt enkelt inte att gå till den sida som står i web.config utan det som står i global.asax och den koden är kompilerad så det betyder att du måste kompilera om din kod om du vill ändra detta. Man kan säkert lösa det genom att läsa värden från en externkälla vart man vill gå och om man vill visa den sida, typ en databas/xml-fil osv osv...
- M
279 ms totalt · 4 externa anrop · v20260731065814-full.a51de22e
