For some time now, I have been using a pattern I call “Common Function Result” to deal with errors and return values from functions. When I first learned about .Net and learned about try/catch blocks, I thought they were great. I thought they were leaps and bounds above the classic VB OnError mechanism, but they still didn’t solve all my problems. I wanted a cleaner way to get the error information from the function back to the caller. After some trial and error I came up with this class: 

   1: public class FunctionResult<returnType>
   2: {
   3:  
   4: #region Properties
   5:  
   6: #region "ExceptionVal"
   7:  
   8: private Exception _exceptionVal = null;
   9: /// <summary>
  10: /// Gets or sets the exception val.
  11: /// </summary>
  12: /// <value>The exception val.</value>
  13: public Exception ExceptionVal
  14: {
  15:     get
  16:     {
  17:         return this._exceptionVal;
  18:     }
  19:     set
  20:     {
  21:         this._exceptionVal = value;
  22:     }
  23: }
  24:  
  25: #endregion
  26:  
  27: #region "ReturnVal"
  28:  
  29: private returnType _ReturnVal = null;
  30: /// <summary>
  31: /// Gets or sets the return val.
  32: /// </summary>
  33: /// <value>The return val.</value>
  34: public returnType ReturnVal
  35: {
  36:     get
  37:     {
  38:         return this._ReturnVal;
  39:     }
  40:     set
  41:     {
  42:         this._ReturnVal = value;
  43:     }
  44: }
  45:  
  46: #endregion
  47:  
  48: #region "ResultType"
  49:  
  50: private FunctionResultTypes _ResultType = null;
  51:  
  52: /// <summary>
  53: /// Gets or sets the type of the result.
  54: /// </summary>
  55: /// <value>The type of the result.</value>
  56: public FunctionResultTypes ResultType
  57: {
  58:     get
  59:     {
  60:         return this._ResultType;
  61:     }
  62:     set
  63:     {
  64:         this._ResultType = value;
  65:     }
  66: }
  67:  
  68: #endregion
  69: #endregion
  70:  
  71: }
  72: #region Supporting Classes
  73:  
  74: /// <summary>
  75: /// List of possible errors that can be return from a function result
  76: /// </summary>
  77:  
  78: public enum FunctionResultTypes
  79: {
  80:     /// <summary>
  81:     /// The function result was sucessful.
  82:     /// </summary>
  83:     NoErrors = 1,
  84:     
  85:     /// <summary>
  86:     /// The function result encountered validation errors.
  87:     /// </summary>
  88:     ValidationErrors = 2,
  89:  
  90:     /// <summary>
  91:     /// The function result encountered unexpected errors.
  92:     /// </summary>
  93:     OtherErrors = 3
  94:  
  95: }
  96:  
  97: #endregion

This class is the heart of the pattern. Instead of returning the actual result type from a function I am writing like string or int, I return this class which has these three properties: ResultType, ReturnVal, and ExceptionVal. For instance, let’s say I am writing the following function: 

   1: public int divideSomeNumbers(int numberOne, int numberTwo)
   2: {
   3:     if (numberOne == 0 || numberTwo == 0)
   4:     {
   5:         throw new Exception("Value can't be zero");
   6:     }
   7:  
   8:     return numberOne / numberTwo;
   9: }

This function is pretty simple; it takes two numbers and divides them, it also does some error checking to make sure that neither of the passed in numbers is zero. To let the caller know that one of the numbers that was passed in is equal to zero, it throws an exception. To make this function use the pattern I would rewrite it like this:

   1: public FunctionResult<int> divideSomeNumbers(int numberOne, int numberTwo)
   2: {
   3:     FunctionResult<int> ret = new FunctionResult<int>();
   4:  
   5:     try
   6:     {
   7:         if (numberOne == 0 || numberTwo == 0)
   8:         {
   9:             ret._ResultType = FunctionResultTypes.ValidationErrors;
  10:             ret._exceptionVal = new Exception("Value can't be zero");
  11:             return ret;
  12:         }
  13:  
  14:         ret._ReturnVal = numberOne / numberTwo;
  15:         ret._ResultType = FunctionResultTypes.NoErrors;
  16:  
  17:     }
  18:     catch(Exception e)
  19:     {
  20:         ret._exceptionVal = e;
  21:         ret._ResultType = FunctionResultTypes.OtherErrors;
  22:     }
  23:  
  24:     return ret;
  25:  
  26: }

The new version of the function always returns something to the caller so the caller does not need to worry about wrapping their call in a try/catch block; all they need to do is check the ResultType property and see if there was an error. If there was an error, the caller then has the option to retrieve the exception from the ExceptionVal property and do something with it, like display the error message. If there was not an error then the caller can use the ReturnVal property to get the actually function result. Since the ReturnVal property uses generics, the caller will get the strongly typed result back from the function. Here is an example of code to call the new version of the function:

   1: FunctionResult<int> ret = divideSomeNumbers(0, 1);
   2:  
   3: switch(ret.ResultType)
   4:  
   5: {
   6:  
   7:     case FunctionResultTypes.NoErrors:
   8:  
   9:         Console.Write(string.Format("The function result was {0}", ret.ReturnVal.ToString()));
  10:  
  11:         break;
  12:  
  13:     case FunctionResultTypes.ValidationErrors:
  14:  
  15:         Console.Write(string.Format("There was a validation error: {0}", ret.ExceptionVal.Message));
  16:     
  17:         break;
  18:  
  19:     case FunctionResultTypes.OtherErrors:
  20:  
  21:         Console.Write(string.Format("The function had an unexpected error: {0}", ret.ExceptionVal.Message));
  22:  
  23:         break;
  24:         
  25: }
  26: 

To me, the code above is cleaner and much easier to read. It also lets you handle different types of errors like validation and unexpected exceptions in a common way.