[ASP.NET] best practices error handling

[CaptBiele]

Ik wil nu mijn eerste vb.net app in elkaar gaan zetten, en zal dus nog veel fouten gaan maken
Ik wil dan ook goed weten hoe ik het beste de errors kan afhandelen.
Mijn scenario: ik wil de graag de fouten loggen (eventlog en/of txtbestand) en deze vervolgens
weergeven op één algemene foutpagina. (dus geen aparte pagina voor 404 of zo) Ik ben de enige die de applicatie gebruikt, dus het moeten gedetailleerde foutmeldingen zijn.

Ik heb al een aantal tutorials en best practices doorgelezen, maar kan nog niet zeggen dat ik het nu
allemaal overzie. Ik zal dus proberen uit te leggen hoe ik het nu probeer voor elkaar te krijgen... mogen jullie het afschieten/aanvullen.

De basis functionaliteit om foutmeldingen op te vangen en te loggen staat in de Application_Error in de global.asax. Hier wordt gelezen of eventlogging en/of naar txtbestand schrijven aan staan of niet. (dit gebeurd aan de hand van de appsettings uit web.config). De foutmelding sla ik op in een sessie variabele, en doe een Server.Transfer naar de algemene foutmeldings pagina errorpage.aspx. Hier lees ik de foutmelding uit en toon hem.

Ik gebruik dus niet de functionaliteit van <customerrors> uit de web.config ... (ik weet niet of dit de voorkeur heeft boven application_error... De foutmelding wordt toch ook helemaal niet uitgelezen?! lijkt mij een beetje onhandig)

Verder snap ik niet waarom ik ook nog try, catch blokken moet gebruiken in de code zelf. Het is netter, ik kan alleen niet uitleggen waarom. Ik neem aan dat alle plaatsen waar error handling mogelijk is elkaar overlappen. Dat dus page_error alle foutmeldingen van de pagina afvangt, en application_error alle foutmeldingen van alle pagina's, etc.

Ik weet ook dat de "kosten" qua performance redelijk hoog zijn. Dus dat waar een if-statement voldoende is, geen try catch blok gebruiken. En misschien dat als ik het helemaal netjes wil doen, ik een error manager moet schrijven, die ik in mijn nieuwe projecten kan includen.

[whoami]

Application_Error zou ik gebruiken voor error's die je anders niet hebt opgevangen.

Try / catch blokken kan je gebruiken om ervoor te zorgen dat, indien er een exceptie optreedt, je die exceptie op een goede manier kan afhandelen, en er evt. voor zorgen dat je applicatie verder kan.
Het throwen van exceptions is idd duur, en dat moet je dus niet gebruiken als je mbhv een if een bepaalde situatie kunt omzeilen.

Om het wegschrijven van exceptions/error gecentraliseerd te houden, zou ik trouwens ook een class schrijven die dit op zich neemt. Van die class kan je ook een singleton maken, zodanig dat je gewoon dit kunt doen:

code:

try
{
}
catch( Exception ex )
{
   ExceptionManager.Instance.LogException ( ex );
}

Om die errors naar verschillende 'loggers' weg te schrijven, kan je dan een IExceptionLogger interface maken, en dan maak je classes die deze interface implementeren. Deze classes zorgen er dan voor dat de fouten naar de betreffende 'logger' worden geschreven:

code:

ExceptionManager.ExceptionLoggers.Add (new EventLogExceptionLogger());
ExceptionManager.ExceptionLoggers.Add (new TextFileExceptionLogger());

Waarbij EventLogExceptionLogger en TextFileExceptionLogger dus die IExceptionLogger interface implementeren.

Ik zou trouwens, waar je ook kunt, gebruik maken van Try/Catch/Finally blokken. Ik zou zelf die Application_Error en Page_Error als laatste 'opvangnet' zien.

[CaptBiele]

tnx voor je duidelijke uitleg. Ik heb nog geen ervaring met interfaces maken en implementeren, maar daar ga ik zeker induiken.

whoami schreef op maandag 21 maart 2005 @ 20:14:
Application_Error zou ik gebruiken voor error's die je anders niet hebt opgevangen.

Try / catch blokken kan je gebruiken om ervoor te zorgen dat, indien er een exceptie optreedt, je die exceptie op een goede manier kan afhandelen, en er evt. voor zorgen dat je applicatie verder kan.

