When you have a **prototype-scoped bean** that contains a **singleton-scoped bean**

as a dependency, the behavior of the Spring container during `getBean()` calls is

as follows:

1. **Prototype Bean**: Each time you call `getBean()` for the prototype-scoped
bean, Spring will create a new instance of the prototype bean.
2. **Singleton Dependency**: The singleton-scoped bean inside the prototype bean
will not be recreated each time. Instead, the same instance of the singleton bean
will be injected into each new instance of the prototype bean.

### Detailed Explanation:

- **Prototype Bean** (`PrototypeClass`): Marked with `@Scope("prototype")`, it is
created as a new instance each time you call `getBean()`.
- **Singleton Bean** (`SingletonClass`): Marked with the default
`@Scope("singleton")`, it is created only once and shared across the entire Spring
container.

### Scenario:
Suppose you have the following setup:

```java
@Component
@Scope("singleton")
public class SingletonClass {
// Singleton bean logic here
}

@Component
@Scope("prototype")
public class PrototypeClass {
@Autowired
private SingletonClass singletonClass;

public void show() {

System.out.println("Prototype instance: " + this);
System.out.println("Injected Singleton instance: " + singletonClass);
}
}
```

### When You Call `getBean("prototypeClass")` Multiple Times:

- **New Instances of `PrototypeClass`**: Every time you call
`getBean("prototypeClass")`, Spring will create a new instance of `PrototypeClass`.
- **Same Instance of `SingletonClass`**: Each `PrototypeClass` instance will
receive the same instance of `SingletonClass`, as it is a singleton.

**Example Output**:
If you call `getBean("prototypeClass")` three times, you may see output similar to:
```
Prototype instance: PrototypeClass@1a2b3c
Injected Singleton instance: SingletonClass@4d5e6f

Prototype instance: PrototypeClass@7g8h9i

Injected Singleton instance: SingletonClass@4d5e6f

Prototype instance: PrototypeClass@j1k2l3

Injected Singleton instance: SingletonClass@4d5e6f
```
### Summary:
- **Prototype bean**: A new instance is created with each call to `getBean()`.
- **Singleton bean inside the prototype**: The same singleton instance is shared
across all new instances of the prototype bean.

This behavior ensures that the prototype bean can have unique instances, while its
singleton dependency remains consistent across the application.
===============================
If you have a **singleton-scoped bean** that contains a **prototype-scoped bean**
as a dependency, the behavior when calling the prototype bean can be
counterintuitive due to how Spring manages the lifecycle of beans:

### Default Behavior:

- When you inject a **prototype bean** into a **singleton bean**, Spring injects
**only one instance** of the prototype bean during the singleton bean's
initialization.
- This means that, by default, when you call a method on the singleton bean that
references the prototype bean, it will always use the **same instance** of the
prototype bean that was injected initially.

### Problem:
Since the singleton bean is created only once and its dependencies are resolved at
that time, the prototype bean does **not** get recreated each time the singleton
bean accesses it. This is because the lifecycle of the prototype bean is controlled
by the singleton bean, which leads to unexpected behavior if you want fresh
instances of the prototype bean on each use.

### How to Ensure Fresh Instances of Prototype Bean:

To ensure that the singleton bean can get a new instance of the prototype bean each
time it's needed, you can use:
1. **`@Lookup` Annotation**: This annotation tells Spring to look up a new instance
of the prototype bean each time it is called.
2. **`ObjectFactory` or `Provider`**: Using these Spring facilities, you can create
a new instance of the prototype bean whenever it is accessed within the singleton
bean.

### Example Using `@Lookup`:

```java
@Component
@Scope("singleton")
public class SingletonClass {
@Lookup
public PrototypeClass getPrototypeBean() {
// Spring overrides this method to return a new instance of PrototypeClass
return null;
}

public void show() {

PrototypeClass prototype = getPrototypeBean();
System.out.println("Prototype instance: " + prototype);
}
}
```

### Example Using `ObjectFactory`:

```java
@Component
@Scope("singleton")
public class SingletonClass {
 @Autowired
private ObjectFactory<PrototypeClass> prototypeFactory;

public void show() {

PrototypeClass prototype = prototypeFactory.getObject(); // New instance
each time
System.out.println("Prototype instance: " + prototype);
}
}
```

### Example Using `Provider` (from `javax.inject`):

```java
@Component
@Scope("singleton")
public class SingletonClass {
@Autowired
private Provider<PrototypeClass> prototypeProvider;

public void show() {

PrototypeClass prototype = prototypeProvider.get(); // New instance each
time
System.out.println("Prototype instance: " + prototype);
}
}
```

### Summary:
- **By default**: A prototype-scoped bean inside a singleton bean behaves like a
singleton because only one instance is injected at the time of singleton bean
creation.
- **To get fresh instances**: Use `@Lookup`, `ObjectFactory`, or `Provider` to
ensure new instances of the prototype bean are retrieved each time it is accessed
in the singleton bean.
================================
In Spring Boot, the `@Qualifier` annotation is used to resolve the ambiguity when
there are multiple beans of the same type and you need to specify which one should
be injected. It helps Spring identify which specific bean should be used when there
is more than one candidate available for dependency injection.

### Why `@Qualifier` is Needed:

When you have multiple beans of the same type in the Spring context, Spring doesn't
know which one to inject by default, leading to an
`org.springframework.beans.factory.NoUniqueBeanDefinitionException`. The
`@Qualifier` annotation helps you specify which bean to use.

### How to Use `@Qualifier`:

You can use `@Qualifier` along with `@Autowired` to tell Spring exactly which bean
to inject by specifying the bean name.

### Example:

Suppose you have two beans of the same type:

```java
@Component("beanOne")
public class ServiceA implements MyService {
// Implementation of ServiceA
}
@Component("beanTwo")
public class ServiceB implements MyService {
// Implementation of ServiceB
}
```

### Injecting a Specific Bean:

```java
@Service
public class ClientService {
private final MyService myService;

@Autowired
public ClientService(@Qualifier("beanOne") MyService myService) {
this.myService = myService;
}

public void performTask() {

myService.doSomething();
}
}
```

In this example, the `@Qualifier("beanOne")` annotation tells Spring to inject the

`ServiceA` bean into `ClientService`.

### Common Use Cases:

1. **Disambiguation**: When you have multiple beans implementing the same interface
or of the same type.
2. **Customization**: To choose a specific implementation when injecting services
or repositories.
3. **Conditional Injection**: In cases where the bean name or type is determined
based on specific conditions.

### Example with Field Injection:

```java
@Autowired
@Qualifier("beanTwo")
private MyService myService;
```

### Using `@Qualifier` with `@Primary`:

If you use `@Primary` on one bean and `@Qualifier` on another, `@Primary`
designates a default bean, but `@Qualifier` can still be used to explicitly choose
another bean.

