HandlerExceptionResolvers – Spring MVC

اگر به اینترفیس Controller مراجعه کنیم می بینیم که متدی با نام handle وجود دارد.

 

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

متد handle استثنائی از نوع java.lang.Exception را پشتیبانی می کند. IDEهای خوب، به طور خودکار متد را سربارگذاری کرده و در حالی که این کار را انجام می دهند، عبارت throws را به متد اضافه می کنند. به یاد داشته باشید که شما می توانید، و به طور معمول باید، عبارات throws را برای متدها خاص منظوره کنید. این کار به طور کلی خوب است، زیرا مانع از ایجاد استثنائاتی می شود که نامشخص هستند (در صورتی که java.lang.Exception ذکر نشود، کامپایل با خطا مواجه خواهد شد). نکته دوم اینکه، استفاده از استثناهای خاص، به خودکار سازی سند کردن کنترلر شما، کمک می کند. هنگام بررسی JavaDoc، شما می توانید به راحتی تمام اطلاعات در مورد استثناهای ممکن کنترلر را بدست آورید، که به نوبه خود برای اتخاذ یک سیاست منسجم برای مقابله با آنها مفید خواهد بود.

کنترلر را تصور کنید که برای رزرو صندلی برای تئاتر استفاده می شود. این کنترلر ساده یک پارامتر درخواست را برای شناسایی تئاتر نیاز دارد. این کنترلر با استفاده از یک شئ service، به دنبال تئاتر مورد نظر می گردد و در صورت عدم وجود این تئاتر استثنای ShowNotFoundException را ایجاد می کند. به عبارت دیگر، امضای متد کنترلر به این صورت است (با این فرض که نویسندگان این کد به درستی عبارت throws را نوشته باشند):

 

شاید شما تصور کنید که در دیگر کنترلرها، ممکن است شرایط خطای مشابهی بوجود آید و در نتیجه یک استثنای ShowNotFoundExceptions ایجاد شود. از آنجایی که ما می خواهیم روش مقابله با خطا در کل برنامه مشابه باشد، بهتر است کنترل خطا را از ایجاد خطا جدا کنیم.

Spring یک HandlerExceptionResolvers ایجاد کرده است که اجازه می دهد زمانی که یک استثنا ایجاد می شود رفتاری مستقل از کنترلر داشته باشیم. HandlerExceptionResolvers، همانند LocaleResolver، MultipartResolver، HandlerMapping، و اجزای زیربنایی دیگر Spring MVC به صورت خودکار توسط DispatcherServlet انتخاب می شود. HandlerExceptionResolver یک متد ارائه می دهد:

 

توجه داشته باشید که این متد مجاز به ایجاد یک استثنا نیست. آرگومان handler نشان دهنده کنترلر و یا interceptor است که استثنا از آن جا سرچشمه گرفته و به همراه خود استثنا به متد منتقل می شود.

با وجود اینکه شما می توانید یک HandlerExceptionResolver برای خود پیاده سازی کنید و رفتار سفارشی را در زمانی که یک استثنا ایجاد می شود درون آن قرار دهید، اما قبل از انجام این کار، ابتدا نگاهی به Spring SimpleMappingExceptionResolver داشته باشید. این کلاس پارامترهایی را برای تعیین کد وضعیت در نظر گرفته است و همچنین در حالی که به یک view خاص هدایت می شود، استثنای ایجاد شده را درون model قرار می دهد.

در مورد پیکربندی SimpleMappingExceptionResolver ابتدا با نام bean مربوط به آن شروع می کنیم:

 

در ابتدا باید exceptionMapping راه اندازی شود. این یک شی از نوع property شامل الگوهای نام کلاس و نام view است. اگر نام کلاس استثنا منطبق بر الگوی تعیین شده باشد، از نام view مربوطه استفاده خواهد شد. این الگو از نویسه عام[۱] پشتیبانی نمی کند – فقط کافی است یک زیررشته منطبق با نام کلاس داده شود. بنابراین، شما باید به این نکته دقت داشته باشید که چه الگویی را قرار است استفاده کنید. استفاده از Exception به عنوان الگو، تقریبا همیشه، با استثناهایی که این عبارت را در نام کلاس خود دارند، مطابقت خواهد کرد. البته، استفاده از FQCN همچنین ممکن است و همیشه نتیجه مورد انتظار را تولید خواهد کرد. در مثال زیر، یک استثنا از نوع ShowNotFoundException به viewای منتج خواهد شده که در shownotfound تعریف شده است.

 

در ادامه، ما به resolver خواهیم گفت که استثنا را در مدل قرار دهد. صفت exception در مدل قابل تنظیم است. همه این موارد در کنار هم، مکانیزم کنترل خطا ارائه شده توسط Servlet specification را شبیه سازی می کند. تفاوت بین این دو در این است که این مورد شرایط متناسب با محیط تولید برنامه های تحت وب، ایجاد می کند. به عنوان مثال، این روش به شما امکان دسترسی به handler را می دهد که استثنا از آنجا نشات گرفته است.

 

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

 

آخرین پارامتری که باید تهیه شود، ارائه دو JSP (یا قالب Velocity، ماکروهای FreeMarker، و یا دوست داشته باشید Excel view) است. یک مورد اینجا نمایش داده می شود:

 

آخرین چیزی که نیاز است در مورد HandlerExceptionResolverها گفته شود این است که می توان بیش از یک نمونه از آنها را به برنامه اضافه، و با استفاده از خصیصه order مرتب کرد. در صورتی که چند resolver تعریف کنید، SimpleMappingExceptionResolver قابلیت دیگری اضافه می کند: خاصیت mappedHandlers. این خاصیت، مجموعه تمام handlerهایی را نگه می دارد که با این resolver باید بررسی شود. در صورتی که خاصیت mappedHandlers تنظیم نشده باشد، این resolver بر روی تمام handlerهای برنامه اعمال می شود. این ویژگی، به ویژه در یک برنامه پیچیده که در آن چندین  HandlerMapping استفاده شده باشد مفید است. به طور کلی، یکی resolver استثنا به یک کنترلر نگاشت خواهد شد.

شما باید بتوانید ثبات را در رویکرد کلی Spring MVC، با توجه به نقاط گسترش[۲] مانند resolve استثنا، view resolver، و … ببینید. پروژه Spring احتمالا تاکید زیادی تر بر روی ثبات، نسبت به فریم ورک های دیگر دارد.

[۱] Wildcard

[۲] Extension Points

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *