Skip to main content

Exception Handling With Exception Policy

This is how I would think of an application at the very basic level:
Now this works great. But one thing that is missing in this picture is Exception Handling. In many cases we pay very less attention to it and take it as "we'll cross that bridge when it'll come to that". We can get away with this as in many application as exceptions does not stop it from being in the state "is the application working" as long as we code it carefully and at the very least handling the exceptions in code blocks.
This works. But we end up having try catch and if else everywhere and often with messy or no direction to what type of exception is to be handled where and how. Nonetheless, when it comes down an enhancement that depends upon different types exceptions, we will end up writing/modifying code every where, resulting in even messier code. I'm sure no one wants that. Even, in scenarios, a custom handler is not the answer either. Cause this way we will still need to make changes all over our code where we have used that handler.



The hero that can save us from this predicament is this namespace: á•™(`▿´)á•—
 Microsoft.Practices.EnterpriseLibrary.ExceptionHandling
So the idea is very simple.
- Think about what kind of exceptions may occur in you application like read exception, write exception, heck even not implemented exception. (at the very least the  "awesome" application can have "awesomegenericexception"
- Define a policy for each. For each policy we'll have our own implementation or channel in to an existing implementation.
- apply these policies where necessary.

How it looks:
- in config:
<configSections>
    <section name="exceptionHandling" type="Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Configuration.ExceptionHandlingSettings, Microsoft.Practices.EnterpriseLibrary.ExceptionHandling, Version=6.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" requirePermission="true" />
</configSections>
<exceptionHandling>
    <exceptionPolicies>
        <add name="AwesomeExceptionPolicy">
            <exceptionTypes>
                <add name="All Exceptions" type="System.Exception, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
                    postHandlingAction="ThrowNewException">
                    <exceptionHandlers>
                        <add name="Wrap Handler" type="Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.WrapHandler, Microsoft.Practices.EnterpriseLibrary.ExceptionHandling, Version=6.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
                            exceptionMessage="Awesome Exception Occured." exceptionMessageResourceType=""
                            exceptionMessageResourceName="Awesome Exception Occured. This is so awesome that you are going to get a text message for it :)."
                            wrapExceptionType="Awesome.Lib.Exceptions.AwesomeExceptionPolicyImpl, Awesome.Lib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
                    </exceptionHandlers>
                </add>
            </exceptionTypes>
        </add>
    </exceptionPolicies>
</exceptionHandling>

- in code "the boss of exceptions":public class ExceptionManagerFactory : IProvider
{
    ExceptionManager exceptionManager;
    public Type Type
    {
        get
        {
            return this.GetType();
        }
    }
    public object Create(IContext context)
    {
        return GetExceptionManager();
    }
    public ExceptionManager GetExceptionManager()
    {
        if (exceptionManager == null)
        {
            IConfigurationSource config = ConfigurationSourceFactory.Create();
            ExceptionPolicyFactory factory = new ExceptionPolicyFactory(config);
            this.exceptionManager = factory.CreateManager();
        }
        return this.exceptionManager;
    }
}

- in code "the injection":Kernel.Bind<ExceptionManager>().ToProvider<ExceptionManagerFactory>().InSingletonScope();

- in code "the implementation":public class AwesomeExceptionPolicyImpl : ApplicationException
{
    public AwesomeExceptionPolicyImpl(string message)
        : base(message)
    { }     public AwesomeExceptionPolicyImpl(string message, Exception innerException)
        : base(message, innerException)
    {
        Console.WriteLine("to err is human :)");
    }
}
- in code "the use":
ExceptionManager exManager; // injection. Can be done in the super duper base class.
exManager.Process(() =>
{
 YouMyAwesomeTask();
}, "AwesomeExceptionPolicy");


private void YouMyAwesomeTask()
{
 // do the awesome task.
}


Here, I am only implementing the policy for System.Exception. But this can be for other exception types as well. Where the type does not need to be anything more than just a type or even just a message.


- So when it will come down to future modification we will only have to touch one class. Or in the worst case very little change in the code.
- And the overall outcome is even better you write less code. While implementing your method you only think about what policy does it fall under. How that is handled/implemented that's not your problem.
- Even you can make up policy as you go and implement them at later point or channel them to one implementation.
- And ofcourse, CLEAN CODE.

\ (•◡•) /

Comments

Popular posts from this blog

The story of a Hack Job

"So, you have hacked it" -- Few days ago one of the guys at work passed me this comment on a random discussion about something I built. I paused for a moment and pondered: Do I reply defending how that's not a hack. OR Do I just not bother I picked the second option for 2 reasons: It was late. It probably isn't worth defending the "hack vs" topic as the comment passed was out of context. So I chose the next best action and replied "Yep, sure did and it is working great.". I felt like Batman in the moment. In this post I will rant about the knowledge gap around hacking and then describe about one of the components of my home automation project (really, this is the main reason for this post) and use that as an example how hacking is cool and does not always mean bad. But first lets align on my definition of hacking: People use this term in good and bad, both ways. For example: "He/she did a hack job" -- Yeah, that probably...

Managing devices using Edge Manager

Managing edge devices has been a complex process as traditional IT ops tools fall short in distributed, low-connectivity environment to manage huge quantity of devices.  Red Hat Edge Manager  (Open source project: FlightControl , GA'd by Red Hat on late Jan, 2026) solves these challenges by providing streamlined management of edge devices and applications through a declarative approach . Now, there's a fair bit to unpack here. But for simplicity this is how I am going to map those 3 things here: Management of edge devices: I am mapping this to LCM (including upgrade, patch etc) of the underlying OS (in this case RHEL OS of BootC flavor or at least UBI based RHEL ). Managing applications: Mapping this to deploying applications and LCM of the applications stack on the OS. Declarative approach: This one is super interesting. To me this is very K8s-yy but in the world of edge devices running linux (RHEL OS, as of today). And then this thing also has MCP : This is my next prob...

Kubectl using SSH tunnel for TKG K8s Clusters

We know SSH'ing and probably many knows about SSH tunnel. The way, in my opinion, these 2 (SSH and SSH tunnel) are different to me (and I am in favor of SSH Tunnel) is how I use it. From tooling perspective I would almost always do tunnel instead of direct ssh.  In this post I will describe how to do SSH tunnel for kubectl to interact with remote kubernetes cluster (Specifically Tanzu Kubernetes Grid aka TKG cluster). Get the project ready to go from my github:  https://github.com/alinahid477/vsphere-with-tanzu-wizard Topics Backstory SSH tunnel for TKG Clusters using Docker container Technical stuff: Tunnel through Bastion for TKG K8s cluster Technical stuff: SSH Tunnel for Kubectl for remote K8s Clusters (same with or without docker) Technical stuff: Explain me this A famous quote from Darth Vader himself: "Feel the power of SSH Tunnel" Backstory Why ssh or ssh tunnel? The below diagram shows in what scenario a SSH or SSH Tunnel almost becomes a necessity. Let's st...

Jenkins on k8s - can it be this easy?

 As developers or devops we have had a somewhat love and hate relationship with Jenkins like "love oss based ci/cd that can be hosted on any environment with ranges of community plugins for pretty much anything" BUT "hate messy UI, lack of documentations, difficult to configure" etc etc. But this post isn't about pros and cons of Jenkins, rather it is about how you can get Jenkins on your k8s super quick and easy (using Merlin). Git Repo:  https://github.com/alinahid477/jenkinsonk8s Table of contents: Why Jenkins Why Merlin for Jenkins What is Merlin for Jenkins How Merlin for Jenkins works How Jenkins on k8s work Some anticipated FAQs Why Jenkins Jenkins remains a popular choice when it comes to CICD solution with a massive community of users and contributors (despite the fact there are new cool kids in block like Tekton etc). The way I see it (because of our love and hate relationship with it) "Jenkins is not CICD tool that you want it's the CICD t...

Cloud Native CICD or CICD Natively in Cloud

Kubernetes aka K8s is a popular term these days and the technology is reshaping how we develop, build and deliver applications for obvious good reasons. All the major cloud vendors have K8s offering as well as it is also available on onprem private clouds/data centres too ( Read my post about this ). Thus, I can claim that K8s as platform is cloud native and applications running on K8s are also cloud native (provided it meets some other criteria).  In this post I will describe my take on the topic Cloud Native CICD. Table of Contents: Cloud Native CI/CD CI, CD and Pipelines Challenges with Traditional CICD tools Core attributes of K8s native CICD tools Choices available for K8s native CICD tools Why I like Cartographer Cartographer drawbacks and solutions Mercator - The Cartographer UI Tanzu Application Platform Conclusion Cloud Native CI/CD: The term "Cloud Native CICD" can be interpreted in two ways: Produce cloud native deployable (through CI) and deploy/deliver it on a cl...

Sitecore - Module based approach

​ Okay so this is something I picked up from a recent developer group thingy and have been annoying my colleagues about this since then. Instead of thinking Sitecore as one project (MVC) solution why not treat it like a module/deliverable based implementation. I have created a sample solution which is here: https://bitbucket.org/ali_nahid/sckitchensync   The idea is pretty simple (Just like DDD pattern): You get a rough idea of the entire implementation like what are the  deliverable , functionalities etc etc and group them. Then just like the way you plan renderings on your page you plan bunch of different modules to implement in your solution. In my case I divided my sitecore implementation into the following modules: 1.       The core: This module contains the layouts and core renderings. In my case 1 standard layout that just defines the top level placeholders. Like header, footer, content etc. And a “_Ma...