```java
@Component
@Primary
public class DefaultService implements MyService {
// Default implementation
}

@Component("customService")
public class CustomService implements MyService {
// Custom implementation
}
```
**Injection without `@Qualifier` will use `DefaultService` due to `@Primary`**:
```java
@Autowired
private MyService myService; // Injects DefaultService
```

**Injection with `@Qualifier`**:

```java
@Autowired
@Qualifier("customService")
private MyService myService; // Injects CustomService
```

### Summary:
- **`@Qualifier`** is used to specify which bean to inject when multiple beans of
the same type exist.
- It helps avoid ambiguity and ensures the correct bean is chosen for dependency
injection.
- Works with `@Autowired`, constructor injection, and method parameter injection.
====================
Mocking `final` classes in JUnit 5 can be done using **Mockito** version 2 or above
with specific configuration. By default, earlier versions of Mockito didn't allow
mocking `final` classes or methods, but later versions introduced this capability.

### Steps to Mock `final` Classes in JUnit 5:

1. **Ensure You Have Mockito 2+ or Above**: Use Mockito version 2.x or later,
ideally the latest version of Mockito 3 or 4, which supports mocking `final`
classes and methods out of the box.

2. **Add Mockito and Mockito Inline Dependency**:

To enable mocking of `final` classes, you may need to include the `mockito-
inline` dependency, which extends Mockito to support `final` classes.

**Maven Dependencies**:
```xml
<dependency>
<groupId>org.mockito</groupId>
<artifactId>mockito-core</artifactId>
<version>4.11.0</version> <!-- Use a suitable version -->
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.mockito</groupId>
<artifactId>mockito-inline</artifactId>
<version>4.11.0</version> <!-- Same version as mockito-core -->
<scope>test</scope>
</dependency>
```

**Gradle Dependencies**:
```groovy
testImplementation 'org.mockito:mockito-core:4.11.0'
testImplementation 'org.mockito:mockito-inline:4.11.0'
```

3. **Example of Mocking a `final` Class**:

```java
 import org.junit.jupiter.api.Test;
import org.mockito.Mockito;

import static org.mockito.Mockito.*;

final class FinalClass {

public String sayHello() {
return "Hello!";
}
}

public class FinalClassTest {

@Test
void testMockFinalClass() {
// Create a mock of the final class
FinalClass finalClassMock = mock(FinalClass.class);

// Define behavior
when(finalClassMock.sayHello()).thenReturn("Mocked Hello!");

// Verify the mocked behavior

System.out.println(finalClassMock.sayHello()); // Output: Mocked Hello!
}
}
```

### Key Points to Remember:

- **Mockito-inline**: Including the `mockito-inline` dependency allows you to mock
`final` classes and methods without additional configuration.
- **Static Methods**: For mocking static methods, you need `mockito-inline` or use
tools like **PowerMock** or **MockK** (another library compatible with Java).
- **Version Compatibility**: Always make sure that your Mockito version supports
the feature you need.

### Why Mock `final` Classes?

Mocking `final` classes can be useful for testing legacy code or libraries that you
cannot modify, where final methods need to be tested without changing their
original implementation.

By following these steps, you can mock `final` classes and methods in JUnit 5 with
ease, ensuring better flexibility in writing unit tests for classes that are
otherwise non-mockable by default.
========================
Mocking static methods in JUnit 5 can be done using **Mockito** version 3.4.0 or
higher, which introduced built-in support for mocking static methods through the
`mockito-inline` module. Here's how to set it up and use it:

### Step-by-step Guide to Mocking Static Methods:

1. **Add the Mockito Dependencies**:

Ensure you include the `mockito-core` and `mockito-inline` dependencies to
enable static method mocking.

**Maven Dependencies**:
```xml
<dependency>
<groupId>org.mockito</groupId>
<artifactId>mockito-core</artifactId>
 <version>4.11.0</version> <!-- Use the appropriate version -->
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.mockito</groupId>
<artifactId>mockito-inline</artifactId>
<version>4.11.0</version>
<scope>test</scope>
</dependency>
```

**Gradle Dependencies**:
```groovy
testImplementation 'org.mockito:mockito-core:4.11.0'
testImplementation 'org.mockito:mockito-inline:4.11.0'
```

2. **Write a Test Class with Static Method Mocking**:

Use `Mockito.mockStatic()` to mock static methods within a test. This method
returns a `MockedStatic` object that needs to be closed after the test.

**Example**:
```java
import org.junit.jupiter.api.Test;
import org.mockito.MockedStatic;
import org.mockito.Mockito;

import static org.mockito.Mockito.*;

public class StaticMethodExampleTest {

@Test
void testStaticMethodMocking() {
try (MockedStatic<StaticClass> mockedStatic =
Mockito.mockStatic(StaticClass.class)) {
// Define the behavior of the static method
mockedStatic.when(StaticClass::staticMethod).thenReturn("Mocked
Response");

// Call the static method

String result = StaticClass.staticMethod();
System.out.println(result); // Output: Mocked Response

// Verify that the static method was called

mockedStatic.verify(StaticClass::staticMethod);
}
}
}

// Example class with a static method

class StaticClass {
public static String staticMethod() {
return "Original Response";
}
}
```

3. **Explanation**:
- **`mockStatic()`**: Creates a mock for the specified class and allows stubbing
static methods.
- **Try-with-resources**: The `MockedStatic` object must be closed after use to
restore the original behavior of the static method. Using try-with-resources
ensures automatic closure.
- **`when()`** and **`thenReturn()`**: Used to define the behavior of the static
method when called.

4. **Verify Static Method Call**:

The `verify()` method within `mockedStatic` can be used to check if the static
method was called as expected.

**Example Verification**:
```java
mockedStatic.verify(StaticClass::staticMethod, times(1));
```

### Key Points:

- **Isolated Mocking**: Each use of `mockStatic()` creates an isolated mock scope.
- **Thread Safety**: Mocking static methods in a multi-threaded environment can
lead to unexpected results if not used carefully.
- **Mockito Version**: Ensure you are using Mockito 3.4.0 or higher to access
static method mocking capabilities.

### Alternative Libraries:

For projects that need more advanced static mocking, you can consider:
- **PowerMock**: An older tool that works with both static and private methods, but
it requires additional configuration and is more complex.
- **MockK**: A popular library for Kotlin that supports static method mocking and
works in Java as well.

By following these steps, you can effectively mock static methods in your JUnit 5
tests with minimal configuration using modern Mockito features.
================================
Mocking constructors directly in JUnit 5 using **Mockito** is not supported
natively. However, **PowerMock** was traditionally used for mocking constructors.
If you need to mock constructors, consider using **PowerMock** or **Mockito-
inline** with tools like **Objenesis** for complex scenarios. Here’s how to handle
constructor mocking:

### 1. Using PowerMock (Legacy Tool)

