Pozdrav!
Zanima me kako djeluje hvatanje generalnog Exceptiona na performanse programa (ukoliko se u catch dijelu ne radi nista posebno) u usporedbi s hvatanjem mogucih izvedenih iznimaka?
Pa ako imatko strucan da nabaci koju rijec na tu temu...
Očito, isti klinac. Iznenađujuće.
static void Main(string[] args)
{
List<double> run1 = new List<double>();
List<double> run2 = new List<double>();
for(int runs = 0; runs<=10; runs++)
{
Stopwatch timer = new Stopwatch();
try
{
timer.Start();
for (int i = 0; i <= 10000; i++)
{
//Thread.Sleep(1);
if (i == 50)
{
throw new FileNotFoundException();
}
}
}
catch (Exception ex)
{
Console.WriteLine("Exception");
}
timer.Stop();
Console.WriteLine("End of run1: " + timer.ElapsedMilliseconds + " ms");
run1.Add(timer.ElapsedMilliseconds);
timer = new Stopwatch();
try
{
timer.Start();
for (int i = 0; i <= 10000; i++)
{
//Thread.Sleep(1);
if (i == 50)
{
throw new FileNotFoundException();
}
}
}
catch (FileNotFoundException ex)
{
Console.WriteLine("FileNotFoundException");
}
timer.Stop();
Console.WriteLine("End of run2: " + timer.ElapsedMilliseconds + " ms");
run2.Add(timer.ElapsedMilliseconds);
}
var avrg1 = run1.Average();
var avrg2 = run2.Average();
Console.WriteLine("---------------------------");
Console.WriteLine("Average for run1: " + avrg1);
Console.WriteLine("Average for run2: " + avrg2);
Console.ReadKey();
}
I rezultat:
Exception
End of run1: 5 ms
FileNotFoundException
End of run2: 4 ms
Exception
End of run1: 4 ms
FileNotFoundException
End of run2: 4 ms
Exception
End of run1: 4 ms
FileNotFoundException
End of run2: 4 ms
Exception
End of run1: 4 ms
FileNotFoundException
End of run2: 4 ms
Exception
End of run1: 4 ms
FileNotFoundException
End of run2: 4 ms
Exception
End of run1: 4 ms
FileNotFoundException
End of run2: 4 ms
Exception
End of run1: 4 ms
FileNotFoundException
End of run2: 4 ms
Exception
End of run1: 4 ms
FileNotFoundException
End of run2: 4 ms
Exception
End of run1: 4 ms
FileNotFoundException
End of run2: 4 ms
Exception
End of run1: 4 ms
FileNotFoundException
End of run2: 4 ms
Exception
End of run1: 4 ms
FileNotFoundException
End of run2: 4 ms
---------------------------
Average for run1: 4,09090909090909
Average for run2: 4
I nešto na stacku o tome. Što se tiče samog .neta i brzine, svejedno ali što se tiče samog razvoja, bolje je hvatati pojedinačne i eventualno, cijelu funkciju utrpati u try...catch i hvatati generički Exception ako nam "pobjegne".
Pozdrav!
Zanima me kako djeluje hvatanje generalnog Exceptiona na performanse programa (ukoliko se u catch dijelu ne radi nista posebno) u usporedbi s hvatanjem mogucih izvedenih iznimaka?
Pa ako imatko strucan da nabaci koju rijec na tu temu...
Mislim da krivo shvaćaš što je Exception handleing (EH).
"Običan" Exception naspram ostalih exceptiona je samo bazična klasa naspram nasljeđene klase, te shodno time preformanse samog handlanja exceptiona ne bi smjele biti ništa različite. Čak i da jesu drastično u jednom ili drugom smjeru to nas ne bi smjelo zabrinjavati.
Paonta EH-a je da za uhvatiš točno određenu stvar i pokušaš što mirnije (gracefully) ju obraditi. Primjerice (dajem čisto hipotetski primjer)
try
{
AccessResource();
}
catch(ResourceNotFoundException ex)
{
Log.Write("Resource Not Found");
TryCreateResource();
}
catch(ResourceTimeOutException ex)
{
Log.Write("Resource Timed Out");
throw;
}
Ukoliko znamo koji se Exception dogodio možemo adekvatno reagirati - u ovom slučaju primjerice sa TryCreateResource(). Međutim ukoliko je pristup time outao, tu jednostavno samo želimo logirati i proslijediti Exception drugom layeru (exception bubbling).
Međutim, ako primjerice krenemo loviti sve sa samim Exceptionom (bazom), teško da možemo što u catch bloku napraviti
try
{
AccessResource();
}
catch(Exception ex)
{
Log.Write("Oooh oooh, something went wrong????")
//What to do? What to do?
throw;
}
"Običan" exception se može loviti ili na vršom dijelu aplikacije (entry point) da se ulove svi ne-hendlani exceptioni (zapišeš u log, pokušaš počistiti za sobom, obavjestiti korisnika da se nešto loše dogodilo i eventualno kontrolirano spustiti aplikaciju) ili na kraju povezanih Exceptiona kao safe net i možda još koji edge case.
Ukratko, ako se brineš o preformansama EH-a, to najčešće znači da je problem u dizajnu. EH se nikada ne smije koristiti kao flow kontrola i u pravilu, ukoliko sve ide "po planu" kod nikada niti neće ući u catch i time inicirati EH (naravno, ništa nejde po planu zato i iimamo EH).
Exception throwing / catching je poprilično skupa operacija, međutim, sve dokle se ne throwa / catcha ništa, kod će imati istu brzinu kao da niti nema try/catch oko sebe.
