基于控制器的自定义错误页条件选择及ErrorHandler重写问询

Got it, let's break this down so you can serve custom error pages (including a JavaScript-formatted one for Controller B) without modifying core system files. Here's a step-by-step approach tailored to your setup:

1. Create a Custom ErrorHandler Class in Your Plugin #

First, make a new ErrorHandler.php file in your plugin's classes directory. This class will extend the system's default ErrorHandler and add your controller-specific logic.

<?php namespace YourPlugin\Classes; // Replace with your actual plugin namespace

use System\Classes\ErrorHandler as SystemErrorHandler;
use Illuminate\Http\Request;

class ErrorHandler extends SystemErrorHandler
{
    // Override the method that selects the error template
    protected function getTemplate($exception)
    {
        // Grab the current controller from the request route
        $controller = Request::route()?->getController();
        
        // Check if the error came from Controller B
        if ($controller instanceof \YourPlugin\Controllers\ControllerB) { // Replace with your Controller B's full class path
            return 'your-plugin::errors.js_error'; // Path to your JS error template
        }
        // Check for Controller A
        elseif ($controller instanceof \YourPlugin\Controllers\ControllerA) { // Replace with your Controller A's full class path
            return 'your-plugin::errors.controller_a'; // Path to your Controller A's HTML error template
        }
        
        // Fall back to the system's default template for other cases
        return parent::getTemplate($exception);
    }

    // Adjust the response headers for Controller B's JS output
    public function render($exception)
    {
        $response = parent::render($exception);
        
        $controller = Request::route()?->getController();
        if ($controller instanceof \YourPlugin\Controllers\ControllerB) {
            // Set the correct content type for JavaScript
            $response->header('Content-Type', 'application/javascript');
        }
        
        return $response;
    }
}

2. Register the Override in Your Plugin's Boot Method #

Open your plugin's Plugin.php file and add this to the boot() method to tell the system to use your custom ErrorHandler instead of the core one:

public function boot()
{
    // Bind our custom ErrorHandler to replace the system default
    $this->app->bind('System\Classes\ErrorHandler', function($app) {
        return new \YourPlugin\Classes\ErrorHandler($app['config'], $app['log']);
    });
}

3. Create Your Custom Error Templates #

Make a views/errors directory in your plugin, then add the two template files:

Controller A's HTML Error Template (controller_a.htm) #

<!DOCTYPE html>
<html>
<head>
    <title>Controller A Error</title>
</head>
<body>
    <h1>Oops! Something went wrong in Controller A</h1>
    <p>{{ message }}</p>
</body>
</html>

Controller B's JavaScript Error Template (js_error.htm) #

console.error('Error in Controller B: {{ message }}');
// You can add more JS logic here, like triggering a frontend error handler
window.handleControllerBError && window.handleControllerBError('{{ message }}');

Key Notes to Keep in Mind #

• Namespace & Paths: Double-check all namespace references and file paths match your plugin's structure. For example, if your plugin is named Acme.MyPlugin, replace your-plugin with acme.myplugin in template paths.
• Controller Detection: The Request::route()?->getController() call uses a null-safe operator to avoid errors if there's no controller (like 404s). Adjust this if you need to handle those cases too.
• Testing: Enable your plugin, trigger errors in Controller A and B, and verify the correct templates are served (check the response content type for Controller B to ensure it's application/javascript).

内容的提问来源于stack exchange，提问作者Alec