**PowerMock** allows you to mock constructors, static methods, and private methods,
but it has some limitations and may not be compatible with the latest versions of
JUnit 5 and Mockito. You may need to integrate it with JUnit 4 or use an older test
framework.

**Maven Dependencies**:
```xml
<dependency>
<groupId>org.powermock</groupId>
<artifactId>powermock-module-junit4</artifactId>
<version>2.0.9</version> <!-- Ensure compatibility -->
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.powermock</groupId>
<artifactId>powermock-api-mockito2</artifactId>
<version>2.0.9</version>
<scope>test</scope>
</dependency>
```

**Example**:
```java
import org.junit.Test;
import org.junit.runner.RunWith;
import org.mockito.Mockito;
import org.powermock.api.mockito.PowerMockito;
import org.powermock.core.classloader.annotations.PrepareForTest;
import org.powermock.modules.junit4.PowerMockRunner;

@RunWith(PowerMockRunner.class)
@PrepareForTest(TargetClass.class)
public class ConstructorMockTest {

@Test
public void testMockConstructor() throws Exception {
// Mock the constructor of TargetClass
TargetClass mockInstance = PowerMockito.mock(TargetClass.class);

PowerMockito.whenNew(TargetClass.class).withAnyArguments().thenReturn(mockInstance)
;

// Define behavior
Mockito.when(mockInstance.someMethod()).thenReturn("Mocked Response");

// Instantiate the object and call the method

TargetClass target = new TargetClass();
String response = target.someMethod();

System.out.println(response); // Output: Mocked Response

// Verify constructor call

PowerMockito.verifyNew(TargetClass.class).withNoArguments();
}
}
```

### 2. Using Java Reflection & Objenesis (Advanced)

If you want to avoid PowerMock and need an alternative for mocking constructors,
you can use **Objenesis** for creating objects without invoking constructors. This
approach is more complex and may be suitable for very specific use cases.

### 3. Using Mockito with Dependency Injection (Preferred)

Instead of mocking constructors directly, use **dependency injection** to pass

dependencies to your classes. This approach allows easier testing and adheres to
good design principles.

**Example**:
```java
public class Service {
private final Dependency dependency;

public Service(Dependency dependency) {

this.dependency = dependency;
}
 public String performAction() {
return dependency.doSomething();
}
}

// Test with constructor injection:

import org.junit.jupiter.api.Test;
import static org.mockito.Mockito.*;

public class ServiceTest {

@Test
void testService() {
// Mock the dependency
Dependency mockDependency = mock(Dependency.class);
when(mockDependency.doSomething()).thenReturn("Mocked Result");

// Inject the mock

Service service = new Service(mockDependency);

// Assert the result

System.out.println(service.performAction()); // Output: Mocked Result
}
}
```

### Key Points:

- **Avoid Constructor Mocking if Possible**: Using dependency injection makes
classes easier to test and maintain.
- **PowerMock for Legacy Code**: Use **PowerMock** only if you need to mock
constructors in legacy code where refactoring is not an option.
- **Mockito & Reflection**: For simpler, cleaner testing, rely on dependency
injection and mocking objects passed into constructors rather than the constructors
themselves.
==================================
The `substring()` method in Java is used to extract a portion of a `String`
starting from a specified index up to another index or to the end of the string.

### Syntax:
```java
String substring(int beginIndex)
String substring(int beginIndex, int endIndex)
```

### Parameters:
- **`beginIndex`**: The starting index (inclusive) of the substring. It must be
between `0` and the length of the string.
- **`endIndex`** (optional): The ending index (exclusive) of the substring. It must
be between `beginIndex` and the length of the string.

### Explanation:
- The character at `beginIndex` is included in the substring.
- The character at `endIndex` is not included in the substring.

### Examples:
1. **Substring from a specified start index to the end**:
```java
String str = "Hello, World!";
 String result = str.substring(7);
System.out.println(result); // Output: "World!"
```
- Starts at index `7` (`W`) and goes to the end.

2. **Substring between two indices**:

```java
String str = "Hello, World!";
String result = str.substring(0, 5);
System.out.println(result); // Output: "Hello"
```
- Starts at index `0` (`H`) and ends at index `5` (excludes the character at
index `5`, which is `,`).

### Important Notes:

- **Index Out of Bounds**: If `beginIndex` or `endIndex` is negative, greater than
the string length, or if `beginIndex` is greater than `endIndex`, the method throws
a `StringIndexOutOfBoundsException`.
- **Immutability**: The `substring()` method does not change the original string.
It returns a new string that represents the extracted part.

### Example with Error Handling:

```java
try {
String str = "Java Programming";
String sub = str.substring(5, 20); // This will throw an exception
System.out.println(sub);
} catch (StringIndexOutOfBoundsException e) {
System.out.println("Invalid index: " + e.getMessage());
}
```

### Performance Consideration:

- In older versions of Java (before Java 7), `substring()` could share the same
`char[]` of the original string, leading to potential memory leaks if the original
string was large and only a small portion was needed. Since Java 7, `substring()`
creates a new `char[]`, avoiding this issue.
Note : concatenation is possible between String and StringBuilder and String
Builder size is not fixed and it will increase automatically once it reaches it's
default capacity.
=====================================================
In your code:

```java
Boolean x = new Boolean("yes");
Boolean y = new Boolean("no");
System.out.println((x == y) + ":" + x.equals(y));
```

The `Boolean` class in Java interprets the strings `"yes"` and `"no"` differently
than you might expect. Here's a detailed explanation:

### **Key Points:**

1. **Boolean Constructor Behavior**:

The `Boolean` constructor takes a `String` argument and evaluates its value
case-insensitively:
- If the string equals `"true"` (ignoring case), the `Boolean` object represents
`true`.
 - For any other string, the `Boolean` object represents `false`.

In your example:
- `new Boolean("yes")` creates a `Boolean` object with the value `false`.
- `new Boolean("no")` also creates a `Boolean` object with the value `false`.

2. **Reference Comparison (`==`)**:

The expression `(x == y)` checks if `x` and `y` refer to the same object. Since
`new Boolean("yes")` and `new Boolean("no")` create **two distinct objects**, `x ==
y` evaluates to `false`.

3. **Value Comparison (`.equals()`)**:

The `equals()` method in the `Boolean` class checks if the **value** of the two
objects is the same. Since both `x` and `y` have the value `false`, `x.equals(y)`
evaluates to `true`.

### **Output Explanation:**

- `(x == y)` → `false` (different objects).
- `x.equals(y)` → `true` (same logical value: `false`).

Thus, the output of your program will be:

```
false:true
```

### **Important Note:**

Using the `Boolean` constructor is generally discouraged as it can lead to
unexpected behavior. Instead, prefer:
- `Boolean.valueOf(String)` for parsing strings into `Boolean` objects.
- Direct use of `true` and `false` for clarity.
========================
When writing a thread class in Java, there are two main approaches:

1. **Extend `Thread` Class**:

This is useful if you want to override `Thread`'s methods directly or need a
standalone thread class.

2. **Implement `Runnable` Interface** (Preferred):

This is a better approach as it allows you to extend other classes and promotes
better design by separating the thread's task from the thread's mechanism.

---

### **Preferred Approach: Implementing `Runnable`**

```java
public class MyRunnableTask implements Runnable {

@Override
public void run() {
// Task to be executed in the thread
for (int i = 1; i <= 5; i++) {
System.out.println(Thread.currentThread().getName() + " is running: " +
i);
try {
Thread.sleep(500); // Simulate some delay
} catch (InterruptedException e) {
System.out.println("Thread was interrupted: " + e.getMessage());
}
 }
}

public static void main(String[] args) {

// Create an instance of the task
MyRunnableTask task = new MyRunnableTask();

// Create and start threads

Thread thread1 = new Thread(task, "Worker-1");
Thread thread2 = new Thread(task, "Worker-2");

thread1.start();
thread2.start();
}
}
```

**Advantages**:
- Allows extending other classes since you’re not bound to extend `Thread`.
- Promotes a cleaner design as tasks and thread behavior are decoupled.

---

### **Using `Thread` Class**

```java
public class MyThread extends Thread {

@Override
public void run() {
// Task to be executed in the thread
for (int i = 1; i <= 5; i++) {
System.out.println(getName() + " is running: " + i);
try {
Thread.sleep(500); // Simulate some delay
} catch (InterruptedException e) {
System.out.println("Thread was interrupted: " + e.getMessage());
}
}
}

public static void main(String[] args) {

// Create and start threads
MyThread thread1 = new MyThread();
MyThread thread2 = new MyThread();

thread1.setName("Worker-1");
thread2.setName("Worker-2");

thread1.start();
thread2.start();
}
}
```

**Advantages**:
- Slightly easier for beginners to understand and implement.
- Involves fewer steps compared to implementing `Runnable`.
---

### **When to Choose Which?**

- **Use `Runnable`**: When your thread task does not require overriding `Thread`
methods and you need flexibility for class inheritance.
- **Use `Thread`**: When you need to directly override thread-specific methods or
for small standalone examples.

### **Best Practices**:

1. **Avoid Extending `Thread` Unless Necessary**:
- Prefer implementing `Runnable` or using `Callable` for tasks that return
values.
2. **Use Executors for Thread Management**:
For most production scenarios, instead of creating threads manually, use the
`ExecutorService` framework for managing thread pools.
```java
ExecutorService executor = Executors.newFixedThreadPool(2);
executor.submit(new MyRunnableTask());
executor.shutdown();
```
This approach is safer, more efficient, and avoids manual thread management.
=====================================
In the context of **PostgreSQL**, "what is left after a JOIN" refers to how
**result sets** are generated based on the type of JOIN you use. Specifically, it
relates to the **rows included in the result set** after the JOIN condition is
evaluated.

---

### **Types of Joins in PostgreSQL** and What is "Left After Join":

#### 1. **INNER JOIN**

- **Keeps only matching rows** from both tables based on the JOIN condition.
- Rows that do not satisfy the condition are excluded.

**Query Example:**
```sql
SELECT employees.name, departments.department_name
FROM employees
INNER JOIN departments
ON employees.department_id = departments.id;
```

**What is left after the JOIN?**

- Only rows where `employees.department_id = departments.id`.

---

#### 2. **LEFT JOIN (or LEFT OUTER JOIN)**

- **Keeps all rows from the left table**, regardless of whether there is a match in
the right table.
- For rows in the left table without a match, columns from the right table are
filled with `NULL`.

**Query Example:**
```sql
SELECT employees.name, departments.department_name
FROM employees
LEFT JOIN departments
ON employees.department_id = departments.id;
```

**What is left after the JOIN?**

- All rows from the `employees` table.
- If an employee doesn’t have a matching `department_id` in the `departments`
table, `department_name` will be `NULL`.

---

#### 3. **RIGHT JOIN (or RIGHT OUTER JOIN)**

- **Keeps all rows from the right table**, regardless of whether there is a match
in the left table.
- For rows in the right table without a match, columns from the left table are
filled with `NULL`.

**Query Example:**
```sql
SELECT employees.name, departments.department_name
FROM employees
RIGHT JOIN departments
ON employees.department_id = departments.id;
```

**What is left after the JOIN?**

- All rows from the `departments` table.
- If a department doesn’t have matching employees, `employees.name` will be `NULL`.

---

#### 4. **FULL OUTER JOIN**

- **Keeps all rows from both tables**.
- Rows without a match in either table will have `NULL` in the columns of the table
without a match.

**Query Example:**
```sql
SELECT employees.name, departments.department_name
FROM employees
FULL OUTER JOIN departments
ON employees.department_id = departments.id;
```

**What is left after the JOIN?**

- All rows from both `employees` and `departments`.
- Non-matching rows from either table will have `NULL` in the columns from the
other table.

---

#### 5. **CROSS JOIN**

- **Returns the Cartesian product** of the two tables.
- Every row from the first table is combined with every row from the second table.

**Query Example:**
```sql
SELECT employees.name, departments.department_name
FROM employees
CROSS JOIN departments;
```

**What is left after the JOIN?**

- Every combination of rows from `employees` and `departments`.
- No filtering or matching is done.

---

#### 6. **SELF JOIN**

- A table is joined with itself.

**Query Example:**
```sql
SELECT e1.name AS Employee1, e2.name AS Employee2
FROM employees e1
JOIN employees e2
ON e1.manager_id = e2.id;
```

**What is left after the JOIN?**

- Rows where `e1.manager_id = e2.id`.
- It represents relationships between employees and their managers.

---

### **General Explanation**

After a JOIN in PostgreSQL:
- The resulting rows are determined by the type of JOIN.
- **Matching rows** are retained (or all rows from one/both tables, depending on
the JOIN type).
- **Non-matching rows** might be excluded or padded with `NULL`.

---

### **Visualization Example**

Assume we have two tables:

#### `employees`:
| id | name | department_id |
|----|-----------|---------------|
| 1 | Alice | 10 |
| 2 | Bob | 20 |
| 3 | Charlie | NULL |

#### `departments`:
| id | department_name |
|----|-----------------|
| 10 | HR |
| 20 | IT |
| 30 | Marketing |

---

**INNER JOIN:**
```sql
SELECT employees.name, departments.department_name
FROM employees
INNER JOIN departments
ON employees.department_id = departments.id;
```

| name | department_name |
|--------|-----------------|
| Alice | HR |
| Bob | IT |

---

**LEFT JOIN:**
```sql
SELECT employees.name, departments.department_name
FROM employees
LEFT JOIN departments
ON employees.department_id = departments.id;
```

