feat(exceptions): add notes and example on using generics with custom exceptions

WHAT:
- Explained why generic exception classes like `class MyGenericException<T> extends Exception` are not allowed in Java.
- Added example of `DetailedException<T>` that uses generics safely by keeping type information in fields rather than the class itself.
- Demonstrated throwing and catching a `DetailedException<Integer>` with additional error details.

WHY:
- In Java, all exceptions extend from `Throwable`. For runtime consistency, the JVM must know the concrete exception type.
- Due to **type erasure**, generic type parameters (like `<T>`) are erased at runtime, so the JVM cannot distinguish between
  `MyGenericException<Integer>` and `MyGenericException<String>`.
- This makes generic exception instantiation impossible, but we can still use generics to enrich exception details.

HOW:
- Defined `class DetailedException<T> extends Exception` with a generic field `T details`.
- Constructor accepts both a message (`String`) and details (`T`).
- `getDetails()` returns the type-safe extra data.
- Example: throwing `new DetailedException<Integer>("An error occurred", 404)` and catching it to retrieve both the message and extra detail.

KEY TAKEAWAYS:
1. **Checked vs Unchecked Exceptions**
   - `Exception` (checked): must be declared or handled.
   - `RuntimeException` (unchecked): don’t need explicit declaration/handling.
2. **Restrictions with Generics**
   - Cannot define `class MyGenericException<T> extends Exception` → compile-time error.
   - Reason: **type erasure** removes `<T>` at runtime.
3. **Safe Pattern**
   - Store generic data inside an exception (fields), not in its type.
   - This allows passing extra type-safe diagnostic data while keeping exception hierarchy valid.

REAL-WORLD USE CASES:
- Wrapping domain-specific errors with structured details:
  - Example: `DetailedException<OrderId>` for invalid order references.
  - Example: `DetailedException<ErrorCode>` in APIs for passing numeric error codes alongside messages.
- Improves debugging and error-handling workflows by attaching context data directly to exceptions.

Signed-off-by: https://github.com/Someshdiwan <[email protected]>

Author: Someshdiwan

Section24JavaGenerics/src/GenericExceptions/Generic Exceptions in Java.txt

@@ -0,0 +1,78 @@
+In Java, exceptions are objects that represent an error or unexpected condition during the execution of a program.
+
+All exceptions in Java are descendants of Throwable, which has two main subclasses:
+
+Exception: Represents checked exceptions (those that need to be declared or handled).
+RuntimeException: Represents unchecked exceptions (those that don’t need to be declared or handled).
+Here’s an example of a basic custom exception:
+
+class MyException extends Exception {
+    public MyException(String message) {
+        super(message);
+    }
+}
+Understanding Generic Exceptions
+
+Generics allow us to parameterize types (as discussed in earlier points).
+
+The concept of generics can be applied to exceptions as well. However, generic exceptions have certain restrictions
+due to how Java handles exceptions.
+
+Key Restriction:
+You cannot create instances of generic types as exceptions: The Java runtime needs to be able to construct exceptions
+based on the exact type. But due to type erasure (discussed later), the JVM loses the specific type information at runtime.
+
+Thus, the direct usage of generic types in exceptions is limited.
+
+For example, the following is not allowed:
+
+class MyGenericException<T> extends Exception {  // Compilation error
+    private T data;
+
+    public MyGenericException(T data) {
+        this.data = data;
+    }
+}
+
+This will cause a compilation error because the type T is erased at runtime, and Java can't determine what specific
+exception to instantiate.
+
+Advanced Generic Exception Patterns:
+
+Even though you can’t directly instantiate generic exceptions, there are still advanced patterns and techniques to
+incorporate generic behaviour in exceptions. Here’s how:
+
+Using Generics with Exception Messages or Fields:
+
+You can include generic types in the fields or messages of exceptions instead of trying to make the exception class
+itself generic.
+
+Example:
+class DetailedException<T> extends Exception {
+    private T details;
+
+    public DetailedException(String message, T details) {
+        super(message);
+        this.details = details;
+    }
+
+    public T getDetails() {
+        return details;
+    }
+}
+
+public class Main {
+    public static void main(String[] args) {
+        try {
+            throw new DetailedException<Integer>("An error occurred", 404);
+        } catch (DetailedException<Integer> e) {
+            System.out.println(e.getMessage());  // Output: An error occurred
+            System.out.println(e.getDetails());  // Output: 404
+        }
+    }
+}
+
+In this case, the DetailedException class contains a generic field details that can hold extra information about the
+exception.
+
+This information could be anything, such as the problematic value or other diagnostic data.