.NET, Archive, Software Design

Software Design Tip of the Fortnight: Tip #2

Jason / December 20, 2008

For this second installment of Software Design Tip of the Fortnight I want to talk a little about exceptions. Exceptions in .NET provide an excellent means of handling errors. We all know not to use exceptions for flow control, but there are many other ways to abuse exceptions.

Abusing exceptions can be anything from throwing the base Exception class, to throwing more than just exceptions. But the most common abuse of exception handling is to simply suppress them. We have all seen applications that do something similar to:

SomeBusinessObject bo = SomeBusinessObject.LoadWithId(4);
try{
    bo.SomeIntValue = int.Parse(txtSomeTextField.Text);
}catch{
   //the value wasn't int... so ignore it.
}
bo.Save();

The problem with suppressing exceptions is that most components don’t just throw them for the fun of it, there is some underlying reason why the exception was thrown in the first place.

The above example appears innocent enough. Int32’s Parse method throws an exception if it cannot parse the input string. But what if in the future another developer decides that the business object’s SomeIntValue needs a certain business rules that limits the acceptable values.

public class SomeBusinessObject{ //other class code public int SomeIntValue{ get{ return _someIntValue; } set{ if(value < 0) throw new BusinessRuleException("Invalid value for SomeIntValue."); _someIntValue = value; } } } read more

.NET, Archive, Software Design

A Generic Error Occurred in GDI+

Jason / October 14, 2008

You know you’re doing good when your application crashes with an exception as detailed as “a generic error occurred in gdi+”. That is about as, well generic, as it gets :- )

In my particular case I was constructing an Image down in my DAO using the FromStream method, like so:

Image result;
using (FileStream file = File.OpenRead(filename)) {
	result = Image.FromStream(file);
	file.Close();
}
return result;

I was doing this so that I could know for a fact that the file was being disposed of properly. I didn’t want to have any orphaned file references locking up the file in case I later needed to delete it.

The problem was that up in my UI I was attempting to call the Save method on Image to dump its contents out to the ASP.NET response stream, like so:

img.Save(HttpContext.Response.OutputStream, ImageFormat.Jpeg); read more

Archive, C#, Software Design

Testing Software Contracts Using ContractTest

Contracts, both explicit and implied, are key in designing a working software system. An example of an explicit contract in C# would be the implementation of an interface, while an implied contract would be something along the lines of all business objects have default constructors. Contracts of both types are critical to the success of a software system, but how do you test for and enforce these contracts?

Explicit contracts are often enforced by the compiler and are not nearly as fragile as implied contracts. Using the ContractTest testing framework you can write test cases for many common implied contracts. You can incorporate ContractTest assertions directly into your existing unit tests. For the following examples I will be using NUnit syntax, but you could use most any other unit test framework.

For example, assume you want to test for the presence of a publicly accessible default constructor on one of your business objects. Such a test using ContractTest would look like.

using ContractTest.Assertions; using NUnit.Framework; using MyNamespace.BusinessObjects; [TestFixture] public class SampleTests{ [Test] public void Test1(){ ContractAssert.Type.HasPublicDefaultConstructor<BizObjectA>(); } } read more

.NET, Archive, Software Design

The Wonders Of InternalsVisibleTo

Jason / November 8, 2007

I do not know how I missed this, but just today I found out that you can expose an assembly’s internal methods/properties/classes to a "friend" assembly. Normally internals are only accessible to members of the same assembly, and are often used to hide "plumbing" methods and utilities classes.

For many reasons you often want to separate your code into multiple assemblies, perhaps one for each application layer or some other logical boundary. A problem arises when two or more assemblies need access to each others internals. Prior to .NET 2.0 you had two choices, either expose these plumbing methods as public, or lump as much of your code into one assembly as was needed to keep the plumbing internal.

In comes .NET 2.0’s InternalsVisibleTo attribute. This attribute is applied on the assembly level, and allows the assembly to give internal access to specific assemblies.

For example:

Say you have two assemblies, MyExample.DomainObjects & MyExample.ServiceLayer. In the DomainObjects assembly you have the following abstract class:

namespace MyExample.DomainObjects{
public abstract class DomainObject{
//.... other things....
public virtual DateTime LastModifiedDate{
get { ... }
internal set { ... }
}
}
}
read more