Parse Errors & Syntax Debugging
debt(d1/e1/b1/t3)
Closest to 'caught instantly' (d1), php -l (lint) and the PHP CLI itself catch parse errors immediately at compile time before any code runs.
Closest to 'one-line patch' (e1), parse errors are typically a missing semicolon, brace, or quote — fixed on the exact line php -l reports.
Closest to 'minimal commitment' (b1), adding php -l to CI is a trivial convention; it doesn't shape architecture or impose ongoing tax.
Closest to 'minor surprise' (t3), the misconception that parse errors only happen in large files is mild; the real gotcha is production blank pages when display_errors is off, which most devs learn quickly.
TL;DR
Explanation
PHP parses the entire file before executing any of it. A syntax error in line 200 prevents line 1 from running. ParseError extends Error (PHP 7+) and can be caught in other files via eval() or require inside try/catch, but not in the file itself. Debugging: run php -l file.php from CLI to syntax-check without executing. Common causes: missing ; after statement, unclosed string, unclosed { } ( ), PHP 8 named argument typos, mismatched heredoc identifiers. In production, parse errors show as blank pages if display_errors is Off — check error logs.
Common Misconception
Why It Matters
Common Mistakes
- Not running php -l in CI pipelines — parse errors reach production.
- Debugging via browser when php -l gives the exact line.
- Not enabling error reporting in development.
Code Examples
<?php
function greet($name)
echo "Hello $name"; // Missing { } around function body
}// Run in CI:
// php -l src/Service/UserService.php
// PHP Parse error: syntax error, unexpected token "echo" in ... on line 3
// In PHP 7+ you can catch ParseError from eval():
try {
eval('<?php echo "test"'); // Missing ;
} catch (ParseError $e) {
echo "Syntax error: " . $e->getMessage();
}