مدیریت خطا در Laravel؛ آموزش Exception Handling از مقدماتی تا پیشرفته

مقدمه

هیچ برنامه‌ای بدون احتمال بروز خطا نیست. ممکن است کاربر آدرس اشتباهی وارد کند، یک رکورد در پایگاه داده وجود نداشته باشد، ارتباط با یک API قطع شود یا هنگام ذخیره اطلاعات، خطایی در برنامه رخ دهد.

نحوه برخورد برنامه با این اتفاقات، تفاوت میان یک نرم‌افزار قابل‌اعتماد و برنامه‌ای است که با کوچک‌ترین مشکل از کار می‌افتد.

در لاراول، بخش مهمی از این مسئولیت بر عهده سیستم Exception Handling یا مدیریت استثناها قرار دارد. این سیستم به شما کمک می‌کند خطاهای رخ‌داده را گزارش کنید، پاسخ مناسبی به کاربر بدهید و در صورت نیاز، رفتار برنامه را هنگام وقوع خطا سفارشی‌سازی کنید.

برای مثال، فرض کنید کاربری قصد مشاهده یک محصول را دارد؛ اما محصول از پایگاه داده حذف شده است. به‌جای نمایش یک خطای نامفهوم، می‌توانید پاسخ استاندارد 404 برگردانید. همچنین اگر یک سرویس خارجی در دسترس نباشد، می‌توانید خطا را ثبت کنید و پیام مناسبی به کاربر نمایش دهید.

در این مقاله یاد می‌گیریم:

• Exception چیست و چه تفاوتی با خطای معمولی دارد؟
• چگونه با try و catch خطاها را مدیریت کنیم؟
• سیستم مدیریت استثنا در Laravel چگونه کار می‌کند؟
• فایل bootstrap/app.php چه نقشی دارد؟
• چگونه خطاهای 404 و 500 را مدیریت کنیم؟
• چگونه صفحات خطای سفارشی بسازیم؟
• چگونه خطاهای API را به‌صورت JSON برگردانیم؟
• چه نکات امنیتی را هنگام مدیریت خطا باید رعایت کنیم؟

مثال‌ها بر اساس ساختار Laravel 12 نوشته شده‌اند و اصول اصلی آن‌ها در نسخه‌های جدید لاراول نیز کاربرد دارند.

۱. Exception چیست؟

Exception یا استثنا، روشی برای اعلام یک وضعیت غیرعادی در زمان اجرای برنامه است؛ وضعیتی که ممکن است اجرای عادی یک عملیات را مختل کند.

برای مثال، فرض کنید برنامه شما می‌خواهد اطلاعات یک سفارش را از پایگاه داده دریافت کند، اما سفارش موردنظر وجود ندارد.

یا فرض کنید هنگام ارسال درخواست به یک سرویس پرداخت، ارتباط شبکه قطع می‌شود.

در چنین شرایطی ممکن است یک Exception رخ دهد و لازم باشد برنامه تصمیم بگیرد چگونه با آن برخورد کند.

یک مثال ساده در PHP:

<?php



try {

    throw new Exception('Something went wrong.');

} catch (Exception $e) {

    echo $e->getMessage();

}

در این کد:

1. بلوک try شامل عملیاتی است که ممکن است استثنا ایجاد کنند.
2. دستور throw یک استثنا ایجاد می‌کند.
3. بلوک catch استثنا را دریافت می‌کند.
4. متد getMessage() پیام استثنا را برمی‌گرداند.

خروجی برنامه به این صورت خواهد بود:

Something went wrong.

در پروژه‌های واقعی، معمولاً به‌جای نمایش مستقیم پیام فنی استثنا به کاربر، آن را ثبت می‌کنیم و یک پاسخ مناسب برمی‌گردانیم.

۲. تفاوت Error و Exception چیست؟

در PHP، اصطلاحات Error و Exception از نظر فنی دقیقاً یکسان نیستند.