| name | department_name |
|----------|-----------------|
| Alice | HR |
| Bob | IT |
| Charlie | NULL |

---

**RIGHT JOIN:**
```sql
SELECT employees.name, departments.department_name
FROM employees
RIGHT JOIN departments
ON employees.department_id = departments.id;
```

| name | department_name |
|--------|-----------------|
| Alice | HR |
| Bob | IT |
| NULL | Marketing |

---

**FULL OUTER JOIN:**

```sql
SELECT employees.name, departments.department_name
FROM employees
FULL OUTER JOIN departments
ON employees.department_id = departments.id;
```

| name | department_name |
|----------|-----------------|
| Alice | HR |
| Bob | IT |
| Charlie | NULL |
| NULL | Marketing |

---

This demonstrates how the type of JOIN determines what is "left after the join."
=============================================
In PostgreSQL, both `DELETE` and `TRUNCATE` are commands used to remove data from a
table, but they work in different ways and are used in different scenarios. Here's
a breakdown of the differences:

### 1. **DELETE Command**

- **Purpose**: Removes rows from a table based on a condition (or removes all rows
if no condition is specified).
- **Syntax**:
```sql
DELETE FROM table_name WHERE condition;
```
- Example:
```sql
DELETE FROM employees WHERE department = 'HR';
```
This deletes all rows in the `employees` table where the department is 'HR'.

- **Behavior**:
- Deletes rows one by one, which can be slower for large tables.
- Can be rolled back if used inside a transaction (`BEGIN`/`COMMIT`).
- Fires any triggers associated with `DELETE` on the table.
- Does not reset the table's auto-incrementing `SERIAL` column (if applicable).

- **Use Case**:
- When you need to remove specific rows based on a condition.
- When you want to retain the table structure and any constraints (like foreign
keys) intact.

### 2. **TRUNCATE Command**

- **Purpose**: Removes all rows from a table, effectively emptying the table.
- **Syntax**:
```sql
TRUNCATE TABLE table_name;
```
- Example:
```sql
TRUNCATE TABLE employees;
```

- **Behavior**:
- **Faster than DELETE**: It doesn't scan rows or fire triggers, so it can be
significantly quicker, especially for large tables.
- **Resets the auto-increment sequence**: If the table has a `SERIAL` column,
`TRUNCATE` will reset the sequence back to its starting value.
- **Cannot delete specific rows**: Unlike `DELETE`, `TRUNCATE` removes all rows
in the table.
- **Cannot be rolled back** in certain cases (depending on transaction settings).
If you're in a transaction block and the `TRUNCATE` command is issued, it can be
rolled back, but some database configurations may treat it differently.
- **No triggers fired**: Does not activate `DELETE` triggers.
- **Faster**: Since it doesn't involve scanning and row-by-row deletion, it's
faster than `DELETE` for clearing large tables.

- **Use Case**:
- When you want to completely empty a table (remove all rows) without concern for
individual row-level triggers or conditions.
- Useful for clearing tables in staging, testing, or during batch operations.
### Key Differences Between `DELETE` and `TRUNCATE`:
| Feature | `DELETE` | `TRUNCATE`
|
|------------------------|-------------------------------------|-------------------
---------------|
| Removes rows based on condition | Yes, you can specify a `WHERE` clause | No,
removes all rows |
| Performance | Slower for large tables due to row-by-row deletion |
Faster, no row-by-row deletion |
| Auto-increment reset | No | Yes
|
| Triggers | Fires `DELETE` triggers | Does not fire
triggers |
| Rollback | Can be rolled back in transactions | Can be rolled back
in some cases |
| Locking | Row-level locks | Table-level lock
|
| Foreign Key Constraints| Checked (can raise errors) | Depends on the
`CASCADE` option |

### Example of Usage:

#### DELETE Example:

```sql
-- Delete all rows from 'employees' where the department is 'HR'
DELETE FROM employees WHERE department = 'HR';
```

#### TRUNCATE Example:

```sql
-- Truncate the 'employees' table (remove all rows)
TRUNCATE TABLE employees;
```

### When to Use Each:

- **Use `DELETE`** when:
- You want to remove specific rows.
- You need to retain the structure and constraints of the table.
- You want to trigger `DELETE` triggers or handle cascading deletes.

- **Use `TRUNCATE`** when:

- You want to quickly empty the entire table.
- You don't need to worry about row-level triggers or foreign key constraints.
- You want to reset the `SERIAL` column value.

Let me know if you need further details or examples!

=============================================================
In **Spring Framework** (specifically Spring MVC and Spring Boot), both
`@Controller` and `@RestController` are annotations used to define controller
classes that handle HTTP requests. However, there are key differences in how they
work, and they are used in different contexts based on whether you're building
traditional web applications or RESTful APIs.

### 1. **@Controller**

The `@Controller` annotation is used to define a Spring MVC controller class. This
type of controller is typically used in **web applications** where the response is
often a **view** (e.g., a JSP, Thymeleaf template, or HTML page). It is part of the
**Model-View-Controller (MVC)** pattern.
#### Key Characteristics:
- **Return a View**: A controller annotated with `@Controller` typically returns a
**view name** (like "home" or "index") that will be resolved by a view resolver
(such as `Thymeleaf`, `JSP`, etc.) to render an HTML page.
- **Uses View Resolvers**: It often involves combining the model (data) with a view
(UI) to generate a response to the user.
- **Handles Form Data**: Commonly used to handle user input, form submissions, and
direct rendering of pages.
- **Response Body**: By default, methods in `@Controller` do not return the
response body directly; instead, they are generally used to return views, and the
view rendering is handled by the framework.

#### Example:
```java
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;

@Controller
public class MyController {

// Mapping to the "/home" URL, returns a view

@RequestMapping("/home")
public String homePage() {
return "home"; // Returns "home.jsp" or "home.html" to render the page
}
}
```

- In this example, the `homePage()` method returns the name of a view (`home`),
which will be resolved to a file like `home.jsp` or `home.html` based on the
configured view resolver.

### 2. **@RestController**

The `@RestController` annotation is a specialized version of `@Controller` that is

used for building **RESTful web services** (APIs). When a controller is annotated
with `@RestController`, it is designed to handle HTTP requests and return **data**
(often in JSON or XML format) instead of views. It automatically assumes that the
response body will be serialized (typically as JSON or XML) and sent back to the
client.

#### Key Characteristics:

- **Returns Data**: Methods in a `@RestController` class return data (usually
POJOs), which are automatically serialized into JSON or XML using message
converters (like `Jackson` for JSON).
- **No View Rendering**: Unlike `@Controller`, `@RestController` does not involve
view resolvers. It returns plain data (e.g., JSON or XML) in the HTTP response
body.
- **Simplified**: `@RestController` is a shortcut for `@Controller` combined with
`@ResponseBody`. This means every method in `@RestController` automatically returns
data in the response body, without needing `@ResponseBody` on each individual
method.

