DEV Community: Azna Aroos

Stop Writing Try-Catch Everywhere: Use Global Exception Handling Instead

Azna Aroos — Thu, 02 Apr 2026 14:27:30 +0000

Ever found yourself wrapping almost every method with a try-catch block, only to end up with messy, repetitive code? You’re not alone. Handling errors is one of those things every developer does, but not everyone does it well.

As applications grow, scattered exception handling quickly turns into a maintenance nightmare. Inconsistent error responses, duplicated logic, and hard-to-track bugs start creeping in. That’s where a smarter approach comes in. In this article, we’ll move from basic exception handling to a cleaner, more scalable solution, Global Exception Handling, and see how it can transform the way your application deals with errors.

Exception Handling

Exception Handling is a mechanism used in programming to manage runtime errors (exceptions) in a controlled way, so that the program does not crash unexpectedly. An exception is an abnormal event that occurs during the execution of a program, such as:

⦁ Dividing by zero
⦁ Accessing a null object
⦁ Invalid user input
⦁ File not found

Instead of stopping the program, exception handling allows developers to catch and handle these errors gracefully.

In languages like Java, this is done using blocks such as:

⦁ try – > contains code that may cause an exception
⦁ catch –> handles the exception
⦁ finally -> executes regardless of exception occurrence

Example (Conceptual)

try {
    int result = 10 / 0;
} catch (ArithmeticException e) {
    System.out.println("Cannot divide by zero");
}

Here, instead of crashing, the program handles the error and continues execution.

Limitations of Traditional Exception Handling

While basic exception handling is useful, it has some drawbacks:

⦁ Repeated code across multiple classes
⦁ Hard to maintain in large applications
⦁ Inconsistent error responses
⦁ Difficult to manage all errors centrally
This is where Global Exception Handling becomes important.

Global Exception Handling

Global Exception Handling is an advanced approach where all exceptions in an application are handled in one centralized location, rather than handling them individually in each class or method.

In frameworks like Spring Boot, this is typically implemented using:
⦁ @ControllerAdvice
⦁ @ExceptionHandler
These allow the system to intercept exceptions globally and return a structured, consistent response.

How It Works
Instead of writing try-catch everywhere, you define a global handler:

@ControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(Exception.class)
    public String handleException(Exception ex) {
        return "Something went wrong: " + ex.getMessage();
    }
}

Now, any exception thrown in the application will be handled here.

Advantages of Global Exception Handling
⦁ Centralized error handling
⦁ Cleaner and more readable code
⦁ Consistent error responses
⦁ Easier maintenance and debugging
⦁ Better user experience
⦁ Improved security (no exposure of internal errors)

Exception Handling helps prevent application crashes by managing runtime errors locally using try-catch. However, in large applications, this approach becomes difficult to manage.
Global Exception Handling solves this by providing a centralized way to handle all exceptions, making the system more organized, maintainable, and user-friendly.

java#springboot#backend#exceptionhandling#webdev #programming#softwareengineering #api

Entity vs DTO vs Model — Stop Using These Terms Interchangeably

Azna Aroos — Sun, 29 Mar 2026 11:39:23 +0000

Do you ever confuse yourself with the terms Entity, Model, and DTO? Sometimes you might hear your lecturer say that you can call an Entity a Model, but is that really true?
They may sound similar, but they are actually quite different. Let's understand what they really are and what they actually do.

Entity

An Entity represents a database table using annotations like @entity. Think of it as a real table in your database.
Example: Student Table

@Entity
@Table(name = "students")
public class StudentEntity {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String name;
    private String email;
    private String password;
}

An Entity is used by JPA/Hibernate. It is tightly coupled to the database and typically contains all fields, including sensitive ones such as passwords.

DTO (Data Transfer Object)

A DTO is used to transfer data between layers.

It is not directly connected to the database. It is a safer, filtered version of your data that you send to the frontend.

public class StudentDTO {
    private Integer id;
    private String name;
}

Model

This is where many people get confused. In Spring Boot, Model is often used as a general term for business objects. In MVC architecture, a Model is specifically used to pass data to views. Sometimes developers use "Model" in place of "Entity," so its meaning depends on the context.
In Spring MVC, a Model is simply used to pass data to a view template like Thymeleaf.

@GetMapping("/student")
public String getStudent(Model model) {
    model.addAttribute("name", "Aqueel");
    return "StudentPage";
}

A Simple Analogy — The Toy Shop
Imagine you own a toy shop.
Think of the Entity as your back storage room. It contains everything:

All toys
Their cost price
Supplier details
Secret discount rules

That's your Entity — directly connected to the database.
When customers walk in, you don't take them to the storage room. You only show them:

Toy name
Selling price
Color

You hide the supplier info and purchase price from them. That filtered view is your DTO — a safe version of the data.
The Model is like the receipt at the counter. When someone buys a toy, it shows:

Toy name
Quantity
Total price

Why Not Just Use Entity Everywhere?

- Security risk — sensitive fields like passwords get exposed.
- Over-fetching — you return more data than the client actually needs.
- Tight coupling — your database structure becomes directly tied to your API.
- Hard to scale — changes to the database will break your API responses.

The Golden Rule:

Use Entity to talk to your database, DTO to talk to the outside world, and Model to talk to your views.

Think of it this way,

Entity = what lives in your database 🗄️
DTO = what you show to the world 🌐
Model = what you pass to your UI 🖥️

Never expose your Entity directly to the frontend. Always filter your data through a DTO. The extra effort keeps your application secure, clean, and scalable.

Found this helpful? ♻️ Repost to help other developers.
Follow for more tips! 🚀

SpringBoot #Java #Backend #WebDevelopment #Programming #DTO #JPA #SoftwareEngineering #Developer

Layered Architecture A Beginner's Guide to Structuring Software Systems

Azna Aroos — Sun, 08 Mar 2026 16:48:43 +0000

Building software is not something you decide to do one minute and start building the next. High-quality software is not just about writing code — it is equally about how efficiently data flows across components, independently and without interruption.

Software architecture defines how the different parts of an application fit together and interact to enable better data flow. It helps engineers understand how to build a system and, ultimately, helps achieve customer satisfaction by keeping the software focused on real user needs.

There are many ways to organize software components. Today, we will explore one of the most popular and practical approaches: Layered Architecture.

🍔 Think of a Burger

Imagine you are making a burger. A burger is built in layers, and each layer has a specific job:

Top Bun — holds everything together
Cheese — adds flavor
Vegetables — provide freshness and fullness
Beef Patty — the heart of the taste
Bottom Bun — the foundation

If something goes wrong with the vegetables, you do not throw the whole burger away — you fix the vegetable layer. Layered Architecture in software works exactly the same way.

A system is divided into layers. Each layer has a specific responsibility. Each layer communicates only with the layer directly adjacent to it. That's it.

🏗️ The Three Core Layers

In real-world software development, a layered architecture typically consists of three main layers:

Presentation Layer (UI Layer)
Business Logic Layer (Service Layer)
Data Access Layer (Database Layer)

01 · Presentation Layer (UI Layer)

This is what users see and interact with. It includes elements such as:

Login page
Sign-up form
Buttons and navigation
Dashboard

The Presentation Layer only collects input from the user and displays output back to them. It performs no heavy calculations and does not communicate directly with the database.

💡 Think of it as the waiter in a restaurant. The waiter serves the food that the chef prepares in the kitchen — what happens in the kitchen is none of the waiter's business. Each person does only the job they are assigned.

02 · Business Logic Layer (Service Layer)

This is the brain of the software. It is responsible for:

Validating incoming data
Applying business rules and logic
Making decisions based on processed information

Examples of business logic include:

Verifying whether the entered password is correct
Calculating the total bill amount
Checking whether a user is authorized to access a resource

This layer does not render any UI and does not store data directly. It simply thinks and processes.

03 · Data Access Layer (Database Layer)

This layer handles all communication with the database. Its core operations include:

Saving data
Retrieving data
Updating data
Deleting data

Examples:

Inserting a new user record into the database
Fetching user profile details
Updating an existing profile

🔄 How the Layers Work Together

Consider a user logging into an application. Here is how the request flows through each layer:

