I need to fire an alert to an external notification system to sms to support teams if an exception occurs. Is below conventional ?

try{//backend code}
catch (Exception e){
   // call notification  api 

Or is it preferred to encapsulate this logic into a custom checked exception class which would instead have the notification API call ?

try{//backend code}
catch (Exception e){
   //throw new CustomCheckedException

CustomCheckedException has logic to   invoke the notification API methods 

CodePudding user response：

A couple of things here.

1. To you question: One of the best solutions / answers to your question is the Thread.setUncaughtExceptionHandler. This solution potentially lets you handle notifying the user / notifying the server in one place.

https://www.tutorialspoint.com/java/lang/thread_setuncaughtexceptionhandler.htm

2. IMO, you should never catch Exception. There are situations (like with thread pools) where you can catch Throwable (it includes Error's as well) and times when you might want to catch RuntimeException but I wouldn't recommend catching Exception - you end up catching to many things you weren't expecting to catch - it can create problems with code manageability over time

CodePudding user response：

First of all, I think you should not couple exceptions to notifications (sending SMS, mails, writing to an external service etc.). In other words, the exceptions should indicate the type of irregularity occurred which do not follow the 'normal flow'. Exceptions allows you to handle situations at a distance, say two methods below the method which throwed the exception. The methods could be in different classes, modules.

I would create an exception class to represents different 'concepts', and create an API/ABSTRACTION/INTERFACE to send a notification which is separate from the EXCEPTION CLASS. Moreover, I would not state the method used in sending notification (Sms, mail etc.).

So...

    public class ExecutingClass{
     private final Notifier notifier. //probabily there are better names than //'Notifier' depending on the domain and context.
    
    public ExecutingClass(Notifier notifier){ //given in construction
      this.notifier = notifier;
    }
    
    public void runLogic(){
    try{
     //code which throws exception
    }catch(Exception e){ //to send notifications for any kind of exception.
       notifier.sendNotification(createNotificationInformation(e));
    }
    }
    
    private NotificationInformation createNotificationInformation(Exception e){
       //create a new notification information using the exception or other information
    //fill all information to an value/model class (holds just informations)
    return created.
    }
    
    }

This way, you could give different ways of sending notifications by writing a class to send an SMS notification, another to send mail etc. (Give different implementations at construction of the object)

Moreover, you could form 'a chain of responsibility' and use all of the ways of sending notifications. Or you can pass in a 'wrapper' object with the same interface which sends various notifications using the specific notification classes. Calling each of them one by one or in parallel.

NOTE: Do not mix things that change for different reasons at different times. Do not mix different concepts.

Exceptions are needed to diagnose the situations, make the situation explicit, and handle the condition at a distance. the code you execute to handle the exception should not be coupled to them.