[.NET] Uit een bestaande applicatie errors tracen

[Sybr_E-N]

Momenteel ben ik bezig met bug hunting in een reeds bestaande webapplicatie. Nou is het zo dat de architectuur van die applicatie wat te wensen over laat. Hierdoor is het een en ander (lees alles) slecht opgezet. Rarara nu heeft men last van serieuse performance problemen.

Een van de zaken die bijvoorbeeld niet (goed) zijn geimplementeerd is een degelijke error afhandeling.

Laat ik het zo zeggen error's worden te pas en te onpas gebruik als programflow.

Voorbeeld:

C#:

try {
  Convert.ToInt32(inputString);
  return true;
} catch {
  return false;
}

Dit soort grappen en grollen zit lekker diep verweven in de hele applicatie. Nu weet bijna iedereen
dat error's throwen een dure aangelegenheid is, en performancewise gezien kan het de applicatie helpen om de meeste van deze zaken aan te passen. Nu was ik van plan om eens uit te zoeken hoeveel en wat voor soort Error's er nou door de hele applicatie worden gethrowed, zowel handled als unhandled exceptions. Dit scheelt mij weer gigantisch veel uitzoek werkt hoevaak bepaalde methoden worden aangeroepen enzo.

Omdat het een bestaande applicatie is en dermate groot is het niet mogelijk om bijvoorbeeld overal debug informatie toe te voegen.

Na wat spelen met Microsoft Application Center Test, kon ik al achterhalen hoeveel error's er gethrowed worden via de performance counters. (duizenden in een korte stress-test). Maar deze informatie is mij veel te beperkt, ik wil ook weten welke error's dat waren en het liefst ook waar in de code het gebeurd.

Mijn vraag:
Nu wil ik op een relatief simpele manier alle error's te voorschijn toveren, maar hoe pak ik dat aan? Het enige wat ik tot nu toe tegen ben gekomen zijn stukken source code waarbij je als nog in de source code moet lopen grutten, of voor (meestal) nieuw op te zetten applicaties.

[Vedett.]

Ik weet niet of dat gaat, maar ben er wel zeer benieuwd naar.

[gorgi_19]

afaik worden die errors netjes afgevangen door je exception, dus zie je ze niet meer verder Maar wat een oplossing voor je voorbeeld... Double.TryParse is bijvoorbeeld daar al wat netter

[Sybr_E-N]

gorgi_19 schreef op vrijdag 17 maart 2006 @ 11:15:
afaik worden die errors netjes afgevangen door je exception, dus zie je ze niet meer verder Maar wat een oplossing voor je voorbeeld... Double.TryParse is bijvoorbeeld daar al wat netter

I know. (Hier loopt ook zo'n topic met slechte code voorbeelden, ik kan je vertellen daar past deze applicatie in z'n geheel in.)

Weet je zeker dat je ze niet ergens naar toe kan loggen? Dat zou jammer zijn.

Maar ik wil wat hardere bewijzen op tafel hebben, en dan op een later tijdstip jouw voorbeeldoplossing kan worden geimplementeerd. Maar alleen zeggen, ja het 'fout' gaat het niet redden vandaar dit topic.

[Vedett.]

Is misschien een find en replace op