#### Example:
```java
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;
@RestController
public class MyRestController {

// Mapping to the "/api/data" URL, returns a JSON object

@GetMapping("/api/data")
public MyData getData() {
return new MyData("Hello", "World");
}
}

class MyData {
private String greeting;
private String target;

public MyData(String greeting, String target) {

this.greeting = greeting;
this.target = target;
}

// Getters and Setters

}
```

- In this example, the `getData()` method returns an instance of `MyData`, and

Spring will automatically convert it into a JSON response like:
```json
{
"greeting": "Hello",
"target": "World"
}
```

### Key Differences Between `@Controller` and `@RestController`

| **Feature** | **@Controller** |
**@RestController** |
|------------------------------|------------------------------------------|--------
-----------------------------------------|
| **Purpose** | Used to define controllers that handle web
requests and return views. | Used to define RESTful web services that return data
(usually JSON or XML). |
| **Response Type** | Typically returns a **view name** (e.g.,
`home.jsp`) that gets rendered as HTML. | Returns data (POJOs) directly as JSON or
XML, automatically serialized. |
| **Return Value** | Returns a **view name** or **ModelAndView**. |
Returns the response body (e.g., a POJO, a list of objects). |
| **View Rendering** | Involves rendering views (e.g., JSP, Thymeleaf).
| No view rendering, just returning serialized data. |
| **Use Case** | Best for traditional **server-side rendered web
applications** (e.g., HTML pages). | Best for building **RESTful APIs** or
**microservices** that return data to the client. |
| **@ResponseBody** | Does not automatically apply `@ResponseBody` (you
can use it on individual methods). | Automatically applies `@ResponseBody` to all
methods. |
| **Example** | Typically returns HTML or a view to the browser.
| Typically returns JSON/XML data to the client. |

### When to Use Each:

- **Use `@Controller`** when:
- You are building a **traditional web application** where the response is a
**web page** (HTML, JSP, Thymeleaf, etc.).
- You need to handle user interaction through forms or view-based navigation.
- You want to use **server-side rendering**.

- **Use `@RestController`** when:

- You are building a **RESTful web service** or API where the response is usually
**data (JSON, XML)** rather than a view.
- You need to return data that will be consumed by clients, such as single-page
applications (SPAs), mobile apps, or other systems.

### Example Use Case Scenario:

- **`@Controller`**: A Spring MVC application that renders dynamic HTML pages using
JSP or Thymeleaf templates, with forms that the user submits to perform various
actions.
- **`@RestController`**: A Spring Boot application that exposes a REST API that
returns JSON data, which could be consumed by a front-end framework (like Angular,
React) or mobile applications.

### Summary:

- **`@Controller`**: Used in traditional MVC web applications where the response is

a view (HTML, JSP, etc.). The controller methods return a view name that will be
resolved by the view resolver.
- **`@RestController`**: Used for building REST APIs where the response is data
(usually JSON or XML). It automatically serializes objects returned by controller
methods into the appropriate response format.
============================================
In Java, **private static methods** cannot be **overridden** in the typical sense
of method overriding, because **overriding** refers to a subclass providing a
specific implementation of a method that is already defined in its superclass, and
this applies to instance methods (non-static). However, there are some nuances to
consider when discussing private static methods and how they are handled in
inheritance:

### 1. **Private Methods Cannot Be Overridden**:

- **Private methods** are **not inherited** by subclasses, meaning they are **not
visible** to subclasses. Therefore, private methods cannot be **overridden**
because the subclass doesn't have access to the private method in the parent class.

So, if a method is marked as **private**, it is not possible to override it in

the subclass, because it's not part of the subclass's method signature.

```java
class Parent {
private void show() {
System.out.println("Parent's private method");
}
}

class Child extends Parent {

// This will NOT override the parent's method
private void show() {
System.out.println("Child's private method");
}
}
```
 - In this case, the `show()` method in `Child` does not override the `show()`
method in `Parent` because it's private, and the child class does not have access
to the parent's private method.

### 2. **Static Methods and "Overriding"**:

- **Static methods** are not actually overridden in the same way as instance
methods. They are **resolved at compile-time** (i.e., based on the reference type),
not at runtime like instance methods.
- A static method in a subclass with the same signature as a static method in the
parent class is said to be **hiding** the parent method, not overriding it.

If a static method is private in the superclass, it cannot be accessed or hidden

by the subclass. However, if the static method is not private, it can be hidden by
defining a static method with the same name and parameters in the subclass.

```java
class Parent {
private static void show() {
System.out.println("Parent's private static method");
}
}

class Child extends Parent {

// This is NOT overriding, but hiding the static method
public static void show() {
System.out.println("Child's static method");
}
}
```

In this case:
- The `show()` method in `Child` **hides** the `show()` method in `Parent`, but
this is **not an override**.
- The method in the superclass is `private`, so the subclass cannot access it,
and the subclass defines its own method.

Even if the `show()` method in `Parent` were `protected` or `public`, it would

still be considered **method hiding**, not overriding.

### 3. **Method Hiding vs. Overriding**:

- **Method Hiding**: When a static method in the subclass has the same signature as
a static method in the superclass, the subclass method hides the superclass method.
This is not true overriding because static methods are resolved at compile time
based on the type of the reference, not the actual object.

```java
class Parent {
public static void show() {
System.out.println("Parent's static method");
}
}

class Child extends Parent {

public static void show() {
System.out.println("Child's static method");
}
}
```
 In this example:
- If you call `Parent.show()` or `Child.show()`, the corresponding method will be
called.
- But, if you reference an object using a superclass reference, it will call the
method defined in the superclass (even if the object is of the subclass type),
because static methods are not dynamically dispatched.

```java
public class Test {
public static void main(String[] args) {
Parent p = new Child();
p.show(); // Will call Parent's static method, not Child's, due to
method hiding
}
}
```

### 4. **Summary**:
- **Private Methods**: Private methods are not inherited or accessible by
subclasses, so they cannot be overridden. They are only accessible within the class
in which they are defined.
- **Static Methods**: Static methods can be hidden (not overridden) by a subclass
method with the same signature, but they are resolved at compile time based on the
reference type.
- If a static method in a parent class is private, it cannot be accessed or
hidden by a subclass.

### To conclude:
- **Private static methods cannot be overridden** (or even accessed) by subclasses.
- Static methods can be **hidden** in the subclass, but this is not true
overriding.
==================================================
In SQL, both the `LIKE` operator and the `GROUP BY` clause are used to filter or
organize data, but they serve different purposes. Let’s explore where and how each
of these can be used in SQL queries:

### 1. **`LIKE` Operator**

