Learn how PHP errors, exceptions, and logs work together. Set up safer error messages, handle common failures, and make problems easier to fix.
Every PHP application runs into problems eventually. A file may be missing, a database may be unavailable, or a user may send data your code did not expect. Good error handling helps you find the cause without showing private details to visitors.
This guide explains the main kinds of PHP errors and shows how to handle them. You will learn how to set up error reporting, use exceptions, write useful logs, and avoid common mistakes.
An error message can help a developer understand what went wrong. But the same message may reveal file paths, database details, or other information that visitors should not see.
Good error handling has two jobs. It gives developers enough detail to fix the problem, and it gives users a clear, safe response. These jobs often need different messages: a detailed note goes to a private log, while the page shows a short message such as “We could not load this page. Please try again.”
Handling errors also helps your application fail in a controlled way. Instead of leaving a half-finished page or showing a raw warning, your code can stop the action, record what happened, and offer a sensible next step.
PHP uses several terms for problems. Understanding the difference helps you choose the right response.
In current PHP, both exceptions and many serious errors can be caught with catch (Throwable $e). That does not mean you should catch every problem everywhere. Catch an issue where your code has a useful way to respond. Otherwise, let your application’s main error handler deal with it.
During development, you generally want PHP to report all issues. This helps you catch small problems before they reach users. A common development setting is to report all errors and show them on screen.
For production, keep reporting enabled so issues can be recorded, but turn off displaying detailed errors to visitors. The exact settings are best placed in the PHP configuration for the environment. A hosting control panel or deployment setup may manage them for you.
Production rule: Report and log errors, but do not display detailed PHP errors to the public.
If you need to set these values in a PHP entry file, a basic example is: error_reporting(E_ALL);, ini_set(‘display_errors’, ‘0’);, and ini_set(‘log_errors’, ‘1’);. Configuration in a server or PHP settings file is often more reliable because it can apply before your application starts.
Do not turn off all error reporting just to make a warning disappear. That hides useful clues and can allow bugs to stay unnoticed. Fix the cause, or handle the problem in a clear and deliberate way.
Exceptions are useful when an operation cannot continue as expected. Your code can raise an exception, and a nearby part of the application can catch it and decide what to do.
For example, imagine a function that needs a positive account number. It can reject invalid input with an InvalidArgumentException. In simple form, the check looks like this: if ($accountId < 1) { throw new InvalidArgumentException(‘Account ID must be positive’); }
A caller that knows how to respond can catch that specific exception: try { loadAccount($accountId); } catch (InvalidArgumentException $e) { showInvalidAccountMessage(); } The names in this example stand for your own functions. The important idea is to catch the problem where you can give a useful response.
Use specific exception types when possible. Catching InvalidArgumentException is clearer than catching every possible Throwable if you only expect bad input. Broad catches can still be useful at the top level of an application, where they prevent an uncaught problem from producing a raw error page.
Older PHP code may produce warnings instead of exceptions. You can keep track of a warning with PHP’s error log, or use a custom error handler to change selected warnings into ErrorException objects.
For example, a custom handler can check whether the warning is currently reported and then throw an ErrorException with the warning details. This lets a surrounding try-and-catch block respond to that problem. Such a handler affects the code that runs after it is registered, so use it only if your application has a clear plan for handling the resulting exceptions.
Do not convert every warning automatically without testing. Some libraries may rely on a warning being recorded while execution continues. A broad conversion can change their behavior and create new failures. Handle known cases first, and confirm that your application and its libraries work with the chosen policy.
A useful log entry answers basic questions: what failed, when it happened, and which part of the application was involved. If possible, include a request or event ID so your team can connect the log to a user report without putting private user details in the message.
PHP can write errors to a server log when logging is enabled. Your framework may also provide a logging tool. Use one place that your team can access and monitor, and make sure log files are not publicly available from the website.
Avoid recording passwords, payment details, session tokens, or full private messages. Logs can be copied, searched, and kept for a long time. Store only what is needed to find and fix the problem, and follow your organization’s rules for keeping that data.
When an exception is caught, its message and details may help with debugging. Keep those details in the private log. Show visitors a short, plain message that does not expose the server or the code.
Expected user mistake
Show a helpful message beside the form field. For example, explain that an email address is missing. Do not treat normal validation failures as mysterious server errors.
Temporary service failure
Stop the current action safely, record the failure, and let the user know they can try again. Do not claim that a payment or order succeeded unless you know it did.
Unexpected programming problem
Send details to a private log, show a general error page, and alert the team when the issue needs prompt attention.
Validation should happen before risky work when possible. Check that required values exist and have the expected type or format. Still handle failures from databases, file systems, and outside services, because valid input cannot prevent every problem.
No. Use try and catch where you can take a useful action, such as asking a user to correct input or showing a safe fallback. Catching everything around every line can make code harder to read and may hide problems.
In most cases, no. Detailed errors can show paths or internal details. Keep error reporting and logging on, but send the details to a private log instead of the public page.
Not by default. Warnings are not the same as exceptions. A custom error handler can turn selected warnings into ErrorException objects, but test this carefully because it changes how those warnings behave.
PHP error handling is not about hiding every problem. It is about deciding what should happen when something goes wrong. Report issues while you build, keep detailed information private in production, and give users a clear response.
Start with safe configuration and useful logs. Then add focused validation and exception handling around important actions. These habits make problems easier to find and help your application respond more safely when they occur.
No account yet?
Create an Account