• Exception برای نمایش و انتقال شرایط استثنایی استفاده می‌شود.
• Error برای برخی خطاهای سطح زبان PHP، مانند بعضی خطاهای نوع داده یا فراخوانی‌های نامعتبر، به کار می‌رود.
• هر دو از نوع Throwable هستند و می‌توان در صورت نیاز آن‌ها را با سازوکار مناسب دریافت کرد.

برای مثال:

try {

    throw new RuntimeException('Operation failed.');

} catch (Throwable $e) {

    echo $e->getMessage();

}

در این مثال از Throwable استفاده شده است تا هم Exceptionها و هم Errorهای قابل‌گرفتن را پوشش دهد.

البته نباید تصور کنیم که همه خطاهای PHP را می‌توان به این روش مدیریت کرد؛ برخی خطاهای سطح فرایند یا مشکلات محیط اجرا ممکن است به سازوکارهای دیگری نیاز داشته باشند.

در بیشتر عملیات‌های روزمره لاراول، بهتر است به‌جای گرفتن تمام خطاها به‌صورت عمومی، استثناهای مورد انتظار را به شکل مشخص مدیریت کنید.

۳. مدیریت خطا با try و catch در Laravel

ساختار try/catch یکی از ابزارهای اصلی مدیریت استثنا در PHP است و در کنترلرها، سرویس‌ها و سایر بخش‌های لاراول نیز می‌توان از آن استفاده کرد.

برای مثال، فرض کنید می‌خواهید عملیاتی را انجام دهید که احتمال شکست دارد:

<?php



namespace App\Http\Controllers;



use Illuminate\Http\Request;

use Illuminate\Support\Facades\Log;

use Throwable;



class PaymentController extends Controller

{

    public function process(Request $request)

    {

        try {

            // اجرای عملیات پرداخت

            $result = $this->processPayment();



            return response()->json([

                'success' => true,

                'message' => 'Payment processed successfully.',

            ]);



        } catch (Throwable $e) {

            Log::error('Payment processing failed.', [

                'message' => $e->getMessage(),

            ]);



            return response()->json([

                'success' => false,

                'message' => 'پردازش پرداخت با مشکل مواجه شد.',

            ], 500);

        }

    }



    private function processPayment(): bool

    {

        // منطق واقعی ارتباط با درگاه پرداخت باید اینجا پیاده‌سازی شود.

        return true;

    }

}

این مثال برای آموزش ساختار مدیریت خطا نوشته شده است و متد processPayment() عمداً یک عملیات نمایشی دارد؛ در پروژه واقعی باید منطق ارتباط با درگاه، اعتبارسنجی پاسخ و تأیید پرداخت پیاده‌سازی شود.

در این کد، اگر عملیاتی در بلوک try استثنا ایجاد کند، کنترل به catch منتقل می‌شود. سپس خطا ثبت می‌شود و یک پاسخ JSON برمی‌گردد.

آیا همیشه باید از try/catch استفاده کنیم؟

خیر. یکی از اشتباهات رایج در برنامه‌نویسی این است که تمام کدهای برنامه را داخل try/catch قرار دهیم.

لاراول به‌صورت پیش‌فرض سیستم مدیریت استثنا دارد و بسیاری از خطاهای مدیریت‌نشده را خودش گزارش می‌کند و به پاسخ HTTP مناسب تبدیل می‌کند.

از try/catch زمانی استفاده کنید که واقعاً می‌خواهید برای یک خطای مشخص رفتار متفاوتی داشته باشید؛ برای مثال:

• شکست یک درخواست به سرویس خارجی را مدیریت کنید.
• پس از شکست یک عملیات، وضعیت مشخصی به کاربر برگردانید.
• یک عملیات جایگزین اجرا کنید.
• خطا را ثبت کنید و در شرایط مشخص، اجرای برنامه را ادامه دهید.