The `LIKE` operator is used for pattern matching in `WHERE` clauses, allowing you
to search for values that match a specified pattern. It's commonly used with string
data types.

#### Syntax:
```sql
SELECT column1, column2
FROM table_name
WHERE column_name LIKE pattern;
```

- **`LIKE`** works with wildcard characters to match parts of strings.

- `%` – Represents zero or more characters.
- `_` – Represents a single character.

#### Use Cases for `LIKE`:

- **Filtering String Data**: You can use `LIKE` to search for rows that contain,
start with, or end with a specific pattern in a column.
- **Wildcard Searches**: It's useful when you don't know the exact value but can
specify a pattern.

#### Example 1: Match rows where a column starts with a specific string:
```sql
SELECT name
FROM employees
WHERE name LIKE 'J%'; -- Finds names starting with 'J'
```

#### Example 2: Match rows where a column ends with a specific string:
```sql
SELECT email
FROM users
WHERE email LIKE '%@gmail.com'; -- Finds emails ending with '@gmail.com'
```

#### Example 3: Match rows where a column contains a specific string:

```sql
SELECT address
FROM customers
WHERE address LIKE '%Main Street%'; -- Finds addresses containing 'Main Street'
```

#### Example 4: Use with a single character:

```sql
SELECT product_name
FROM products
WHERE product_name LIKE '_pen'; -- Matches 'pen', 'Apen', 'Bpen', etc.
```

#### Note:
- `LIKE` is case-insensitive in some databases (like MySQL) but case-sensitive in
others (like PostgreSQL). You can use `ILIKE` for case-insensitive matching in
PostgreSQL.

---

### 2. **`GROUP BY` Clause**

The `GROUP BY` clause is used in SQL to group rows that have the same values into
summary rows. It is commonly used with aggregate functions (e.g., `COUNT()`,
`SUM()`, `AVG()`, `MAX()`, `MIN()`) to perform calculations on each group of data.

#### Syntax:
```sql
SELECT column1, aggregate_function(column2)
FROM table_name
WHERE condition
GROUP BY column1;
```

#### Use Cases for `GROUP BY`:

- **Summarizing Data**: Grouping data based on some column and applying aggregate
functions to calculate sums, averages, counts, etc.
- **Finding Unique Values**: Using `GROUP BY` with columns to get unique
combinations of those columns.

#### Example 1: Count the number of employees in each department:

```sql
SELECT department, COUNT(*)
FROM employees
GROUP BY department;
```
- This query groups the rows by the `department` column and counts how many
employees are in each department.

#### Example 2: Calculate the average salary for each department:

```sql
SELECT department, AVG(salary)
FROM employees
GROUP BY department;
```

- This query groups the rows by `department` and calculates the average salary for
each group.

#### Example 3: Get the maximum salary in each department:

```sql
SELECT department, MAX(salary)
FROM employees
GROUP BY department;
```

- This query finds the maximum salary for each department.

#### Example 4: Group by multiple columns:

```sql
SELECT country, city, COUNT(*)
FROM customers
GROUP BY country, city;
```

- This query groups the rows by both `country` and `city` and then counts how many
customers are in each unique combination of country and city.

#### Example 5: `HAVING` with `GROUP BY`:

You can use the `HAVING` clause to filter groups after they’ve been created by
`GROUP BY` (similar to how `WHERE` is used to filter rows before grouping).

```sql
SELECT department, COUNT(*)
FROM employees
GROUP BY department
HAVING COUNT(*) > 10; -- Only show departments with more than 10 employees
```

---

### Key Differences and When to Use Each:

- **`LIKE`** is used for **pattern matching** in the `WHERE` clause to filter rows
based on string patterns.
- Example: Filter all rows that match a specific text pattern (e.g., all emails
ending with '@gmail.com').
- **`GROUP BY`** is used to **group rows** and perform **aggregate functions** on
each group.
- Example: Summarize data by counting employees in each department or calculating
averages for groups.

### Combining `LIKE` and `GROUP BY`

You can also use `LIKE` and `GROUP BY` in the same query. For example, if you
wanted to count how many employees have a certain substring in their names and
group them by department, you could combine both:

#### Example:
```sql
SELECT department, COUNT(*)
FROM employees
WHERE name LIKE 'J%' -- Find employees whose name starts with 'J'
GROUP BY department;
```

In this query:
- The `WHERE` clause filters employees whose names start with 'J' using the `LIKE`
operator.
- The `GROUP BY` clause groups the filtered results by `department`, and `COUNT(*)`
gives the number of such employees in each department.

---

### Summary:

- **`LIKE`**: Used in the `WHERE` clause for pattern matching in string columns.
Useful for filtering rows based on string patterns (e.g., starts with, ends with,
contains).

- **`GROUP BY`**: Used to group rows based on one or more columns and apply
aggregate functions (e.g., `COUNT()`, `SUM()`, `AVG()`) to summarize data.

Both operators can be combined in a single query to filter and summarize data at
the same time.
===================================
If you want to apply the `HAVING` clause in a query to filter only the **HR
department**, while still grouping by department and counting the employees, you
would typically use the `WHERE` clause to filter for the **HR** department
**before** performing the grouping, and then apply the `HAVING` clause to filter
based on the count condition.

Here's how you can adjust your query:

### Query to Filter HR Department and Count Employees:

```sql
SELECT department, COUNT(*)
FROM employees
WHERE department = 'HR' -- Filter to only consider the HR department
GROUP BY department
HAVING COUNT(*) > 10; -- Only show if the HR department has more than 10
employees
```

### Explanation:
- **`WHERE department = 'HR'`**: Filters the rows to only include employees in the
**HR** department before the grouping happens.
- **`GROUP BY department`**: Groups the results by the department.
- **`HAVING COUNT(*) > 10`**: Filters the groups after the aggregation. It ensures
that only the HR department (if it has more than 10 employees) is included in the
result.

### When would the query return results?

- This query will return results if the **HR** department has **more than 10
employees**. If there are fewer than 10 employees in the HR department, no rows
will be returned.

### What if you want to check for HR department and any other department with more
than 10 employees?

If you want to check **all departments** and also specifically look for the **HR**
department having more than 10 employees, you can keep the `GROUP BY` and `HAVING`
clauses as they were originally, and then add a condition to check for **HR**
department specifically in the result set. For example:

```sql
SELECT department, COUNT(*)
FROM employees
GROUP BY department
HAVING COUNT(*) > 10
OR department = 'HR'; -- Specifically show HR department if it has less than or
more than 10 employees
```

In this case:
- The query will show **all departments** with more than 10 employees, but also
show the **HR** department regardless of the employee count.

---