User enters their username and password → Presentation Layer
Presentation Layer sends the data to → Business Logic Layer
Business Logic Layer asks → Data Access Layer to query the database
Data Access Layer returns the result to → Business Logic Layer
Business Logic Layer evaluates the result and makes a decision
Presentation Layer displays "Login Successful" or "Incorrect Password"

Each layer performs only its own responsibility — and nothing more.

✅ Why Use Layered Architecture?

Modularity — Each layer is independent, making the codebase easier to understand, maintain, and extend.

Security — The layered structure enables targeted security measures at each level, protecting the system from a wide variety of threats.

Easy to Modify — Changes in one layer, like switching databases, don't affect the others. Each layer is self-contained.

Easy to Test — Each layer can be debugged and tested in isolation, leading to more reliable and faster testing cycles.

Layered Architecture is one of the most foundational patterns in software design. Understanding it is the first step toward building systems that are clean, scalable, and maintainable.

SOLID Principles: Writing Code That Survives the Real World

Azna Aroos — Fri, 27 Feb 2026 07:49:10 +0000

Writing software is not just about making things work.
It’s about making things work today, tomorrow, and one year from now.

Last week, we explored Event-Driven Architecture — how systems communicate and scale.
This week, we’re stepping into something even more foundational:

SOLID Principles

SOLID is not a framework.
It’s not a library.
It’s a way of thinking.

Each letter in SOLID represents a principle that helps us design clean, flexible, and maintainable software.

Before we go technical, imagine yourself as a kid with a lot of toys:

One toy should do one thing.

A spoon is for eating.

A toothbrush is for brushing teeth.

If your spoon also tried to brush your teeth, that would be weird, right?
That’s where the first principle comes in.

S – Single Responsibility Principle (SRP)

One thing = One job

A class should have only one responsibility.
It should have only one reason to change.

If a class handles:

user registration

sending emails

saving data to the database

…that’s too much responsibility.

Just like a spoon shouldn’t brush your teeth, a class shouldn’t try to do everything.

In the real world:

A chef cooks.

A driver drives.

A teacher teaches.

Clear roles. Clear responsibilities.

classDiagram
    class UserService {
        +registerUser()
    }
    class EmailService {
        +sendEmail()
    }
    UserService --> EmailService

Figure 1: Single Responsibility Principle (SRP) – Each class has only one responsibility.

O – Open/Closed Principle (OCP)

You can add new toys to your toy box without breaking your old ones.

That means:

You can extend behavior without modifying existing code.

Instead of changing old code every time you need something new, you extend it.
Extend. Don’t modify.

In the real world:

You don’t break your house walls to add a new device.

You plug something into an existing socket.

Good software design allows growth without destruction.

classDiagram
    class Payment {
        <<interface>>
        +pay(amount)
    }
    class CreditCardPayment {
        +pay(amount)
    }
    class PayPalPayment {
        +pay(amount)
    }
    class PaymentProcessor {
        +process(payment)
    }
    Payment <|.. CreditCardPayment
    Payment <|.. PayPalPayment
    PaymentProcessor --> Payment

Figure 2: Open–Closed Principle (OCP) – Extend functionality without modifying existing code.

L – Liskov Substitution Principle (LSP)

If you replace your chocolate milk with strawberry milk, it should still behave like milk.

If something is a “type of” something else, it should behave properly as that type.

Example:

We say:

“A penguin is a bird.”

But we also say:

“All birds can fly.”

Now something feels wrong — penguins can’t fly.

The problem is not the penguin, it’s our design assumption.

Rule: Don’t force subclasses to break expectations.
If a subclass cannot fully behave like its parent, your inheritance design is wrong.

classDiagram
    classDiagram
    class Bird
    class FlyingBird {
        <<interface>>
        +fly()
    }
    class Sparrow
    class Penguin
    FlyingBird <|.. Sparrow
    Bird <|-- Sparrow
    Bird <|-- Penguin

Figure 3: Liskov Substitution Principle (LSP) – Subtypes must behave like their parent types.

I – Interface Segregation Principle (ISP)

In simple words: Don’t force someone to do things they don’t need to do.

If you give a kid responsibilities like:

Cook

Drive

…that’s too much. Give only what they actually need.

Example:

A TV remote has only TV buttons.

An AC remote has only AC buttons.

