In this our third article on C#.Net custom exception handling, we will discuss using Reflection to identify the source assembly and logging exceptions in a custom data store.

As stated before, custom exception handling is often seen a low-level luxury. If you have it, then you enjoy it. If you don’t, then it is not really missed. But tailored systems of all kinds benefit from a solid infrastructure. Whether you are building a CRM application, Accounting application, Line-of-Business application, or some combination of these systems … custom exception handling will go a long way toward making your implementation more robust and easier to maintain.

In the previous article we described creating a new custom exception class like this:

In the second article we discussed accepting a custom exception message, and passing this message along to the base class constructor as well. We even discussed wrapping a .Net exception to not only supply a custom message, but to also capture the underlying exception like this:

In this installment, we want to talk about logging valuable information about our custom exception in a custom data store. To do this, we start by simply adding some DAO code to the constructor of our custom exception:

There is nothing magical here. You can use ANY form of data access to now log both your custom message AND the message of the inner .Net exception as well.

So what else might we want to log at this time?

Obviously we want to log the exact date and time. Furthermore, because we now own our custom exception, we can include anything we want in the constructor. For example, we can pass and then log information about the user. Another helpful bit of information might be a simple integer identifier to help us locate the exact place in code where this exception was generated.

But the coolest bit of extra information involves using Reflection to pass details about the assembly that threw the exception. To do this, the code that throws the custom exception must use System.Reflection and then it can do something like this:

Of course this requires yet another constructor that accepts the name of the calling assembly, but that is easy – it is just a string! Note that you can also send MethodInfo.GetCurrentMethod().Name to get the name of the method itself.

In our next article we will dive more deeply into this code and explore other possibilities. In the meantime, try it on your own. It is really easy and a lot of fun.

In conclusion, this article series explains one approach to using custom exceptions in a .Net application. This is certainly not the only way to handle custom exceptions in .Net, and it might not even be the best way. But if you are not using custom exceptions now, then hopefully this article series will help you do so in a meaningful way. As a result, your Intelligent ERP (iERP) system will be even smarter than it was before!

In our first article on custom exceptions, we discussed how custom exceptions are created and why they are useful in an enterprise system. In this article, we will discuss extending the constructor on our custom exception class.

As stated before, custom exception handling is often seen a low-level luxury. If you have it, then you enjoy it. If you don’t, then it is not really missed. But tailored systems of all kinds benefit from a solid infrastructure. Whether you are building a CRM application, Accounting application, Line-of-Business application, or some combination of these systems … custom exception handling will go a long way toward making your implementation more robust and easier to maintain.

In the previous article we described creating a new custom exception class like this:

public class EagleException : System.ApplicationException
{
}

This allows you to throw the new custom exception from anywhere in your code base, and there are benefits associated with doing this as already discussed. But what if you want to include a custom error message as well? You do that by adding a new constructor, and by calling the base constructor as well:

public class EagleException : System.ApplicationException
{
	public EagleException( string message ) : base( string message )
	{
	} 
}

Now you can throw your custom exception with a custom message that is specific to each circumstance:

if( user.IsLostAndConfused )
{
	throw new EagleException( "You may not use this button for a coffee cup." );
}

You will notice that we are explicitly passing this message along to the base class constructor as well, because it can make use of the message in other ways. And while we are on the topic of constructors, let’s consider another scenario that will require a second constructor on our custom exception class.

In the example above, the underlying .Net system is not throwing an exception – only we are. But what if the underlying .Net system throws an exception that we want to catch and wrap up, all nice and neat, inside one of our own custom exceptions? In that case we will want an overloaded constructor on our custom exception that accepts the original one as an inner exception:

public class EagleException : System.ApplicationException
{
	public EagleException( string message, Exception innerException ) : 
base( string message, Exception innerException )
	{
	} 
}

This is really powerful, because now we can do all sorts of things to not only handle the inner exception in a custom way at runtime, but now we can also log tons of useful information associated with this event in the custom data store of our choosing. Stay tuned for our next article on more details!

In conclusion, this article series explains one approach to using custom exceptions in a .Net application. This is certainly not the only way to handle custom exceptions in .Net, and it might not even be the best way. But if you are not using custom exceptions now, then hopefully this article series will help you do so in a meaningful way. As a result, your Intelligent ERP (iERP) system will be even smarter than it was before!

Custom exception handling is often seen a low-level luxury.  If you have it, then you enjoy it.  If you don't, then it is not really missed.  But tailored systems of all kinds benefit from a solid infrastructure.  Whether you are building a CRM application, Accounting application, Line-of-Business application, or some combination of these systems ... custom exception handling will go a long way toward making your implementation more robust and easier to maintain.

In this series, we will discuss several ways to implement custom exception handling in a .Net application.  We will start with a very simple example and then build from there.  All along the way, we will try to explain the details in a simple, straightforward way.

Custom exceptions  do not have to be overly complex.  You can get started pretty easily.  You begin by creating a new class that derives from System.ApplicationException as follows (note that we are using the word "Eagle" here to represent your application name - that part can be whatever you want, of course):

That was not so bad, was it?  But what does this buy you?  Well, quite a lot actually.

This code will build as-is and it is all you need to get started.  With this new class, you can now throw custom exceptions from anywhere in your application code:

Now at least, when anybody sees this exception they will know that it was thrown by you and not by the operating system or some other mysterious part of the system infrastructure.  This is important, because if you - the programmer - threw the exception then it means that you anticipated some specific sort of error.  That goes a long way toward helping the user or debugger or administrator resolve the underlying problem.  It gives them a huge head start in knowing where to look.

Two points:

1. It is expensive to throw exceptions.  Do not make the rookie programming mistake of throwing exceptions as a means of handling normal programming logic.  For example, do not throw and then handle an exception when a simple foreach loop or switch statement would do the job without it.
2. Throwing custom exceptions is very valuable even if you never specifically catch them. This is a really important point.  Some programmers avoid implementing custom exceptions because they feel burdened to catch them all over the place.  You don't ever have to catch a custom exception in order to enjoy the benefits of throwing one!

In future installments, we will discuss using the base class constructors to throw more interesting custom exceptions, using Reflection to capture the exact source of the exception in code, and logging custom exceptions in an underlying custom database.

In conclusion, this article series explains one approach to using custom exceptions in a .Net application.  This is certainly not the only way to handle custom exceptions in .Net, and it might not even be the best way.  But if you are not using custom exceptions now, then hopefully this article series will help you do so in a meaningful way.  As a result, your Intelligent ERP system will be even smarter than it was before!