Since PHP 7, both Errors and Exceptions implement the Throwable interface, but they represent different kinds of problems.

Interview tip: Mention that both extend the Throwable interface, so a single catch (Throwable $e) block can catch either - useful as a last-resort safety net at the top of an application.

The try block contains code that might fail. The catch block handles the exception if one is thrown. The finally block always runs, whether an exception occurred or not - used for cleanup.

function readFile(string $path): string {
    $handle = fopen($path, 'r');
    try {
        if (!$handle) {
            throw new RuntimeException('Cannot open file');
        }
        return fread($handle, filesize($path));
    } catch (RuntimeException $e) {
        echo 'Error: ' . $e->getMessage();
        return '';
    } finally {
        if ($handle) {
            fclose($handle);
        }
    }
}

Interview tip: Emphasize that finally runs even when the try or catch block contains a return statement - a common trick question.

Create a class that extends Exception (or a more specific built-in subclass) to represent domain-specific error conditions with extra context.

class InsufficientFundsException extends Exception {
    public function __construct(
        private float $requested,
        private float $available
    ) {
        parent::__construct(
            "Requested {$requested} but only {$available} available"
        );
    }

    public function getShortfall(): float {
        return $this->requested - $this->available;
    }
}

function withdraw(float $amount, float $balance): void {
    if ($amount > $balance) {
        throw new InsufficientFundsException($amount, $balance);
    }
}

try {
    withdraw(500, 200);
} catch (InsufficientFundsException $e) {
    echo $e->getMessage();
    echo 'Shortfall: ' . $e->getShortfall();
}

Interview tip: Point out that custom exceptions let you catch specific business errors separately from generic ones, and can carry structured data (like getShortfall() here) instead of just a string message.

Throwable is the top-level interface implemented by both Error and Exception. Catching Exception only catches application-level exceptions; catching Throwable catches everything, including engine-level Errors like TypeError.

try {
    strlen(); // ArgumentCountError - an Error, not an Exception
} catch (Exception $e) {
    echo 'This will NOT catch it';
} catch (Throwable $e) {
    echo 'This WILL catch it: ' . $e->getMessage();
}

Interview tip: Recommend using catch (Throwable $e) only at the outermost boundary of an app (e.g. a global handler) to prevent white-screen crashes, not as a routine replacement for specific exception catching.

The finally block runs in almost all cases - after normal completion, after a caught exception, after an uncaught exception propagates further, and even if try/catch contains a return statement.

Interview tip: The exit()/die() case is the detail that separates a strong answer from a memorized one - always mention it.

PHP allows catching multiple exception types in one catch block using the pipe | separator, avoiding repeated identical catch bodies.

try {
    processPayment();
} catch (InsufficientFundsException | CardDeclinedException $e) {
    echo 'Payment failed: ' . $e->getMessage();
    logPaymentFailure($e);
} catch (Throwable $e) {
    echo 'Unexpected error occurred';
    logCriticalError($e);
}

Interview tip: Mention the catch order rule explicitly - putting a general catch (Throwable) before a specific one makes the specific one unreachable, which is a real bug PHP will not warn you about at compile time in older versions.

These functions let you override PHP's default handling of errors and uncaught exceptions with your own logic - commonly used to log issues centrally instead of showing raw output.

set_error_handler(function ($errno, $errstr, $errfile, $errline) {
    error_log("Error [$errno]: $errstr in $errfile on line $errline");
    return true; // prevents PHP's default handler from also running
});

set_exception_handler(function (Throwable $e) {
    error_log('Uncaught: ' . $e->getMessage());
    http_response_code(500);
    echo 'Something went wrong. Please try again later.';
});

Interview tip: Note that frameworks like Laravel already register their own global handlers internally (App\Exceptions\Handler), so in framework code you rarely call these directly - but understanding them is essential for plain PHP and legacy codebases.

PHP's Standard Library (SPL) provides a hierarchy of exception classes for common scenarios, so you don't need to write a custom exception for every case.

function setAge(int $age): void {
    if ($age < 0) {
        throw new InvalidArgumentException('Age cannot be negative');
    }
}

Interview tip: Using SPL exceptions instead of a generic Exception makes catch blocks more precise and self-documenting - reach for a custom exception only when SPL doesn't fit.

try {
    chargeCard($order);
} catch (Throwable $e) {
    Log::error($e->getMessage(), ['trace' => $e->getTraceAsString()]);

    if (app()->environment('production')) {
        return response()->json(['message' => 'Payment failed. Please try again.'], 500);
    }
    throw $e; // rethrow with full detail locally
}

Interview tip: This question tests security awareness as much as PHP knowledge - always mention that leaking stack traces in production can expose file paths, database structure, and even credentials.

Exception chaining lets you wrap a low-level exception inside a higher-level, more meaningful one while preserving the original cause. PHP's Exception constructor accepts a previous exception as its third argument.

class OrderProcessingException extends Exception {}

try {
    try {
        $pdo->query('INSERT INTO orders ...');
    } catch (PDOException $e) {
        throw new OrderProcessingException(
            'Failed to save order',
            0,
            $e // the original exception, preserved as the "previous" one
        );
    }
} catch (OrderProcessingException $e) {
    echo $e->getMessage();          // 'Failed to save order'
    echo $e->getPrevious()->getMessage(); // original PDOException message
}

Interview tip: This shows senior-level thinking - it demonstrates you understand layered architecture (e.g. repository layer errors shouldn't leak database-specific exceptions to the controller layer).