اگر استثنا را دریافت کنید و بدون بررسی آن را نادیده بگیرید، ممکن است مشکل اصلی پنهان بماند.

۴. سیستم مدیریت خطا در Laravel چگونه کار می‌کند؟

در یک پروژه استاندارد لاراول، لازم نیست تمام خطاها را دستی مدیریت کنید. فریم‌ورک یک سازوکار مرکزی برای گزارش استثناها و تبدیل آن‌ها به پاسخ HTTP دارد.

برای مثال، اگر در یک کنترلر استثنایی مدیریت‌نشده رخ دهد، لاراول می‌تواند آن را گزارش کند و پاسخ مناسبی به درخواست برگرداند.

دو مفهوم اصلی در این سیستم عبارت‌اند از:

Reporting: ثبت یا ارسال گزارش خطا برای بررسی بعدی؛ برای مثال، ذخیره در فایل لاگ.

Rendering: تبدیل خطا به پاسخ مناسب برای درخواست HTTP؛ برای مثال، نمایش صفحه 404 یا برگرداندن پاسخ JSON.

تنظیمات اصلی این رفتار در نسخه‌های جدید لاراول از طریق فایل زیر قابل مدیریت است:

bootstrap/app.php

در پروژه‌های جدید Laravel 12، معمولاً بخشی با ساختار مشابه زیر در این فایل وجود دارد:

use Illuminate\Foundation\Configuration\Exceptions;



->withExceptions(function (Exceptions $exceptions): void {

    //

})

ساختار کامل فایل ممکن است شامل تنظیمات Middleware و Routeها نیز باشد. هنگام اعمال تغییرات، فقط بخش موردنیاز را به ساختار موجود اضافه کنید و کل فایل را با یک قطعه کد ناقص جایگزین نکنید.

۵. تفاوت report و render در Laravel

برای درک بهتر سیستم مدیریت خطای لاراول، باید تفاوت میان گزارش خطا و نمایش پاسخ را بدانیم.

گزارش خطا با report

تابع report() برای گزارش یک استثنا استفاده می‌شود.

برای مثال:

use RuntimeException;



try {

    // اجرای عملیات

    throw new RuntimeException('External service failed.');

} catch (RuntimeException $e) {

    report($e);



    // ادامه منطق برنامه در صورت امکان

}

در این مثال، استثنا گزارش می‌شود، اما به‌خودی‌خود به این معنی نیست که پاسخ HTTP خاصی به کاربر برگردانده خواهد شد.

اگر خطا را دریافت کرده‌اید و می‌خواهید آن را ثبت کنید، اما همچنان عملیات را با یک نتیجه جایگزین ادامه دهید، این روش می‌تواند مفید باشد.

مدیریت پاسخ با render

اگر می‌خواهید برای نوع خاصی از استثنا پاسخ سفارشی برگردانید، می‌توانید رفتار Rendering را تنظیم کنید.

برای نمونه، در bootstrap/app.php می‌توانید یک استثنای اختصاصی را به پاسخ مشخصی تبدیل کنید:

use App\Exceptions\InvalidOrderException;

use Illuminate\Http\Request;



->withExceptions(function (Exceptions $exceptions): void {

    $exceptions->render(

        function (InvalidOrderException $e, Request $request) {

            return response()->view(

                'errors.invalid-order',

                status: 422

            );

        }

    );

})

این قطعه کد باید در زنجیره پیکربندی موجود Application::configure(...) قرار بگیرد؛ آن را به‌صورت مستقل و خارج از ساختار فایل قرار ندهید.

در این مثال فرض شده است که کلاس InvalidOrderException و فایل نمای resources/views/errors/invalid-order.blade.php از قبل ایجاد شده‌اند.

هنگامی که این استثنا رخ دهد، لاراول می‌تواند به‌جای رفتار پیش‌فرض، نمای سفارشی را با وضعیت HTTP برابر 422 برگرداند.

