Problem
src/Exceptions/ defines seven exception classes, but only three are actually thrown anywhere in src/: InvalidBaseUriException, DisallowedProxyTargetException, and PassageRequestAbortedException. The other four are never referenced outside their own file definitions:
InvalidPassageHandlerProvided
InvalidPassageOptionsProvided
MissingPassageService
PassageUpstreamException
Confirmed via a repo-wide search — each name appears exactly once (its own class declaration) and nowhere else in src/, tests/, config/, or README.md. These look like leftovers from an earlier design (likely pre-v3, before the array/macro-based service config was replaced by explicit handler classes — see UPGRADE.md's v2→v3 breaking changes) that were never cleaned up when the code that would have thrown them was replaced.
Location
src/Exceptions/InvalidPassageHandlerProvided.php
src/Exceptions/InvalidPassageOptionsProvided.php
src/Exceptions/MissingPassageService.php
src/Exceptions/PassageUpstreamException.php
Why it matters
Dead exception classes are public API surface (they're autoloaded under the package's PSR-4 namespace) that nobody can catch meaningfully since nothing ever throws them. They add noise for anyone reading the Exceptions/ directory trying to understand Passage's error-handling model, and risk being mistakenly relied upon (e.g. a consumer writes a catch (MissingPassageService $e) block that can never trigger).
Suggested fix
Either remove the four unused classes (this is a package still in active v3 development, so it's a safe cleanup), or, if any of them map to a real gap in current error handling (e.g. PassageUpstreamException for upstream errors, InvalidPassageOptionsProvided for malformed getOptions() output), wire them up to be thrown where appropriate and document them. A quick grep (grep -rn "InvalidPassageHandlerProvided\|InvalidPassageOptionsProvided\|MissingPassageService\|PassageUpstreamException" src tests) confirms the current state before deciding which route to take.
Problem
src/Exceptions/defines seven exception classes, but only three are actually thrown anywhere insrc/:InvalidBaseUriException,DisallowedProxyTargetException, andPassageRequestAbortedException. The other four are never referenced outside their own file definitions:InvalidPassageHandlerProvidedInvalidPassageOptionsProvidedMissingPassageServicePassageUpstreamExceptionConfirmed via a repo-wide search — each name appears exactly once (its own class declaration) and nowhere else in
src/,tests/,config/, orREADME.md. These look like leftovers from an earlier design (likely pre-v3, before the array/macro-based service config was replaced by explicit handler classes — seeUPGRADE.md's v2→v3 breaking changes) that were never cleaned up when the code that would have thrown them was replaced.Location
src/Exceptions/InvalidPassageHandlerProvided.phpsrc/Exceptions/InvalidPassageOptionsProvided.phpsrc/Exceptions/MissingPassageService.phpsrc/Exceptions/PassageUpstreamException.phpWhy it matters
Dead exception classes are public API surface (they're autoloaded under the package's PSR-4 namespace) that nobody can
catchmeaningfully since nothing ever throws them. They add noise for anyone reading theExceptions/directory trying to understand Passage's error-handling model, and risk being mistakenly relied upon (e.g. a consumer writes acatch (MissingPassageService $e)block that can never trigger).Suggested fix
Either remove the four unused classes (this is a package still in active v3 development, so it's a safe cleanup), or, if any of them map to a real gap in current error handling (e.g.
PassageUpstreamExceptionfor upstream errors,InvalidPassageOptionsProvidedfor malformedgetOptions()output), wire them up to be thrown where appropriate and document them. A quick grep (grep -rn "InvalidPassageHandlerProvided\|InvalidPassageOptionsProvided\|MissingPassageService\|PassageUpstreamException" src tests) confirms the current state before deciding which route to take.