Mastering Laravel's Latest: Advanced Route Sorting, Validation, and Exception Fakes

Overview

Modern development requires more than just functional code; it demands tools that refine the developer experience and harden application logic.

Laravel
continues this trend with three significant updates: multi-column route sorting, intuitive conditional validation rules, and a robust way to test reported exceptions. These features allow you to maintain cleaner CLI outputs, handle complex form logic with less boilerplate, and ensure your error tracking remains functional even when exceptions are caught and handled.

Prerequisites

To follow this guide, you should have a solid grasp of

PHP
and the Laravel framework. Specifically, familiarity with the php artisan CLI, validation logic in Controllers, and the
PHPUnit
 or
Pest
 testing environments will be essential.

Key Libraries & Tools

  • Laravel Framework: The core
    PHP
     framework providing the new functionality.
  • Artisan CLI: Laravel's built-in command-line interface used for route management.
  • Exceptions Facade: A new testing utility to mock and assert exception behavior.

Code Walkthrough

Multi-Column Route Sorting

Previously, route:list allowed sorting by a single column. Now, you can pass multiple arguments to organize your routing table more effectively.

php artisan route:list --sort=method --sort=uri

This command ensures that routes are grouped by their HTTP verb first, and then alphabetized by their URI, eliminating the "random" feel of secondary columns.

The required_if_declined Rule

When building forms where one selection negates the need for other data—like a checkbox to "Use Personal Address" for shipping—validation can get messy. The new required_if_declined rule handles the "false" or "off" state of a field directly.

$request->validate([
    'shipping_street' => 'required_if_declined:use_personal_address',
]);

If use_personal_address is false, the shipping street becomes mandatory. This is the logical sibling to required_if_accepted.

Faking and Asserting Exceptions

Testing that an exception was reported (sent to

Sentry
or
Flare
) without crashing the test is now possible using the Exceptions facade.

use Illuminate\Support\Facades\Exceptions;

public function test_exception_is_reported()
{
    Exceptions::fake();

    $this->post('/publish-podcast');

    Exceptions::assertReported(ServiceDownException::class);
}

This allows you to verify that your report() calls are functioning correctly within try-catch blocks while still asserting a successful HTTP status code for the user.

Syntax Notes

Laravel utilizes "facade fakes" for testing. By calling Exceptions::fake(), you swap the real exception handler with a mock. This prevents exceptions from bubbling up and failing your test suite, allowing you to use assertReported or assertNotReported as post-action assertions.

Practical Examples

In a real-world e-commerce checkout, you might use required_if_declined for billing details when a "Same as Shipping" toggle is turned off. Meanwhile, exception faking is critical for payment gateway integrations where you want to ensure a connectivity error is logged to your monitoring service, even if the customer only sees a friendly "Try again later" message.

Tips & Gotchas

When using Exceptions::fake(), remember that it stops all reporting. If you need to verify specific message content within the exception, pass a closure to assertReported and return a boolean based on the exception's properties. Always ensure your validation field names match the HTML name attributes exactly, or required_if_declined will fail to find the trigger field.

3 min read