### Summary:
- Use `WHERE department = 'HR'` to **filter** the rows for HR before grouping.
- Use `HAVING COUNT(*) > 10` to apply the condition after the group is created.
- If you need to include specific conditions like showing HR **regardless of
employee count**, use `HAVING` with an `OR` clause for specific logic.
================================================
In Java, especially when working with Spring (e.g., **Spring Boot**), it's common
to define **custom exceptions** and create a **global exception handler** to handle
those exceptions in a structured way. A global exception handler ensures that
exceptions are handled consistently across the application, without needing to
write exception-handling code in each controller.

### Step 1: Create a Custom Exception

A **custom exception** allows you to define specific types of errors that can occur
in your application, with custom messages and properties.

#### Example of a Custom Exception:

```java
public class ResourceNotFoundException extends RuntimeException {

// Optional: Add an ID or other specific fields if needed

private String resource;

public ResourceNotFoundException(String resource) {

super(resource + " not found");
this.resource = resource;
}

public String getResource() {

return resource;
}
}
```
- **`ResourceNotFoundException`** is a custom exception that extends
`RuntimeException`.
- The constructor accepts a `resource` (could be an entity name like `User` or
`Product`) and appends it to the default error message.
- This exception can be thrown when a resource is not found in the application.

### Step 2: Throw the Custom Exception in Your Application

Once you have created your custom exception, you can throw it when a specific error
condition occurs in your service or controller.

#### Example of throwing the custom exception in a service:

```java
@Service
public class UserService {

private final UserRepository userRepository;

public UserService(UserRepository userRepository) {

this.userRepository = userRepository;
}

public User findUserById(Long id) {

return userRepository.findById(id).orElseThrow(() ->
new ResourceNotFoundException("User with ID " + id)
);
}
}
```

- If the user with the given `id` is not found in the repository, the custom
exception `ResourceNotFoundException` is thrown.

### Step 3: Create a Global Exception Handler

In Spring, you can handle exceptions globally using **`@ControllerAdvice`**. This

annotation allows you to define a class where you can handle exceptions across the
whole application, rather than handling them locally in each controller.

#### Example of a Global Exception Handler with `@ControllerAdvice`:

```java
import org.springframework.http.HttpStatus;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.ExceptionHandler;
import org.springframework.web.bind.annotation.ControllerAdvice;

@ControllerAdvice
public class GlobalExceptionHandler {

// Handle the custom ResourceNotFoundException

@ExceptionHandler(ResourceNotFoundException.class)
public ResponseEntity<String>
handleResourceNotFoundException(ResourceNotFoundException ex) {
return new ResponseEntity<>(ex.getMessage(), HttpStatus.NOT_FOUND);
}

// Handle other generic exceptions

 @ExceptionHandler(Exception.class)
public ResponseEntity<String> handleGenericException(Exception ex) {
return new ResponseEntity<>("An unexpected error occurred: " +
ex.getMessage(), HttpStatus.INTERNAL_SERVER_ERROR);
}

// Optional: Handle validation or other specific exceptions (e.g.,

MethodArgumentNotValidException)
}
```

#### Explanation:
- **`@ControllerAdvice`**: This annotation marks the class as a global exception
handler. It can be used to handle exceptions for all controllers in your
application.
- **`@ExceptionHandler(ResourceNotFoundException.class)`**: This method will handle
exceptions of type `ResourceNotFoundException` and return a custom response. In
this case, it returns a `404 Not Found` status code along with the exception
message.
- **`handleGenericException`**: This method is used for generic exceptions. It
returns a `500 Internal Server Error` status with a generic error message.

### Step 4: Customize the Response (Optional)

You can customize the response further by returning a more structured error object,
such as an error code, a timestamp, or additional details. Here's an example of
returning a structured response:

#### Example of a Structured Error Response:

```java
public class ErrorResponse {
private String message;
private int statusCode;
private long timestamp;

public ErrorResponse(String message, int statusCode) {

this.message = message;
this.statusCode = statusCode;
this.timestamp = System.currentTimeMillis();
}

// Getters and setters...

}
```

You can then modify the `GlobalExceptionHandler` to return this `ErrorResponse`

object:

```java
@ControllerAdvice
public class GlobalExceptionHandler {

@ExceptionHandler(ResourceNotFoundException.class)
public ResponseEntity<ErrorResponse>
handleResourceNotFoundException(ResourceNotFoundException ex) {
ErrorResponse errorResponse = new ErrorResponse(ex.getMessage(),
HttpStatus.NOT_FOUND.value());
return new ResponseEntity<>(errorResponse, HttpStatus.NOT_FOUND);
 }

@ExceptionHandler(Exception.class)
public ResponseEntity<ErrorResponse> handleGenericException(Exception ex) {
ErrorResponse errorResponse = new ErrorResponse("An unexpected error
occurred: " + ex.getMessage(), HttpStatus.INTERNAL_SERVER_ERROR.value());
return new ResponseEntity<>(errorResponse,
HttpStatus.INTERNAL_SERVER_ERROR);
}
}
```

Now, instead of just returning a simple string message, the `ErrorResponse` object
is returned in the response body, providing a more structured and readable format.

---

### Step 5: Optional: Handling Validation Errors

In addition to custom exceptions, you might want to handle validation errors,

especially when using Spring’s `@Valid` annotation for form or request validation.

You can add a handler for **validation exceptions** like

`MethodArgumentNotValidException`:

```java
import org.springframework.validation.FieldError;
import org.springframework.web.bind.MethodArgumentNotValidException;

@ControllerAdvice
public class GlobalExceptionHandler {

// Handle validation errors

@ExceptionHandler(MethodArgumentNotValidException.class)
public ResponseEntity<ErrorResponse>
handleValidationException(MethodArgumentNotValidException ex) {
StringBuilder errorMessage = new StringBuilder();

for (FieldError fieldError : ex.getBindingResult().getFieldErrors()) {

errorMessage.append(fieldError.getField())
.append(": ")
.append(fieldError.getDefaultMessage())
.append("; ");
}

ErrorResponse errorResponse = new ErrorResponse(errorMessage.toString(),

HttpStatus.BAD_REQUEST.value());
return new ResponseEntity<>(errorResponse, HttpStatus.BAD_REQUEST);
}
}
```

This handles validation errors and builds a custom error message that lists all the
invalid fields and their respective error messages.

---

### Final Thoughts

- **Custom Exceptions**: By creating your own exceptions (e.g.,
`ResourceNotFoundException`), you can have more control over error handling in your
application. You can provide specific error messages, HTTP status codes, and custom
properties.
- **Global Exception Handling**: Using `@ControllerAdvice`, you can centralize and
standardize error handling, making your application more maintainable. You can
catch exceptions globally and return meaningful, structured error responses to the
client.
- **Structured Error Responses**: For better client-side error handling, it’s often
useful to return a structured error object (e.g., `ErrorResponse`) that includes
details like error codes, timestamps, and specific messages.

By following this approach, you can handle different types of exceptions in a

clear, consistent, and maintainable way across your entire Spring Boot application.
==================================================