Foundations of Programming - Karl Seguin

Chapter 8 - Back to Basics: Exceptions
Many of the exceptions I create are nothing more than marker exceptions - that is, they extend the base
System.Exception class and don't provide further implementation. I liken this to marker interfaces
(or marker attributes), such as the INamingContainer interface. These are particularly useful in
allowing you to avoid swallowing exceptions. Take the following code as an example. If the Save()
method doesn't throw a custom exception when validation fails, we really have little choice but to
swallow all exceptions:
try
{
user.Save();
}
catch
{
Error.Text = user.GetErrors();
Error.Visible = true;
}
//versus
try
{
user.Save();
}
catch(ValidationException ex)
{
Error.Text = ex.GetValidationMessage();
Error.Visible = true;
}
The above example also shows how we can extend exceptions to provide further custom behavior
specifically related to our exceptions. This can be as simple as an ErrorCode, to more complex
information such as a PermissionException which exposes the user's permission and the missing
required permission.
Of course, not all exceptions are tied to the domain. It's common to see more operational-oriented
exceptions. If you rely on a web service which returns an error code, you may very wrap that into your
own custom exception to halt execution (remember, fail fast) and leverage your logging infrastructure.
Actually creating a custom exception is a two step process. First (and technically this is all you really
need) create a class, with a meaningful name, which inherits from System.Exception.
public class UpgradeException : Exception
{
}
You should go the extra step and mark your class with the SerializeAttribute and always provide
at least 4 constructors:
Foundations of Programming Copyright © Karl Seguin www.codebetter.com
70