Oct 27 2006
I recently wanted to have a method I could call to get a type-safe AppSetting, with an optional default value if the AppSetting wasn’t set. In C# 2.0, I came up with this:
public static T GetSetting<T>(string name, T defaultValue)
{
string input = ConfigurationManager.AppSettings[name];
if (input != null)
{
return (T)Convert.ChangeType(input, typeof(T));
}
else
{
return defaultValue;
}
}
Oct 01 2006
Mark came up with an idea to use Enums to drive lookups. I told him I could go one better by providing user-friendly names instead of programmer-friendly enum value names. The idea is to loop through the literal fields of the enum type and check for a DescriptionAttribute on each field. Anyway, here’s the source, with caching for top performance.
Apr 08 2006
A few new features added to the open source url rewriter, including:
Download UrlRewriter.NET 1.6 here.
Mar 11 2006
The TestDriven.NET tool is fantastic. I love the agility it gives you, as you can quickly build your unit tests, write your code and at a right-click, you can run your unit tests from Visual Studio.
One of the problems it currently has (I notice somebody has asked for this in their wishlist) is custom configuration. If the code you’re testing requires settings that would normally be in your web.config or App.config file, you have to ensure these settings are in a file called <your-assembly-name>.dll.config in your bin\Debug directory. A bit inconvenient. NUnit allows you to have a .config file in the root of your project with the same name as your project (e.g., Foo.Bar.config), so why should you do without this feature in Visual Studio?
Well, until the author adds this enhancement (hopefully soon), one workaround I’ve come across for this is to create a Post-Build event in Visual Studio.NET, which copies the config file from the root of your project to the required place in your bin directory.
To set this up, right-click Properties on your Project in Visual Studio.NET. Under Common Properties, click on Build Events. In the Post-build Event Command Line property, add the following: copy $(ProjectDir)$(ProjectName).config $(TargetPath).config
Then, whenever you have a successful build, your latest config changes will be available to TestDriven.NET’s in-built TestRunner.
Nov 30 2005
An article on MSDN published a quick roundup of ten tips for achieving high-performance in your ASP.NET web application:
This is a great list. We’re running 9/10 on this (we don’t cache page output because everything is dynamic), and the web servers are pretty much idling most of the time.
Nov 18 2005
Quite often when developers are developing ASP.NET applications and they’ve added exception handling, they will have some code like the following:
try
{
...
Response.Redirect("/default.aspx", true);
}
catch (Exception exc)
{
... // proper exception handling.
}
Funny thing is, many developers don’t realise it, but Response.Redirect throws a ThreadAbortException, which gets caught by the catch filter.
What’s the right way to handle this? I can outline three ways, each of which may be applicable in a given scenario:
try
{
...
Response.Redirect("/default.aspx", true);
}
catch (ArgumentOutOfRangeException exc)
{
... // proper exception handling.
}
try
{
...
Response.Redirect("/default.aspx", true);
}
catch (ThreadAbortException)
{
throw;
}
catch (Exception exc)
{
… // proper exception handling.
}
Hope that’s answered “why am I getting a ThreadAbortException?” and given you some ideas of how to work around it.
ASP.NET, web development, exception management
Nov 18 2005
I really love code reviews where I tell developers that they need to better plan for and handle exceptions, and in the followup code review, they present the following:
try
{
// do some dangerous stuff that may throw an exception.
}
catch (Exception e)
{
throw (e);
}
My usual reaction is to grit my teeth, administer an icy stare and ask a calm, measured question: “And what exactly, are you aiming to accomplish here? (besides, of course, losing your stack trace and the real source of the exception)”.
The problems I have with this “pattern” are many:
throw(e);. The stack trace now points directly to this line, so you no longer know the real culprit.When I’ve finished with the code review, the above code is usually refactored into one of two forms:
// do some dangerous stuff that may throw an exception.
try
{
// do some dangerous stuff that may throw an exception.
}
catch (InvalidOperationException e)
{
throw MyFacadeException("There was a problem doing the dangerous thing.", e);
}
There are plenty of exception management best practices, but I typically use the following simple rules:
throw; instead of throw(e);.throw;, not throw (e);). This is useful if you need to handle some more generic exceptions, but you want to bubble some more specific exceptions.* Some obscure runtime exceptions actually don’t inherit from Exception, and these get caught in the following code:
try
{
...
}
catch
{
...
}
exceptions, code reviews, quality, wtf
Recently Shared