مستندات رسمی لاراول جزئیات کامل متدهای report و render را توضیح می‌دهد.

۶. چگونه خطای 404 را در Laravel مدیریت کنیم؟

کد وضعیت HTTP برابر 404 به این معنی است که منبع مورد درخواست پیدا نشده است.

برای مثال، اگر کاربری آدرس زیر را باز کند:

https://example.com/products/99999

اما محصولی با شناسه 99999 وجود نداشته باشد، باید پاسخ مناسبی دریافت کند.

یکی از روش‌های رایج در لاراول، استفاده از findOrFail() است:

use App\Models\Product;



public function show(int $id)

{

    $product = Product::findOrFail($id);



    return view('products.show', [

        'product' => $product,

    ]);

}

اگر محصول وجود نداشته باشد، این متد استثنای مربوط به پیدا نشدن مدل را ایجاد می‌کند و لاراول آن را به پاسخ 404 تبدیل می‌کند.

این روش از بررسی دستی مقدار null و نوشتن شرط‌های تکراری در بسیاری از موارد جلوگیری می‌کند.

روش دیگر، استفاده از abort() است:

abort(404);

می‌توانید در صورت نیاز پیام مشخصی نیز ارائه کنید:

abort(404, 'Product not found.');

با این حال، برای صفحات عمومی سایت بهتر است جزئیات فنی غیرضروری را نمایش ندهید.

۷. چگونه صفحه 404 سفارشی بسازیم؟

لاراول امکان ایجاد صفحات خطای سفارشی را فراهم می‌کند. برای ساخت صفحه 404، فایل زیر را ایجاد کنید:

resources/views/errors/404.blade.php

برای نمونه، می‌توانید محتوای زیر را در آن قرار دهید:

<!DOCTYPE html>

<html lang="fa" dir="rtl">

<head>

    <meta charset="UTF-8">

    <meta name="viewport" content="width=device-width, initial-scale=1.0">

    <title>صفحه پیدا نشد</title>

</head>

<body>

    <main>

        <h1>صفحه موردنظر پیدا نشد!</h1>



        <p>

            ممکن است آدرس واردشده اشتباه باشد

            یا صفحه موردنظر حذف شده باشد.

        </p>



        <a href="{{ url('/') }}">بازگشت به صفحه اصلی</a>

    </main>

</body>

</html>

اکنون وقتی لاراول پاسخ 404 را نمایش دهد، در شرایطی که این نمای سفارشی انتخاب شود، محتوای طراحی‌شده شما نمایش داده خواهد شد.

می‌توانید این صفحه را با Tailwind CSS یا سیستم طراحی سایت خود زیباتر کنید.

چرا صفحه 404 سفارشی مفید است؟

یک صفحه 404 مناسب باید:

• به کاربر توضیح دهد که صفحه پیدا نشده است.
• لینک بازگشت به صفحه اصلی داشته باشد.
• در صورت نیاز، جست‌وجو یا لینک صفحات مهم را ارائه دهد.
• وضعیت HTTP صحیح 404 را حفظ کند.

صرف نمایش یک پیام «صفحه پیدا نشد» بدون برگرداندن وضعیت صحیح HTTP می‌تواند برای ابزارهای جست‌وجو و مدیریت سایت مشکل ایجاد کند.

۸. چگونه صفحه خطای 500 بسازیم؟

کد HTTP برابر 500 معمولاً نشان‌دهنده خطای داخلی سرور است.

برای سفارشی‌سازی صفحه این خطا، فایل زیر را ایجاد کنید:

resources/views/errors/500.blade.php

نمونه محتوا:

<!DOCTYPE html>

<html lang="fa" dir="rtl">

<head>

    <meta charset="UTF-8">

    <meta name="viewport" content="width=device-width, initial-scale=1.0">

    <title>خطای سرور</title>

</head>