Kan ik de exceptions niet goed afhandelen vanuit de application_error? wat is precies het verschil met de try / catch blokken

Verder ben ik benieuwd wanneer iemand de <customerrors> sectie van de web.config gebruikt. Ik zie het veel in voorbeelden terug komen, maar snap het verschil niet met application_error..

[Woy]

Het verschil met try catch blokken is dat je er de mogenlijkheid verwacht van een fout. Dan kan je die fout daar nog oplossen. Dus bijvoorbeeld het volgende stukje code

C#:

try
{
    DoSomething();
}
catch( MyException ex )
{
    HandleError( ex );
}
//Ga gewoon verder met je programma

Er zijn namelijk best dingen waar een exception kan optreden terwijl dit niet het einde van de flow van je huidige proces in hoeft te houden. Met een Try/Catch/Finaly block kan je dan het probleem gewoon oplossen. In je Application_Error kun je hoogstens ergens wegschrijven dat er wat mis is gegaan.

Je moet dus proberen zoveel mogenlijk exceptions af te vangen en op te lossen. Uiteindelijk hou je altijd een aantal exceptions over waar je niks mee kan. Deze kan je idd mooi op laten vangen door je Application_Error of door je eigen Exception Http Module

[CaptBiele]

rwb schreef op maandag 21 maart 2005 @ 21:22:
Er zijn namelijk best dingen waar een exception kan optreden terwijl dit niet het einde van de flow van je huidige proces in hoeft te houden. Met een Try/Catch/Finaly block kan je dan het probleem gewoon oplossen.

potverdikkie, zo simpel is het inderdaad. Dat de flow dan niet hoeft op te houden... duh!

Ben ik alleen nog nieuwsgierig naar het gebruik van de <customerrors> sectie van web.config....

[Woy]

CaptBiele schreef op maandag 21 maart 2005 @ 22:57:
[...]


potverdikkie, zo simpel is het inderdaad. Dat de flow dan niet hoeft op te houden... duh!

Ben ik alleen nog nieuwsgierig naar het gebruik van de <customerrors> sectie van web.config....

customerrors heb ik zelf nog nooit gebruikt maar wat ik me volgens mij herinner is dat je daar verschillende types exception aan kan geven voor verschillend gedrag.

Stel je hebt SqlExceptions en je hebt MyCustomExceptions

bij de MyCustomExceptions kan je netjes naar een pagina toe linken waar de melding wordt gegeven dat er iets fout is gegaan.

Bij SqlExceptions wil je mischien wel dat er meteen een E-Mail verstuurd wordt omdat de database down is bijvoorbeeld.
Maar eigenlijk kan ik daar niet zoveel over zeggen omdat ik er nog nooit echt naar gekeken heb.

[Verwijderd]

Kijk ook eens naar het onderdeel "Exception Handling Application Block" van patterns & practices Enterprise Library.

[CaptBiele]

Verwijderd schreef op dinsdag 22 maart 2005 @ 00:13:
Kijk ook eens naar het onderdeel "Exception Handling Application Block" van patterns & practices Enterprise Library.

Ziet er erg interessant uit. Jammer dat ik me moet registreren om te downloaden...

[Verwijderd]

CaptBiele schreef op dinsdag 22 maart 2005 @ 12:55:
[...]


Ziet er erg interessant uit. Jammer dat ik me moet registreren om te downloaden...

Hotmail

[Verwijderd]

Met try&catch kun je trouwens nog meer doen dan enkel "de" execption op te vangen:

Visual Basic .NET:

Dim x,y as integer

Try
   x = CInt(Console.ReadLine())
   y = CInt(Console.ReadLine())
   Console.Writeline (x \ y)
Catch e As OverflowExecptiion
   ' Code om overflow te handlen
Catch e As DivideByZeroException
   '  Code om delen door 0 op te vangen
Catch e As Exception
   ' Code om alle andere fouten af te handele4n
Finally
   ' Iets wat je altijd uitvoert, no matter of voorgaande foutging
End try

[CaptBiele]

ok, je kunt verschillende exceptions opvangen, maar dat is niet zo spannend.
Het belangrijkste verschil is dat de flow gewoon doorloopt, zoals je ook code kan uitvoeren in de Finally.