Repository navigation
Pre-release 4.2.123 → 4.2.122 — task 4.5 (foundation): the Exception package folds into Foundation's v13-shaped Handler - #96
Merged
Conversation
agissept
force-pushed
the
pre-release/4.2.123
branch
from
October 2, 2026 09:20
7ae0eb9 to
8818f9c
Compare
agissept
added this pull request to stack #102
October 5, 2026 06:14
agissept
force-pushed
the
pre-release/4.2.123
branch
3 times, most recently
from
October 5, 2026 08:40
c95e635 to
563bde6
Compare
agissept
approved these changes
Oct 6, 2026
…3-shaped Handler (task 4.5)
illuminate/exception leaves the replace block; only illuminate/foundation
remains for the flip.
- Illuminate\Exception\Handler becomes Illuminate\Foundation\Exceptions\Handler,
v13's name, and implements v13's ExceptionHandler contract
(report/shouldReport/render/renderForConsole). Its constructor takes only the
container, as v13's does, and debug mode is read from app.debug when an
exception is displayed.
- When no render callback answers, it renders the app's errors.{status} or
errors.{N}xx view, as v13 does, and the plain page when there is none or it
fails. The debug displayer (Whoops) still renders in debug mode and in the
console.
- An error raised while handling an error is reported through the same
report callbacks before the fallback renders, as v13's HandleExceptions does.
- The displayers move to Foundation\Exceptions\Displayers and the provider to
Foundation\Providers. ExceptionHandlerAdapter goes: the queue worker's
ExceptionHandler binding now resolves the handler itself.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0169SsatCE8LhaTsQTPiGtVo
agissept
force-pushed
the
pre-release/4.2.123
branch
from
October 6, 2026 02:35
563bde6 to
19007aa
Compare
agissept
marked this pull request as ready for review
October 6, 2026 02:36
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Task 4.5, foundation — the Exception package folds into Foundation as v13's
HandlerStacks on #95. This is the third foundation slice.
illuminate/exceptionleaves thereplaceblock, soilluminate/foundationis the only package left for the flip. The handler takes v13's name and shape. When it renders a fallback page, it uses the app'serrors.*views, as v13 does, not a displayer the app binds.Changes
Illuminate\Exception\HandlerbecomesIlluminate\Foundation\Exceptions\Handler, v13's name, and implements v13'sExceptionHandlercontract (report,shouldReport,render,renderForConsole).app.debugwhen an exception is displayed, sosetDebug()and the displayer constructor arguments are gone.Fallback page. When no render callback answers, the handler renders the app's
errors.{status}view, thenerrors.{N}xx, as v13 does. It passes the status and headers of anHttpExceptionInterface. If neither view exists, or rendering it fails, it shows the plain page. The debug displayer (Whoops) still renders in debug mode and in the console.An error raised while handling an error is reported through the same report callbacks before the fallback renders. v13 reports such an error through the handler too: it reaches the HTTP Kernel, which reports it. Until now the app's displayer reported it on its own.
Moves:
Foundation\Exceptions\Displayersand the provider toFoundation\Providers. The provider always bindsexception.plainto the plain displayer; the console case moved into the handler.ExceptionHandlerAdapteris removed: the queue worker'sExceptionHandlerbinding now resolves the handler itself.src/Illuminate/Exception/composer.jsonis removed.Tests move to
tests/Foundation/Exceptions/.HandlerTestadds cases for:Nxx, with its headers;renderForConsole().QueueForkBridgeTestchecks that the worker's bound contract is the handler.Verification
Nxxview;Nxxbefore the status view;feature/platform/framework-4.2.123-rc1). It drops its ownExceptionServiceProviderandFiveZeroZeroDisplayerand addserrors/5xxanderrors/4xxviews that show its branded error page. It ran with vendor installed exactly from its lock:php -S+server.php→index.php, and 7 artisan commands) and the 13 in-process request scenarios are identical to 4.2.122.php -S: a route's exception throws from its ownrender(). Every status and page body is byte-identical to 4.2.122. The render failure is now logged atERRORthrough the app's report callbacks; before, the app's displayer logged it atALERT.Tag
4.2.123(7ae0eb9f) is not pushed, and neither are4.2.119–4.2.122. Tag pushes are refused for this session.🤖 Generated with Claude Code
https://claude.ai/code/session_0169SsatCE8LhaTsQTPiGtVo