جناب کشاورز ، فرمایش شما متین است ! ولی من تا حالا به مورد هایی بر خوردم که دلفی الکی Error میده در صورتی که اگه بیرون IDE تست کنی Error در کار نیست ! تا اونجا که من میدونم بر داشتن این تیک باعث میشه شما بجای Error خود دلفی Error ویندوزی را ببینید که به نظر من قابل فهم تره تا EAccessViolation های دلفی ! البته صحبت شما را رد نمیکنم چون درسته !
علت اینکه بیرون IDE خطایی در کار نیست این هست که اون خطا توسط exception handling در کد شما، یا در کدی که شما به هر نحوی استفاده می کنید (مثلا در کد یک کامپوننت) خفه شده. شما خطا را بیرون IDE نمی بینید، ولی در داخل IDE همه خطاها نمایش داده می شوند، تا برنامه نویس بداند که چه خطاهایی در هنگام اجرای برنامه اش رخ می دهند، و اگر خطا نمایش داده نمی شود، چه کدی، و به چه شکلی آن را خفه می کند. این امر باعث می شود که هیچ خطایی از چشم برنامه نویس پنهان نماند. ایده ایی که شما مطرح می کنید آن هست که خطا زمانی خطا هست که بصورت یک پیغام به کاربر نمایش داده شود، و تا زمانی که پیغام خطایی به کاربر نهایی نمایش داده نمی شود، چندان اهمیتی ندارد که آن را بررسی کنیم! نتیجه همچین تفکری میشه تولید نرم افزارهای پر از باگ های پنهان که باید مدت ها وقت صرف کرد تا اشکال واقعی آنها کشف بشوند.

منظور از چرت و پرت این بود که اگه برای یک Error این چک را بگذارین و حذف کنین ! بعضی وقتها متوجه اختلافات فاحشی میشین ! مثلا اگه Socket Error داشته باشید ! و چک فعال باشه شما فقط متوجه یه ESocketError میشین اما نمیگه شماره Error چیه ! اما خود ویندوز شماره Error را هم توی پیغام در صورت برداشتن چک میده ! منظور منم از چرت و پرت این بود !
این بخاطر آن هست که دیباگر دلفی خطا Exception را در مراحل مختلف چرخه حیاتش دنبال می کند. یک Exception ممکن است از یک کد بسیار سطح پایین تولید شود، و مرحله به مرحله از یک سطح به سطح بالاتری منتقل شود، و در هر سطح اطلاعاتی به آن اضافه شود. دیباگر برای اینکه به شما امکان پیگیری این فرایند را بدهد، از لحظه اول تا لحظه آخر مراحل حرکت Exception را به شما نمایش می دهد. مثلا در بعضی مواقع می بینید که یک خطا بعد از تولید، و کلیک بر روی دکمه Continue، بلافاصله تکرار می شود. این یعنی خطا در یک سطح پایین رخ داده، در آنجا Exception تولید شده، ولی بعد از پردازش آن، Exception مجددا توسط کد raise شده، تا به سطح بالاتری برسد، و کد سطح بالاتر هم Exception را دریافت کرده، و مجددا آن را raise کرده است.
همچین روالی برای یک برنامه نویس کم حوصله که توجهی به کیفیت نرم افزار تولیدی ندارد، یک روال خسته کننده و ملال آور هست. ولی برنامه نویسی که به کیفیت نرم افزار تولیدی اهمیت می دهد، به تک تک این Exception ها توجه نشان می دهد، و معنی هر یک از آنها، چگونگی بوجود آمدن آنها، و مسیری را که طی می کنند تا به کاربر برسند را دنبال می کند.

بعد از بررسی های فنی مناسب، برای آنکه برنامه نویس متوجه شود که روند اجرای برنامه در زمان وقوع آن خطاها از دید کاربر برنامه چگونه هست، می تواند با استفاده ازگزینه Run without debugger برنامه را به شکل عادی اجرا کند.