Exceptions, Errors & Logging

Errors vs exceptions

You met try/catch briefly. Now we go deeper, because robust apps depend on it. First, two words that sound the same but are not. An exception is a problem you can *anticipate and handle* — a missing file, a failed payment, invalid input. An error (in the old sense) is usually a *bug* in your code — a typo, calling a function that does not exist. Modern PHP turns most of these into exception-like objects, so you can catch them too.

The point of exceptions is control: instead of the whole page dying with an ugly message, you decide what happens when something goes wrong.

try / catch / finally

You wrap risky code in try. If it throws, control jumps to catch. The finally block — new to you — always runs afterwards, whether things succeeded or failed; it is where you clean up (close files, release resources).

<?php
  function divide(int $a, int $b): float {
    if ($b === 0) {
      throw new InvalidArgumentException("Cannot divide by zero");
    }
    return $a / $b;
  }

  try {
    echo divide(10, 0);
  } catch (InvalidArgumentException $e) {
    echo "Problem: " . $e->getMessage();
  } finally {
    echo " (done)";
  }
?>

Step through it: divide(10, 0) checks for a zero divisor and, finding one, throws an InvalidArgumentException with a message. That throw immediately stops the try and jumps to the catch, where $e->getMessage() reads back the message we set. Then finally runs no matter what — here it prints (done) — which is where you would close a database connection or file handle.

Custom exception classes

For real apps you create your own exception types by extending the built-in Exception class. This lets you catch exactly the kind of failure you care about and ignore the rest — far more precise than catching everything.

<?php
  class PaymentFailedException extends Exception {}
  class OutOfStockException extends Exception {}

  function checkout(int $stock): string {
    if ($stock <= 0) {
      throw new OutOfStockException("That item is sold out");
    }
    return "Order placed!";
  }

  try {
    echo checkout(0);
  } catch (OutOfStockException $e) {
    echo "Sorry: " . $e->getMessage();
  } catch (PaymentFailedException $e) {
    echo "Payment issue: " . $e->getMessage();
  }
?>

We define two named exception types — they are empty classes that simply extends Exception, which is enough to give them their own identity. checkout(0) throws an OutOfStockException. Because we have a catch block specifically for that type, that block runs (and the unrelated PaymentFailedException catch is skipped). Each kind of failure gets its own tailored response.

Logging instead of showing errors

In production (a live site) you must never show raw error details to visitors — they leak information and look broken. Instead you log the problem to a file for yourself and show the user a calm, generic message. error_log() appends a line to a log file.

<?php
  try {
    // ... risky work, e.g. a database call ...
    throw new Exception("DB connection refused");
  } catch (Exception $e) {
    // for YOU: full detail goes to a private log file
    error_log($e->getMessage(), 3, "errors.log");
    // for the USER: a friendly, vague message
    echo "Sorry, something went wrong. Please try again later.";
  }
?>

error_log($e->getMessage(), 3, "errors.log") writes the real error text to a file named errors.log (the 3 means "append to this file"). The visitor, meanwhile, only ever sees the polite sentence in the echo — never the technical cause. You read the log; they read reassurance.