<body>

    <main>

        <h1>مشکلی در سرور رخ داده است.</h1>



        <p>

            لطفاً چند لحظه دیگر دوباره تلاش کنید.

        </p>



        <a href="{{ url('/') }}">بازگشت به صفحه اصلی</a>

    </main>

</body>

</html>

این صفحه به کاربر اطلاع می‌دهد که مشکلی رخ داده است، بدون اینکه جزئیات داخلی برنامه را افشا کند.

نکته مهم این است که صفحه سفارشی 500، مشکل اصلی را برطرف نمی‌کند. برای پیدا کردن علت، باید فایل‌های لاگ، تنظیمات برنامه و وضعیت سرویس‌های موردنیاز را بررسی کنید.

همچنین در لاراول می‌توانید از صفحات عمومی خطا مانند 4xx.blade.php و 5xx.blade.php برای گروه‌هایی از کدهای HTTP استفاده کنید؛ با این حال، برای 404، 500 و 503 صفحات اختصاصی همچنان اهمیت دارند.

۹. مدیریت خطا در APIهای Laravel

در پروژه‌هایی که API ارائه می‌کنند، بهتر است خطاها به‌صورت JSON برگردانده شوند؛ نه اینکه کاربر پاسخ HTML دریافت کند.

برای مثال، یک پاسخ خطای ساده می‌تواند به این صورت باشد:

return response()->json([

    'success' => false,

    'message' => 'محصول موردنظر پیدا نشد.',

], 404);

خروجی:

{

    "success": false,

    "message": "محصول موردنظر پیدا نشد."

}

البته ساختار پاسخ باید با قرارداد API شما هماهنگ باشد. اگر API شما از قالب مشخصی برای data، meta یا errors استفاده می‌کند، همه پاسخ‌ها باید همان قرارداد را رعایت کنند.

چگونه پاسخ استثناها را در API سفارشی کنیم؟

در Laravel 12 می‌توانید در bootstrap/app.php رفتار تشخیص پاسخ JSON را سفارشی کنید.

برای مثال:

use Illuminate\Foundation\Configuration\Exceptions;

use Illuminate\Http\Request;

use Throwable;



->withExceptions(function (Exceptions $exceptions): void {

    $exceptions->shouldRenderJsonWhen(

        function (Request $request, Throwable $e): bool {

            return $request->is('api/*')

                || $request->expectsJson();

        }

    );

})

