پیش از هر چیز، ابتدا نیم نگاهی به داستانی فرضی داشته باشیم و در ادامه به بررسی ربط این داستان به ارورهای کدنویسی خواهیم پرداخت. فرض کنید که پس از فارغ التحصیلی از دانشگاه، چند سالی است که هم دانشکده یی های خود را ندیده اید و به لطف شبکه‌های اجتماعی، شما و همکلاسی هایتان همدیگر را می یابید. در یک کافه یا رستورانی قرار می‌گذارید تا یکدیگر را ملاقات کنید. زمان جلسه ساعت 5 بعد از ظهر است و اما شما تازه ساعت 4:30 از منزل بیرون رفته‌اید و از آنجا که اصلاً دوست ندارید پس از سال ها، آدم بدقولی جلوه کنید، با سرعت هرچه تمام تر به سوی محل قرار ملاقات پیش می روید.
از این تاکسی به اون تاکسی، از این اتوبوس به آن اتوبوس، جاهایی را هم از کوچه پس کوچه‌ها می‌روید که سریع‌تر به مقصد برسید. در حال عبور کردن از مقابل مغازه یی که صاحب آن داشت جلوی مغازه اش را آبپاشی می کرد، کمی تلو تلو می‌خورید و ناگهان نقش بر زمین می شوید!
با توجه به این که خیلی عجله دارید، اول احساس درد زیادی نمی‌کنید و به سرعت بلند شده، لباس هایتان را می تکانید و مجدد به سرعت هرچه تمام تر به راه خود ادامه می‌دهید و در نهایت تقریبا به‌موقع به قرار ملاقات خود می رسید. در حین گپ و گفتگو با دوستان، باز هم کمی احساس درد می‌کنید که با خود می‌گویید که "خب زمین خورده ام و کمرم کمی کوفتگی پیدا کرده!" در طول کل جلسه، آن طور که باید و شاید از در کنار دوستان قدیمی خود بودن لذت نمی برید تا این که جلسه به پایان می‌رسد اما از آنجا که ثانیه به ثانیه به درد کمر شما افزوده می شود، مجبور می‌شوید که فردای آن روز به درمانگاه مراجعه کنید و می‌بینید که دیسک کمر شما آسیب دیده است.
واقعیت امر آن است که اگر به محض زمین خوردن، موضوع جدی گرفته می‌شد و به درمانگاه مراجعه می کردیم، شاید هرگز این آسیب دیدگی به دیسک های کمر کشیده نمی‌شد و صرفاً با چند روز استراحت و مراعات مشکل حل می شد! کدنویسی بسیاری از برنامه نویسان هم شبیه به داستان بالا است. چگونه؟ به این شکل که وقتی با اروری در کدهای خود مواجه می شوند، اگر آن ارور به گونه یی باشد که وی را از ادامه ی توسعه ی نرم افزارش نگاه ندارد، ارور را نادیده گرفته و به کار خود ادامه می‌دهند و همین مسأله منجر به بروز مشکلاتی گاها بسیار بزرگ در آینده ی نرم‌افزار می شوند. اگر بخواهیم به مسأله ی ارورها از این بعد نگاه کنیم، ارورهای نرم افزاری را می‌توان به دسته های زیر تقسیم‌بندی کرد:
دستورات return
خیلی اوقات پیش می‌آید فانکشن هایی که می نویسیم، باید چیزی را اصطلاحاً ریترن کنند اما هرگز چک نمی‌کنیم که فانکشن مد نظر دقیقاً چه چیزی را ریترن کرده است چرا که گاهی اوقات پیش می‌آید که اگر فانکشن ما چیزی را ریترن نکند، ما در مراحل ابتدایی توسعه ی نرم‌افزار اصلاً متوجه آن نخواهیم شد.
اکسپشن ها
مدیریت Exception ها در بسیاری از زبان‌های برنامه نویسی سطح بالا دیده می‌شود و کار برنامه نویسان را ساده کرده است چرا که در صورت بروز چنین اکسپشن هایی، مفسر زبان برنامه نویسی مد نظر به ما هشدار خواهد داد. گاهی اوقات برنامه نویسانی را می‌بینیم که مثلاً در زبان برنامه نویسی پی اچ پی به شکل زیر از ساختار مدیریت اکسپشن ها استفاده می کنند:
try {
// do something
} catch() {} // ignoring catching any errorsهمان طور که در بلوک کد بالا مشاهده می شود، برنامه نویس به خوبی بخش try را هندل کرده است اما اگر به هر دلیلی این قسمت به مشکل برخورد، در بخش catch هیچ کدی برای گرفتن اکسپشن ها نوشته نشده است!
به طور خلاصه، باید بگوییم همان‌طور که بی توجه به درد کمر می‌تواند منجر به صدماتی جدی به دیسک های کمر شود، بی توجه به ارورها، هشدارها، اکسپشن ها و … در حین فرایند توسعه ی نرم‌افزار -خواه نرم‌افزار دسکتاپ باشد، خواه اپ موبایل یا وب اپلیکیشن- می‌تواند منجر به مشکلاتی جدی در مراحل تکمیلی توسعه ی نرم‌افزار گردد که از آن جمله می‌توان به موارد زیر اشاره کرد:
- دشواری در یافتن باگ ها زمانی که برنامه بزرگ‌تر می شود.
- ایجاد حفره های امنیتی در نرم‌افزار و بالا رفتن ضریب هک.
- عدم تمایل سایر توسعه دهندگان به مشارکت در توسعه ی نرم‌افزار شما
لذا ضروری به نظر می رسد که به محض مواجهه با ارورهایی از هر نوع، فورا اقدام به رفع آن ها کرده و هرگز کار امروز را به فردا محول نکنیم.
