Software And Architecture

Introduction This is a continuation post on the exception handling strategies in the threads in Java. For Introduction, please read this post The second post is available here This post addresses the problem statement "How to use the exception handlers in the threads spawned by the Executor Service in Java?" Not all times, we will be using Thread  classes to run our threads because we have to manage a lot of the underlying logic for managing threads. There is ExecutorService in Java which comes to the rescue for the above problem. In the previous posts, we have discussed on how to handle the exceptions in plain threads. However, when using executor service, we do not create / manage threads, so how do we handle exception in this case. We have a ThreadFactory   as an argument which can be used to customize the way threads are created for use within the ExecutorService . The below snippet of code leverages this feature to illustrate the exception handling, wherein we create a

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