این کد برای درخواست‌های مسیر api/* یا درخواست‌هایی که انتظار JSON دارند، پاسخ JSON را در نظر می‌گیرد.

این تنظیم فقط رفتار تشخیص نوع پاسخ را کنترل می‌کند؛ لزوماً به این معنی نیست که تمام خطاها با قالب اختصاصی success, message و data برگردانده می‌شوند. برای داشتن قالب ثابت، باید Rendering خطاهای موردنظر را نیز طراحی کنید.

۱۰. چگونه یک Exception اختصاصی در Laravel بسازیم؟

در پروژه‌های بزرگ، ممکن است بخواهید برای خطاهای مربوط به منطق کسب‌وکار، کلاس‌های اختصاصی ایجاد کنید.

برای مثال، در یک فروشگاه اینترنتی، تلاش برای پردازش سفارش نامعتبر می‌تواند یک استثنای مشخص داشته باشد.

با دستور زیر می‌توانید کلاس استثنا ایجاد کنید:

php artisan make:exception InvalidOrderException

لاراول فایل کلاس را معمولاً در مسیر زیر ایجاد می‌کند:

app/Exceptions/InvalidOrderException.php

نمونه ساده کلاس:

<?php



namespace App\Exceptions;



use RuntimeException;



class InvalidOrderException extends RuntimeException

{

}

اکنون می‌توانید این استثنا را در منطق برنامه پرتاب کنید:

use App\Exceptions\InvalidOrderException;



if (! $order->is_valid) {

    throw new InvalidOrderException(

        'The order is invalid.'

    );

}

در این مثال فرض شده است که مدل سفارش، متغیر $order و ویژگی is_valid در پروژه شما وجود دارند.

مزیت این روش این است که خطاهای مربوط به دامنه کسب‌وکار از خطاهای عمومی PHP یا پایگاه داده متمایز می‌شوند.

چه زمانی Exception اختصاصی بسازیم؟

وقتی یک نوع خطا معنای مشخصی در منطق برنامه دارد، کلاس اختصاصی می‌تواند مفید باشد؛ برای مثال:

• سفارش قابل پردازش نیست.
• موجودی محصول کافی نیست.
• اعتبار حساب کاربر تمام شده است.
• عملیات روی یک سرویس غیرفعال انجام شده است.

با این روش، می‌توانید برای هر نوع استثنا رفتار مشخصی تعریف کنید.

۱۱. مدیریت خطاهای اعتبارسنجی

خطاهای اعتبارسنجی با بسیاری از خطاهای داخلی برنامه متفاوت‌اند. اگر کاربر فرم را با داده‌های نامعتبر ارسال کند، معمولاً نیازی نیست این اتفاق را به‌عنوان خطای بحرانی ثبت کنید.

لاراول سیستم اعتبارسنجی داخلی دارد:

$request->validate([

    'name' => ['required', 'string', 'max:255'],

    'email' => ['required', 'email'],

]);

اگر داده‌ها معتبر نباشند، لاراول به‌صورت خودکار رفتار مناسب را برای درخواست تنظیم می‌کند.

برای درخواست‌های معمولی وب، اغلب کاربر به فرم برگردانده می‌شود و خطاهای اعتبارسنجی در اختیار رابط کاربری قرار می‌گیرند. برای درخواست‌های API که انتظار JSON دارند، پاسخ خطای اعتبارسنجی معمولاً با وضعیت HTTP برابر 422 برگردانده می‌شود.

بنابراین، لازم نیست برای تمام خطاهای اعتبارسنجی، try/catch بنویسید.

اگر نیاز به قالب پاسخ متفاوتی دارید، می‌توانید رفتار مربوطه را متناسب با قرارداد API خود تنظیم کنید.

۱۲. تفاوت مدیریت خطا و ثبت لاگ چیست؟

مدیریت خطا و ثبت لاگ به یکدیگر مرتبط‌اند، اما هدف یکسانی ندارند.

برای مثال، اگر عملیات پرداخت ناموفق باشد، می‌توانید خطا را ثبت کنید و در عین حال پاسخ مناسبی به کاربر بدهید.

این دو کار مکمل یکدیگرند: کاربر پاسخ قابل‌فهم دریافت می‌کند و توسعه‌دهنده نیز اطلاعات لازم برای بررسی مشکل را خواهد داشت.

۱۳. نکات امنیتی در مدیریت خطا

یکی از مهم‌ترین اصول مدیریت خطا، جلوگیری از افشای اطلاعات داخلی برنامه است.

غیرفعال کردن Debug در محیط تولید

در فایل .env محیط عملیاتی، مقدار زیر باید معمولاً به این شکل باشد:

APP_DEBUG=false

اگر APP_DEBUG=true باشد، ممکن است جزئیات فنی خطا، مسیر فایل‌ها یا اطلاعات داخلی برنامه به کاربر نمایش داده شوند.

در محیط توسعه می‌توانید Debug را فعال کنید؛ اما در محیط عملیاتی باید آن را غیرفعال نگه دارید.

پس از تغییر تنظیمات، مطمئن شوید کش پیکربندی و فرایند استقرار باعث باقی ماندن مقدار قبلی نشده‌اند.

پیام فنی را مستقیماً به کاربر نمایش ندهید

برای مثال، این روش مناسب نیست:

catch (Throwable $e) {

    return response()->json([

        'message' => $e->getMessage(),

    ], 500);

}

چرا؟ چون پیام استثنا ممکن است جزئیاتی درباره ساختار داخلی برنامه، پایگاه داده یا سرویس‌های وابسته افشا کند.

روش مناسب‌تر:

catch (Throwable $e) {

    report($e);



    return response()->json([

        'message' => 'خطایی در پردازش درخواست رخ داد.',

    ], 500);

}

این مثال برای موقعیتی است که واقعاً تصمیم گرفته‌اید استثنا را در همین بخش مدیریت کنید. در غیر این صورت، بهتر است اجازه دهید سیستم مرکزی لاراول خطا را گزارش و پردازش کند.

از ثبت اطلاعات حساس خودداری کنید

هنگام ثبت خطا، اطلاعاتی مانند رمز عبور، توکن دسترسی، کلیدهای خصوصی و اطلاعات محرمانه پرداخت را وارد لاگ نکنید.

در عین حال، شناسه درخواست، شناسه سفارش یا کد پیگیری غیرحساس می‌تواند به عیب‌یابی کمک کند.

۱۴. اشتباهات رایج در Exception Handling

اشتباه اول: گرفتن تمام خطاها و نادیده گرفتن آن‌ها

اگر خطا را دریافت کنید اما نه آن را گزارش کنید و نه پاسخ درستی برگردانید، پیدا کردن مشکل دشوار می‌شود.

اشتباه دوم: استفاده بیش‌ازحد از try/catch

این کار کد را پیچیده می‌کند و ممکن است رفتار پیش‌فرض مدیریت استثنا در لاراول را بی‌دلیل دور بزند.

اشتباه سوم: نمایش جزئیات Exception به کاربران

پیام فنی خطا برای توسعه‌دهنده مفید است، اما لزوماً نباید در پاسخ عمومی سایت یا API نمایش داده شود.

اشتباه چهارم: ساخت صفحه 404 بدون وضعیت HTTP مناسب

صفحه‌ای که فقط عبارت «پیدا نشد» را نمایش می‌دهد، اما وضعیت 200 برمی‌گرداند، از نظر رفتار HTTP با یک پاسخ واقعی 404 متفاوت است.

اشتباه پنجم: تصور اینکه صفحه خطا، مشکل را برطرف می‌کند

صفحه 500 فقط پاسخ مناسب‌تری به کاربر می‌دهد. علت خطا همچنان باید از طریق لاگ‌ها و بررسی فنی پیدا شود.

جمع‌بندی

مدیریت خطا در لاراول به شما کمک می‌کند هنگام بروز مشکل، کنترل بیشتری روی رفتار برنامه داشته باشید. به‌جای نمایش پیام‌های نامفهوم یا افشای اطلاعات داخلی، می‌توانید استثناها را گزارش کنید، پاسخ HTTP مناسب برگردانید و صفحات خطای سفارشی بسازید.

در این مقاله یاد گرفتیم:

• Exception چیست و چگونه با try/catch مدیریت می‌شود.
• لاراول چگونه استثناها را گزارش و به پاسخ HTTP تبدیل می‌کند.
• چگونه خطاهای 404 و 500 را مدیریت کنیم.
• چگونه صفحات خطای سفارشی بسازیم.
• چگونه پاسخ خطا را برای API به JSON تبدیل کنیم.
• چگونه Exception اختصاصی ایجاد کنیم.
• چرا غیرفعال کردن Debug در محیط تولید ضروری است.

به‌عنوان یک قاعده کلی، خطاهای قابل‌پیش‌بینی را با رفتار مشخص مدیریت کنید، اجازه دهید سیستم مرکزی لاراول خطاهای مدیریت‌نشده را پردازش کند و برای عیب‌یابی، اطلاعات مفید اما غیرحساس ثبت کنید.

منابع رسمی

• مستندات مدیریت خطا در Laravel 12
• مستندات Logging در Laravel 12
• مستندات اعتبارسنجی در Laravel 12