In Oracle PL/SQL, explain how exceptions are raised, including both system raised exceptions and user defined exceptions raised with RAISE or RAISE_APPLICATION_ERROR.

Introduction / Context:
Exception handling is a core feature of PL/SQL that helps you react to error conditions in a controlled way. To handle exceptions correctly, you must first understand how they are raised. This question asks you to explain both system raised exceptions and user raised exceptions in Oracle PL/SQL.

Given Data / Assumptions:

• PL/SQL blocks may encounter runtime errors such as constraint violations or conversion problems.
• Oracle has predefined exceptions for common errors and allows developers to define their own.
• There are specific statements used to raise exceptions from code.
• Exception sections handle these events using WHEN clauses.

Concept / Approach:
Exceptions in PL/SQL are raised in two main ways. First, the PL/SQL engine automatically raises predefined or numbered exceptions when it detects runtime errors, such as NO_DATA_FOUND or DUP_VAL_ON_INDEX. Second, programmers can explicitly raise exceptions. The RAISE statement can be used for named exceptions that have already been declared. The RAISE_APPLICATION_ERROR procedure lets developers raise custom error numbers in the range allowed for user errors along with descriptive messages. Both system and user raised exceptions transfer control to the EXCEPTION section of the current block or propagate outward if not handled.

Step-by-Step Solution:
Step 1: Recognise that Oracle automatically raises exceptions for runtime errors such as dividing by zero, violating constraints, or selecting wrong numbers of rows with SELECT INTO.Step 2: Understand that each such error corresponds to an Oracle error number and often to a predefined PL/SQL exception name, for example ZERO_DIVIDE or VALUE_ERROR.Step 3: For user defined exceptions, declare an exception variable with syntax such as my_error EXCEPTION; in the declarative section.Step 4: Use RAISE my_error; somewhere in the executable section when a logical condition indicates that a business rule has been violated.Step 5: When you need a custom error number and message that can be seen by client applications, call RAISE_APPLICATION_ERROR with an error code and text, such as RAISE_APPLICATION_ERROR(-20001, 'Invalid order status').

Verification / Alternative check:
You can verify how exceptions are raised by writing small PL/SQL blocks that intentionally trigger system errors or call RAISE and RAISE_APPLICATION_ERROR. Watching how control jumps to the EXCEPTION section and how error messages appear in client tools confirms the raising mechanism. Observing that unhandled exceptions propagate to callers demonstrates the propagation rules as well.

Why Other Options Are Wrong:
Option B incorrectly states that exceptions only occur when the database restarts. Option C claims that Java procedures are the only source of exceptions, which is false because PL/SQL itself raises and handles exceptions. Option D suggests that operating system signals are required, which is not how PL/SQL error handling works.

Common Pitfalls:
A frequent mistake is using WHEN OTHERS to catch all exceptions but not re raising them or logging details, which can hide important errors. Another pitfall is misusing RAISE_APPLICATION_ERROR codes outside the supported range. Proper exception design uses specific handlers where possible and ensures that critical errors are logged and, if needed, propagated to the caller.

Final Answer:
Exceptions in PL/SQL can be raised automatically by the runtime engine when predefined error conditions occur, or raised explicitly by the programmer using statements such as RAISE for named exceptions and RAISE_APPLICATION_ERROR for custom error numbers and messages.