You don’t mix everything into one giant remote.

In software, large interfaces are like giant remotes.
Small, specific interfaces are clean and focused.

classDiagram
    class Workable {
        <<interface>>
        +work()
    }
    class Eatable {
        <<interface>>
        +eat()
    }
    class Human
    class Robot
    Workable <|.. Human
    Workable <|.. Robot
    Eatable <|.. Human

Figure 4: Interface Segregation Principle (ISP)– Don’t force classes to implement methods they don’t need.

D – Dependency Inversion Principle (DIP)

If you love only red cars, when that car breaks, your heart breaks too.

But if you love cars in general, you can easily replace one with another.

In software: Depend on abstractions, not concrete implementations.

You plug devices into a wall socket, not directly into a specific power plant.
The socket is the abstraction; the power plant can change.

When high-level modules depend on abstractions:

Systems become flexible

Components become replaceable

Code becomes easier to maintain

classDiagram
    class Database {
        <<interface>>
        +save()
    }
    class MySQLDatabase
    class MongoDatabase
    class OrderService {
        +processOrder()
    }
    Database <|.. MySQLDatabase
    Database <|.. MongoDatabase
    OrderService --> Database

Figure 5: Dependency Inversion Principle (DIP) – Depend on abstractions, not concrete implementations.

Final Thoughts

SOLID principles are not just theory.
They help you write code that:

Is easier to understand

Is easier to extend

Is easier to maintain

Doesn’t break easily

Good design today saves you from pain tomorrow.
When you follow SOLID, your software grows cleanly — just like a well-organized toy box.

💬 What About You?

Have you ever worked on a project where poor design caused problems later?
Which SOLID principle do you struggle with the most?
Let’s discuss in the comments 👇

Understanding Event-Driven Architecture (With a Simple Example)

Azna Aroos — Wed, 18 Feb 2026 14:06:25 +0000

Imagine you're at your best friend’s birthday party.

When she blows out the candles, people clap.
When the music starts, people dance.

No one gives instructions like:
“Everyone, clap now!” or “Everyone must dance!”

People simply react to what happens.

This is exactly how Event-Driven Architecture (EDA) works in software systems.

What Is Event-Driven Architecture?

Event-Driven Architecture is a design pattern where:

A system produces an event (something that happened).

Other parts of the system listen for that event.

They react independently.

No component directly tells another component what to do.
They communicate through events, not direct calls.

This makes the system loosely coupled, scalable, and flexible.

Traditional Approach vs Event-Driven

Traditional (Tightly Coupled)

`public void placeOrder(Order order) {
    inventoryService.updateStock(order);
    emailService.sendConfirmation(order);
    billingService.createInvoice(order);
}`

Here:

The order service directly controls everything.

If we add a new feature, we must modify this method.

The system becomes tightly coupled.

Event-Driven Approach (Loosely Coupled)

`public void placeOrder(Order order) {
    eventPublisher.publish(new OrderPlacedEvent(order));
}`

Now:

Inventory listens to OrderPlacedEvent
Email listens to OrderPlacedEvent
Billing listens to OrderPlacedEvent
Each module reacts independently.

Real Backend Example

When a user places an order:

Inventory service updates stock.
Email service sends confirmation.
Billing service creates an invoice.
Analytics service records the transaction.

If tomorrow you want to add:

Notification service
Fraud detection service
Loyalty points service

You don’t modify existing code.
You simply add a new listener.

That’s powerful.

Benefits of Event-Driven Architecture

Loose Coupling

Services don’t depend directly on each other.

Scalability

You can scale consumers independently.

Flexibility

New features can be added without touching existing logic.

Cleaner Architecture

Clear separation of responsibilities.

Where Is It Used?

Microservices architectures

E-commerce systems

Payment systems

Real-time applications

Distributed systems

Tools commonly used:

Kafka

RabbitMQ

AWS SNS/SQS

Spring Events

Final Thoughts

Event-Driven Architecture is not just a technical concept.
It’s a mindset shift — from commanding components to letting them react.

Just like people reacting at a birthday party.

If you're interested in exploring backend architecture in code, feel free to check my project here:

👉 https://github.com/AznaX97/RoleBasedVisitorManagementAPI