"Don't throw exceptions when you don't have to - it is expensive in managed world" - this is something that you will often hear or read. But developers often throw exceptions from middle-tier just to return appropriate message to the client. This article will show you an alternative way of returning formatted messages from middle-tier components to the client.
What's the catch?
This is the case that you might have already seen: You hava a Try..Catch block in a method for inserting data in one's middle-tier class. You catch SqlException and Exception classes. If any of them occurrs, you throw a custom exception (e.g. MyAppException) that inherits from ApplicationException with a message "Insert fails, blah, blah..". A method on the client will then catch MyAppException and display thea message. Look familiar?
This might not be a good solution even though it is used widely. So, what can we do different? Here, I'll try to offer an alternative way to throwing exceptions that will enable you to return messages, operation status and your custom objects.
Let's say that we have a BlogManager class in our middle-tier component, that has GetBlog method. This method has to return BlogPost class if opertaion against the database succeeds or return a message if the operation fails. So, we have three diferent object types that can be returned: BlogPost class, Message (string) and an indicator that will tell the client if the operation finished successfuly or not (bool). This implies that we can create a class (e.g. ResultSet class) that will have three properties: Message, OpertionSucceeded and Value (the last one will hold a BlogPost or any other class).
[
Serializable()]
public class ResultSet
{
public ResultSet()
{
this._HasSucceeded = true;
}
private Object value;
public Object Value
{
get { return value; }
set { value= value; }
}
private string message;
public string Message
{
get { return message; }
set { message = value; }
}
private bool operationSucceeded;
public bool OperationSucceeded
{
get { return operationSucceeded; }
set { operationSucceeded= value; }
}
}
Our GetBlog method will try to get the specified blog from a database. If opertaion succeeds, BlogBost will be returned and OpertionSucceeded indicatior will be set to True. Otherwise, nothing will be returned, OpertionSucceeded indicatior will be set to False, and we will send a user-friendly message to the client. The exception will be logged to the database.
public ResultSet GetBlog(int blogID)
{
BlogDao blogDao = new BlogDao ();
ResultSet result = new ResultSet();
try
{
result.Value = blogDao.GetByID(blogID);
}
catch (SqlException ex)
{
ExceptionManager.LogException(ex);
result.Message = "An error occurred while trying to
get the blog post from the database.";
result.HasSucceeded = false;
}
return result;
}
If this class is returned from GetBlog method, we will have all the information we need on the client. We would not need to catch any exceptions in the client methods. OpertionSucceeded indicator will tell us whether we have to show an error message or not. Value property will hold the object we need to parse and display. We would just have to cast to appropriate type.
Summary
You saw there could be an alternative to throwing exceptions from middle-tier components just to return error message to the client. Since this is just an idea, I would like to see your comments and thoughts on this.
Here are some useful links on asp.net performance/exception handling:
