DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Data Engineering
  3. Databases
  4. Decoupling: The Exception Puzzle

Decoupling: The Exception Puzzle

See how separation of concerns plays a role in dealing with your exceptions within a system.

Santosh Singh user avatar by
Santosh Singh
·
Aug. 09, 16 · Tutorial
Like (3)
Save
Tweet
Share
5.63K Views

Join the DZone community and get the full member experience.

Join For Free

In any system design, "Separation of Concerns," is one of the core principles. This not only keeps the system modular and but keeps the impact of any changes to the minimum, limited to affected module.

Software systems are no different. While architecting an application, it's good practice to divide the application into different layers or tiers where each layer is assigned a specific function. For example, consider the following application with simple layers,  

Image title


This is the simplest application architecture with neatly divided tiers. In a decoupled, modular system, the changes inside the layers/modules do not affect the other layers that are using it. This generally achieved by defining a fix contract between the layers. In programming languages, this is achieved by Interfaces. 

Now, Exceptions, or error conditions, are also part of contract. A layer can throw many exceptions depending on functionalities at the granular level.

For example, a persistent layer can throw different exceptions depending on whether the data being stored is in a database, file system, or some cloud storage.

Then the question is, should a module using another module know all the potential exceptions it can receive?

Let's see if there is a cleaner way out. 

Defining a fixed set of exceptions per layer is the starting point. Here, for simplicity, let's assume the following exceptions from each layer:

  • PersistentException

  • BusinessException

Here, when the UI layer calls the business layer, it knows that it can potentially encounter BusinessException so it will take care of handling it. The same is true for interactions between the business layer and the Persistent layer. 

But How Is Decoupling in the Picture? 

Well, let's say a user is saving some data — the request goes via business layer all the way to the database. 

Implementation of the persistent layer could be:

interface PersistentLayer{

    DataStatus storeData(Data data) throws PersistentException;
}


And let's say we are storing data in a database. 

public class PersistentLayerImpl implements PersistentLayer{

    DataStatus storeData(Data data) throws PersistentException{

    try{
        //Code related to DB operation
        }catch(ConstraintViolationException e){
            Logger.error("Error while storing in DB",e);
            throws new PersistentException(e);
        }
    }
}


The business layer could be using:

public class BusinessLayerImpl implements BusinessLayer{

    DataStatus someOperation(Data data) throws BusinessException{

    try{
        //Business operation etc
        persistentLayer.storeData(data); //Calling Persistent Layer

        }catch(PersistentException e){
            Logger.error("Error while storing",e);
            throws new BusinessException(e);
        }
    }
}



Now, say there is a change in the persistent layer. Say instead of the database, there is a web services call to store the data in the cloud. The persistent layer code could change as follows,

DataStatus storeData(Data data) throws PersistentException{

    try{
    //Code related web services operation 

    }catch(WebServicesException e){
        Logger.error("Error while storing via web services",e);
        throws new PersistentException(e);
    }
}


See the effect of this change on the business layer? None at all. 

Note that this concept can be extended to n-tier application or modules.

Modular


This is one of the ways where the degree of decoupling among layers/modules can be reduced. 

Decoupling (electronics) application Data (computing) Database Architecture Cloud Concept (generic programming) Web Service

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Java Development Trends 2023
  • Top 5 PHP REST API Frameworks
  • The Importance of Delegation in Management Teams
  • The Future of Cloud Engineering Evolves

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: