我想在生产中完全禁用错误报告,因为我们有一些非常旧的代码我们仍然需要修复但现在确实有效(是的,我也不喜欢它)。我们无法在几天内解决所有问题,因此我们需要像往常一样抑制警告和异常。
真正的问题是它已经在一个简单的惰性错误上抛出异常(因为未定义 var)
if(!$var) {
// do whatever
}
尝试过
APP_DEBUG=假
APP_LOG_LEVEL=紧急
display_errors(false); set_error_handler(null); set_exception_handler(null);
但它仍然显示 ErrorException
未定义变量:script_name_vars_def
编辑:代码是这样工作的
网站.php
Route::any('/someroute', 'somecontroller@controllerFunc');
一些控制器.php
public controllerFunc() {
ob_start();
require '/old_index.php';
$html = ob_get_clean();
return response($html);
}
这样我们就可以使用 Laravel 路由,而不必立即重写旧代码。
我知道我可以很容易地修复这个警告,但是还有很多很多这样的错误,我们现在需要使用 Laravel 路由。稍后解决问题。
想法
- 在
$dontReport
中使用一些通配符。 - 在正确的位置使用
@
抑制 - 可以是 http://php.net/manual/en/scream.examples-simple.php
编辑以解释在哪些步骤之后中间件不起作用
1)创建中间件
php artisan make:middleware SuppressExceptions
2)写下来
抑制异常.php
public function handle($request, Closure $next)
{
error_reporting(0);
return $next($request);
}
- 注册
laravel/app/Http/Kernel.php
protected $middlewareGroups = [
'web' => [
\App\Http\Middleware\SuppressExceptions::class,
],
原文由 online Thomas 发布,翻译遵循 CC BY-SA 4.0 许可协议
是的,您可以更改错误报告。事实上,框架提供了一个拦截异常的地方:
App\Exceptions\Handler
。默认情况下render
方法会将抛出的异常转换为 HTML 响应。APP_ENV
和APP_DEBUG
值只会改变这个错误响应的呈现方式(关于异常堆栈跟踪的详细信息,基本上)。尝试将
render
方法更改为这基本上会关闭报告,然后尝试重新处理请求。在
if
子句中,您可以检查您想要的任何条件(异常类、严重性等)。捕获ErrorException
可能会满足您的需求,但请注意,您可能无法通过这种方式从致命错误中恢复。无论如何,您应该将其视为“概念证明”……对于非幂等请求,这种“重新处理”方法并不好。相反,只需 创建一个中间件
和以前一样,致命错误无法通过这种方式恢复。但是您可以显示一条自定义错误消息,将此中间件与之前的异常处理程序方法相结合: