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

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...

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...

Speeding using Crossplane and ServiceBinding

Software development and release processes continues to improve to deliver value to the users faster and better to support business growth and relevance in this competitive market. To achieve this we focus on automating the path to production and any people or process related obstacles of a software on its way to the user. Generally, some of the goals of the golden paths, are: Remove interdependency and promote self service and  provider & consumer relationship. Shift left - from people & process to technology & automation . Treat Platform-as-product and provide PaaS Secured and standardised by design In this post, I will describe how Crossplane and ServiceBinding can help achieve these goals in the context of applications development and delivery and their consumption of external resources / services in the process. Note:   Crossplane and  ServiceBinding both are capable of covering beyond just database connectivity. In this blog post I am describing Dat...

Passwordless Auth to Azure Key Vault using External Secret and Workload Identity

I want to fetch my secrets from Azure KV and I don't want to use any password for it. Let's see how this can be implemented. This is yet another blog post (YABP) about ESO and Azure Workload Identity. Why Passwordless Auth: It is a common practice to use some sort of "master password" (spn clienid, clientsecret etc) to access Secret Vaults (in this case it is AZ KV) but that master password becomes a headache to manage (rotate, prevent leak etc). So, the passwordless auth to AKV is ideal.  Why ESO: This is discussed and addressed in the conclusion section. Workload Identity (Passwordless Auth): Lets make a backward start (just for a change). I will try to explain how the passwordless auth will work. This will make more sense when you will read through the detailed implementation section. Here's a sequence diagram to explain it: There's no magic here. This is a well documented process by microsoft  here . The below diagram (directly copied from the official doc...

A modern cloud native (and self serve) way to manage Virtual Machines

Really!! Are there could native way to deploy, LCM VMs and add Self Serve on top ???? In this post I will describe an art of the possibility using the below tools: RHDH: Red Hat Developer Hub (Open source project: Backstage ) OCP Virtualization: Red Hat OpenShift Virtualization (Open source project: KubeVirt ) AAP: Red Hat Ansible Automation Platform (Open source project: Ansible / AWX ) RHEL BootC: Image mode for Red Hat Enterprise Linux (Open source project: bootc ) GitOps: Red Hat OpenShift GitOps (Open source project: ArgoCD ) Quay Registry or any other OCI compliant registry All of these projects can be run on Red Hat OpenShift (Open source project: OKD ) OR on other Kubernetes distribution or on VMs (you pick your underlying infra. For this post I have used OpenShift for simplicity of deployment, integrated tools and narrowly focusing on the usecases instead of the deployment of the tools).  The main goal here is to: Easily deploy and lifecycle applications and stuffs ...

Deciphering the hype of Service Mesh

Service Mesh is not a new topic anymore. Most of us in the industry are already familiar with it. There are also tons of article in the internet about its why and how. In my opinion, it has a significant influence on the application architecture. Here's a DevSecOps humor to start the discussion (and it will make sense as you read along).  This is part 1 of my 3 parts blog posts on Service Mesh. Part 1:   Deciphering the hype of Service Mesh Part 2:   Understanding The Ingress and The Mesh components of Service Mesh. Part 3:  Understanding the observability component of Service Mesh (TBD).  In this post, I am going approach Service Mesh from an application architecture point of view. I will also score some of its basic features on a scale of 1 to 5, where 1 being the least important to me and 5 being the most important.  Table of contents: Common Q&As Features mTLS Service Discovery Meshing Ingress, Gateways etc Telemetries Enterprise products and offeri...