Software And Architecture

Introduction This is a continuation to the post on exception handling on threads. For those interested in the background, please visit this link This post discusses on the topic "Can I use separate exception handlers for threads performing mission critical tasks vs non trivial tasks?" Per-Thread Exception Handler Let's us assume that we built a handler that wants to notify the support team that something has gone wrong in some special thread processing, like the one below (not really notifying anyone but helps correlate the context) class SupportNotificationExceptionHandler implements Thread . UncaughtExceptionHandler { @Override public void uncaughtException ( Thread t, Throwable e) { notifySupport (t, e); } private void notifySupport ( Thread t, Throwable e) { System . out . println ( "Notified support team on: " + e. getMessage () + " raised from : " + t. getName ()); } } Let us now apply the above special handle

Introduction Exception handling is very critical to any application and any language that was used to develop. This helps the following stakeholders Stakeholders End-User: A graceful message that indicates that something has gone wrong in the system due to some wrong input or due to some internal fault Developer A clean way to get to know which line of code caused the exception and the stack trace that can help us reach to the points impacted Support Team A helpful hint that they can try to verify and resolve if it is something within their reach or to escalate to the product team SRE (Site Reliability Engineering) An indication of how far the application is performing w.r.to being reliable to the end-users and how faults are handled or tolerated etc.. Problem Statement When we use threads to get the job done for performing some intensive task (computation or Network intensive tasks), it becomes difficult to track down on the exceptions. This post is one in a series of posts that will