Error Handling Advanced

By the end of this lesson you'll catch failures gracefully with try / catch / finally , design your own exception classes, chain causes for clean logs, and report errors safely in production — so a single bad request never takes your whole app down.

Learn Python, JavaScript, Java and more with free interactive lessons, real projects and AI-powered help. Beginner-friendly.

Part of the free Php course at LearnCodingFast — hands-on lessons with examples you run in your browser, plus practice exercises and a quick quiz.

What You'll Learn in This Lesson

1️⃣ try / catch / finally

When code might fail, you wrap it in a try block. If anything inside throws an exception, PHP jumps straight to a matching catch block instead of crashing. An exception is simply an object that means "stop — something went wrong" and carries a message describing what. The optional finally block runs afterwards no matter what — success or failure — which makes it the perfect place for cleanup like closing a file or a database connection.

Read the output order carefully: for the failing case, the catch runs and then the finally still runs. That guarantee is why you put cleanup in finally rather than copying it into both the success and failure paths.

2️⃣ Errors vs Exceptions, and Catching Specific Types

PHP has two families of "throwable" things. An Exception is a recoverable problem your code raises on purpose with throw — bad input, a missing record. An Error (like TypeError or DivisionByZeroError ) is an engine-level fault, usually a bug. Both implement the Throwable interface, so catch (Throwable $e) catches either. The key habit: list your most specific catch first , because PHP uses the first one that matches.

Notice you can even catch an engine Error such as DivisionByZeroError . You generally shouldn't rely on that to paper over bugs, but it's invaluable as a last-resort net so one unexpected fault doesn't take down the whole request.

3️⃣ Custom Exception Classes

Throwing the generic Exception everywhere forces every caller to catch everything and then inspect the message string to figure out what happened. Instead, make your own types by writing class ValidationException extends Exception . Now you can catch (ValidationException $e) separately from a not-found error, and each class can carry extra data — here an HTTP status code — so the error knows how it should be handled.

4️⃣ Exception Chaining

Often a low-level failure (a file won't open) should become a clearer high-level one (the config can't load) — but you don't want to lose the original cause. Exception chaining solves this: when you re-throw, pass the original exception as the third constructor argument. Later, getPrevious() walks back to the root cause, so users see the friendly message while your logs keep the full trail.

5️⃣ Global Handlers, Logging & Dev vs Production

No matter how careful you are, something will eventually slip past every try . set_exception_handler() registers a last line of defence that runs for any uncaught exception, and set_error_handler() lets you turn old-style warnings into exceptions so they flow through the same path. The other half is where errors go : in production set display_errors to 0 so visitors never see raw errors (they leak paths and secrets), and send the details to a log with error_log() instead.

The golden rule sits in those two lines: log the full detail, show the user a friendly generic message. On your own machine you'd flip $isProduction to false and turn display_errors back on so you see everything immediately.

🎯 Your Turn

Now you try. The script below is almost complete — fill in each ___ using the 👉 hint, then run it and check it against the Output panel.

One more — this time you'll define a custom exception type and throw it. Fill in the extends keyword and the class name.

📋 Quick Reference — Error Handling

No code is filled in this time — just a brief and an outline. Write it yourself, run it on onecompiler.com/php or your own machine, then check your result against the expected output in the comments. This is the same throw → catch → cleanup loop you'll use in every real request handler.

Practice quiz

What interface do both Error and Exception implement?

  • Catchable
  • Stringable
  • Throwable
  • Iterator

Answer: Throwable. Everything you can throw implements Throwable, so catch (Throwable $e) is a true catch-all.

What is the difference between an Error and an Exception?

  • An Exception is a recoverable problem you throw; an Error is an engine-level fault
  • An Error is recoverable; an Exception is fatal
  • They are identical
  • Errors are thrown only in functions

Answer: An Exception is a recoverable problem you throw; an Error is an engine-level fault. You throw Exceptions on purpose for recoverable problems; the engine throws Errors (TypeError, etc.) for serious faults.

Will catch (Exception $e) catch a TypeError?

  • Yes — all throwables are Exceptions
  • Only in strict mode
  • Only if you rethrow it
  • No — a TypeError is an Error, not an Exception

Answer: No — a TypeError is an Error, not an Exception. TypeError is an Error, not an Exception. Use catch (Throwable $e) or the specific type to catch it.

Does the finally block always run, even after a return or throw?

  • No — only when the try succeeds
  • Yes — it always runs (except on exit/fatal before reaching it)
  • Only when an exception is thrown
  • Only when there is no catch

Answer: Yes — it always runs (except on exit/fatal before reaching it). finally always runs after try, which is why it is the right place for cleanup like closing files.

How do you order catch blocks for different exception types?

  • Most specific type first, broader ones after
  • Broadest type first
  • Order does not matter
  • Only one catch is allowed

Answer: Most specific type first, broader ones after. PHP uses the first matching catch, so list specific types first and a broad Throwable as a safety net.

How do you define a custom exception type?

  • class MyException implements Exception {}
  • trait MyException uses Exception {}
  • class MyException extends Exception {}
  • function MyException() {}

Answer: class MyException extends Exception {}. A custom exception is just a class that extends Exception; it can carry extra data too.

How do you attach the original cause when re-throwing an exception?

  • Pass it as the first argument
  • Pass it as the third constructor argument
  • Call setCause() on it
  • You cannot chain exceptions

Answer: Pass it as the third constructor argument. throw new ConfigException("...", 0, $cause) chains the cause; getPrevious() walks back to it.

Which method retrieves the chained root cause of an exception?

  • getCause()
  • getRoot()
  • getParent()
  • getPrevious()

Answer: getPrevious(). $e->getPrevious() returns the previously-attached exception that was wrapped.

In production, how should you handle errors safely?

  • Show full stack traces to users
  • Set display_errors to 0 and log details with error_log()
  • Disable error_reporting entirely
  • Echo $e->getMessage() to the page

Answer: Set display_errors to 0 and log details with error_log(). Hide raw errors from visitors (they leak paths and secrets), but keep reporting and route detail to logs.

What does set_exception_handler() register?

  • A handler that runs before every try block
  • A replacement for catch blocks
  • A last-resort handler for any uncaught exception
  • A handler for syntax errors

Answer: A last-resort handler for any uncaught exception. It runs for any exception nothing else caught, just before the script would die — your last line of defence.