Exceptional Logic

I’ve always felt that using exception handling for “normal” programming logic is a bit…dirty. Take the Access database I inherited at work for example. There are several UI modules in separate MDB files for various tasks like running reports, entering customers, sending mass mailings, etc. When one module needs to activate another module, the most straightforward method would be to check if the new module already open, then either open it or switch to the already open window. Instead, it blindly attempts to switch to the window and if there’s an error, it launches the module.

This is especially bothersome in VBA (Access’ scripting language) due to the way Basic handles errors. When you set an error handler (really just a glorified goto), all errors end up at the same point in your code, usually at the end of the function. This means that the code which launches a new window isn’t anywhere near the code that tries to switch to an existing window. I nearly gouged my eyes out when I first came across this.

And then there’s debugging… The Visual Basic debugger allows you to break on all exceptions whether handled or not. This comes in handy if you have a generic error handler which doesn’t provide enough information to track down the cause. By breaking on all exceptions you can find out exactly where the exception occurs and inspect the surrounding code. But if you are trying to debug code that activates another module, you’ll never be able to get past the initial exception when the module isn’t open.

That being said…

Here’s a really simple way to validate an e-mail address in .NET—no Regular Expressions or manual string parsing required:

try
{
  var test = System.Net.Mail.MailAddress(emailAddress);
}
catch (Exception)
{
  // email is invalid
}