Tuesday, April 24, 2007

Books: Developing More-Secure Microsoft® ASP.NET 2.0 Applications

Great, great, great book. Despite the title it doesn't stop on security topics exclusively, but analyzes the important entrails of ASP.NET - pipelines, meaning of events, workflows. It will bring all the stuff together and organize your ad-hoc knowledge.

All possible authorization and authentication scenarios reviewed, including the very common mixed authentication with internal and external users, which I haven’t seen described too often. Great tips and trick with detailed instructions are mixed with high-level architecture overviews. Interestingly, book avoids describing the Profile mechanism. Microsoft did lousy job porting this functionality from the icky Web Site to the Web Application projects and using Profile capabilities requires extra efforts.

This book is strongly recommended for good .NET developers who want to become great .NET developers.

Tuesday, April 10, 2007

Benchmarking .NET: Try-Catch vs. TryParse

Inspired by Scott Hanselman article about careful exception handling I decided to investigate the price of catching cast errors. For comparison I chose a TryParse method, which was implemented by .NET 2.0 in all basic types instead of just double in version 1.1.

I wrote small test runner (and practiced generics and delegates along the way). The following two methods were tested:

private static void ConvertTo_Integer__TryParse(string input)
{
int result;
bool success;
success = Int32.TryParse(input, out result);
}

private static void ConvertTo_Integer__TryCatch(string input)
{
int result;
bool success;
try
{
result=Int32.Parse(input);
}
catch
{
success = false;
}
}
Successful operations at no surprise are pretty fast and equal in performance. But in the failure case the traditional try-catch handling is more pricey.

What would happen if there are more operations, like – 1000 of them? Difference is more visible:

In database-related applications a 1000 parse operations in a row are very common. While DateTime.Parse seems to be capable of better performance than Convert.ToDateTime (as latter uses Parse deep inside), the price of a try-catch eats the advantages anyway.

Those are result for Integer and DateTime parsing as a graph:


© 2008-2013 Michael Goldobin. All rights reserved