catch()
{

naar

catch(Exception ex)
{
Reference.To.MyLogger.LogErrorMessage(this,ex)

geen idee ???

[Sybr_E-N]

Vedett. schreef op vrijdag 17 maart 2006 @ 11:37:
Is misschien een find en replace op
geen idee ???

Dat is te veel werk. Dan moet ik dezelfde code straks twee keer aanpassen, en dat me 1 keer teveel. 1x om loginformatie toe te voegen, en 1x om al die try/catch statements eruit te slopen.

[Verwijderd]

Kan je niet debugging vanuit de ontwikkelomgeving? Vaak kan je excepties e.d. wel loggen naar de console.

Mocht dat niet kunnen om 1 of andere reden en het is managed code dan moet je eens hier kijken: http://msdn.microsoft.com...timedebuggercordbgexe.asp

Je kan namelijk die command-line debugger 'attachen' aan het process en dan laten stoppen op het moment dat je een exceptie krijgt (unhandled/handled). Het probleem is dan alleen dat je programma dan dus stopt. Maar misschien dat je met scriptjes o.i.d. wel automatisch kan loggen en verder kan gaan (zal natuurlijk wel een onwaarschijnlijk grote performance hit geven).

Als laatste zou je je eigen debugger kunnen klussen die dit automatisch doet. Zie voor een voorbeeld in VB bijv. http://www.codeguru.com/v.../win32/article.php/c7525/

[ Voor 4% gewijzigd door Verwijderd op 17-03-2006 12:14 ]

[giMoz]

misschien dat je hier wat aan hebt:
http://www.eggheadcafe.com/articles/20060305.asp

en denk ik nog meer hier aan:
http://www.eggheadcafe.com/articles/20030816.asp

de laatste beschrijft een manier om alle errors die optreden te loggen...
Maar ik weet niet hoe dit gaat met handled exceptions.. volgens mij zijn die niet te loggen...


Misschien gewoon op de code een search for: "try{"??

[ Voor 65% gewijzigd door giMoz op 17-03-2006 12:36 . Reden: extra info ]

[Verwijderd]

giMoz schreef op vrijdag 17 maart 2006 @ 12:34:
Maar ik weet niet hoe dit gaat met handled exceptions.. volgens mij zijn die niet te loggen...

Ja dat kan wel. De debugger krijgt namelijk altijd de eerste kans om de exceptie af te handelen. Vandaar ook mijn voorstel om een debugger te 'attachen' aan dat proces. Als de debugger er verder niets mee doet dan wordt er een lijst van exceptie handlers afgelopen net zo lang totdat er een geschikte handler is gevonden. Elk try/catch block voegt z'n eigen handler toe aan die lijst. Althans, zo is het in C++ geimplementeerd, maar ik kan me voorstellen dat het bij C# wel ongeveer hetzelfde werkt.

Lees anders eens:
http://www.codeproject.com/cpp/exceptionhandler.asp
http://www.gamedev.net/reference/articles/article1272.asp
http://msdn.microsoft.com/msdnmag/issues/01/09/hood/

[kenneth]

Geen antwoord op je directe vraag, maar is het niet handiger om te profilen, en stapsgewijs de grootste bottlenecks te refactoren? In plaats van per type anti-pattern de hele applicatie door te wandelen.

[Sybr_E-N]

Verwijderd schreef op vrijdag 17 maart 2006 @ 11:51:
Kan je niet debugging vanuit de ontwikkelomgeving? Vaak kan je excepties e.d. wel loggen naar de console.

Mocht dat niet kunnen om 1 of andere reden en het is managed code dan moet je eens hier kijken: http://msdn.microsoft.com...timedebuggercordbgexe.asp

Je kan namelijk die command-line debugger 'attachen' aan het process en dan laten stoppen op het moment dat je een exceptie krijgt (unhandled/handled). Het probleem is dan alleen dat je programma dan dus stopt. Maar misschien dat je met scriptjes o.i.d. wel automatisch kan loggen en verder kan gaan (zal natuurlijk wel een onwaarschijnlijk grote performance hit geven).

...

Kijk dit is nou precies wat ik zoek. Ik kan in Visual Studio wel gewoon debuggen, ook kan je er alle exceptions mee afvangen maar dat is dan ook alles. Bij elke exceptie springt ie naar de debugger en meer niet.

Nu heb ik even die cordbg.exe uitgeprobeerd. Hiermee is het mogelijk om een debugger aan je running ASP.NET proces te hangen, nu wordt dan elke exceptie naar console weggeschreven. Ik zie nu bijvoorbeeld allerlei exceptie's op me afkomen. Moet nog wat dingen uitzoeken om bijvoorbeeld ook de stacktrace's er uit te krijgen, en het liefst is een file'tje ofzo.

Ook handig is dat het een sample debugger is van Microsoft, die de Debug API van .NET gebruikt. Via de .NET SDK wordt ook de source (c++) van deze applicatie geleverd.

kenneth in "[.NET] Uit een bestaande applicatie erro..."
Inderdaad, ook profilen is een optie om het een en ander op te sporen. Ik heb tot nu toe nprof, Micorsoft CLR profiler en .NET memory profiler gebruikt. Die laatste kost een paar centen, maar er is een 14 dagen full trial van te gebruiken. Alleen die geeft zoveel specifieke info, dat ik er in een korte tijd weinig raadt mee weet. Is wel iets voor de toekomst om het een en anders eens uit te zoeken.
Nprof is al twee jaar in een alpha stadium, en heeft wat bug betreffende ASP.NET profiling. Die CLR profiler geeft veel info, maar niet dat wat ik moet hebben.

[Mastermind]

Het zal je denk ik niet meevallen alle try-catches eruit te halen en het programma werkend te houden.
Je voorbeeldmethod

C#:

public bool IsConvertableToInt(String str)
{
try {
  Convert.ToInt32(str);
  return true;
} catch {
  return false;
}
}

wordt ergens aangeroepen en die verwacht een true of false. Dus al die aanroepen zul je moeten refactoren.
Kun je natuurlijk die method herschrijven als:

C#:

public bool IsConvertableToInt(String str)
{
str = str.TrimStart(" "); // verwijder evt. spaties in het begin
for (int i = 0, i < str.Length, i++)
{
//is de ASCII code niet 48 t/m 57 (dit is "0" t/m "9") of 45 "-"-teken.
if ((str[i] < 48 || str[i] > 57) && (str[i] != 45 && i ==0)) 
  return false; //ongeldige char gedetecteerd (geen cijfer of minteken)
}
return true;
}

En zo zul je nog een aantal dingetjes moeten veranderen, denk ik

[ Voor 55% gewijzigd door Mastermind op 19-03-2006 10:32 ]

[kenneth]

Uhhh, Mastermind

gorgi_19 schreef op vrijdag 17 maart 2006 @ 11:15:
Double.TryParse is bijvoorbeeld daar al wat netter

[Mastermind]

Dat werkt volgens mij niet bij integers.
Edit: int kent geen TryParse method zie ik idd. double wel.

[ Voor 119% gewijzigd door Mastermind op 19-03-2006 00:24 ]

[gorgi_19]

Mastermind schreef op zondag 19 maart 2006 @ 00:18:
Dat werkt volgens mij niet bij integers.
Edit: int kent geen TryParse method zie ik idd. double wel.

Dan moet je de goede numberstyles parameter meegeven

En volgens mij is in jouw code:

-1-2334 een geldige int

[ Voor 11% gewijzigd door gorgi_19 op 19-03-2006 09:24 ]

[Sybr_E-N]

Mastermind schreef op zondag 19 maart 2006 @ 00:00:
En zo zul je nog een aantal dingetjes moeten veranderen, denk ik

Die hele app zal opnieuw in elkaar geklust moeten worden. Het is meer om de huidige app draaibaar te houden. Maar ik ga iig niet zelf deze functies schrijven, als het al in .NET zit

Maar met behulp van Lutz Loeder's Reflector kun je tegenwoordig al snel zien hoevaak bepaalde methoden worden aangeroepen en welke dat zijn. Dat is handig om te inventariseren of het wel of niet handig is om op korte termijn dit soort convert methoden te refactoren.