معماری بلوک try

[alireza_tavakol]

قبلا" به من آموخته بودن که وقتی در حلقه for یا ساختار شرطی if ، یک خط دستور داری می تونی از گذاشتن {} صرفه نظر کنی . مثلا" یعنی اگه حلقه زیر را مفروضا" مدنظر قرار دهیم

for (int i = 0; i < 10; i++)
{
MessageBox.Show(i.ToString());
}


می توانستیم از کد زیر برای خلاصه نویسی بهره جوییم

for (int i = 0; i < 10; i++)
MessageBox.Show(i.ToString());

حال سوالی دارم چرا بلوک try catch این قابلیت را ندارد و حتما باید دستورات بدنه را در {} قرار دهیم و کد زیر باعث به وجود آمدن خطا می شود؟:متفکر:
// Syntax Error
try
throw new Exception();
catch
MessageBox.Show("Error");

[debugger]

میخوای چی کار کنی ؟ میخوای کامپایلر را باز نویسی کنی ؟؟؟؟

خب اگر ارور میده {} را بزار دیگه

حتما تعریف نشده براش

[alireza_tavakol]

حتما تعریف نشده براش

دقیقا" سوال من همینه

آیا عمدا" کامپایلر نویس ، اجبارا" برنامه نویس رو مجبر به گذاشتن {} کرده؟
- خیلی خوب ، پس بفرمایید با چه هدفی این کار رو انجام داده؟:متفکر:

اگر هم سهوا" برای بلوک try یادش رفته خلاصه نویسی رو مد نظر قرار بده!
- پس یا ما خیلی ساده انگاریم یا خیلی کامپایلر نویس سر به هوا تشریف داره:لبخند:

[debugger]

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

[saeeedft]

سلام دوست عزیز،شما زمانی که این دو دستور رو مینویسی در واقع این دو یک دستور کلی هستند و این یک قانون درمورد این گونه دستورات است،مثل زمانی که شما get و set برای یک property تعریف میکنی

[als_1360]

نظر شخصي :
حلقه For مي تواند در يك حط تعريف شود
ولي وقتي شما Try catch رو به روش دوم مي نويسيد عملاً دو خط كد نوشته ايد و چون دستوري به نام catch نداريم و همچنين ادامه Try قابل دنبالكردن نيست اون ارور رو مي ده پس كامپايلر نويس مجبور بوده اينطوري عمل كنه

[Exception]

دقیقا" سوال من همینه

آیا عمدا" کامپایلر نویس ، اجبارا" برنامه نویس رو مجبر به گذاشتن {} کرده؟
- خیلی خوب ، پس بفرمایید با چه هدفی این کار رو انجام داده؟:متفکر:

اگر هم سهوا" برای بلوک try یادش رفته خلاصه نویسی رو مد نظر قرار بده!
- پس یا ما خیلی ساده انگاریم یا خیلی کامپایلر نویس سر به هوا تشریف داره:لبخند:
اشتباه اصلی شما اینه که فکر میکنید که کامپایلر C#‎‎ همون زبان C#‎‎ هست در حالی که دو تا مبحث جدا هستند! اول ویژگیهای C#‎‎ به طور کامل تعریف میشه و بعد براش کامپایلر مینویسن.
پس اینطور نیست که کامپایلرنویس عمدا یا سهوا بخواد کسی رو مجبور کنه یا نکنه!
این زبان (و نه کامپایلر) در Ecma 334 (http://www.ecma-international.org/publications/standards/Ecma-334.htm) و ISO/IEC 23270:2003 (http://www.iso.org/iso/catalogue_detail.htm?csnumber=36768) تعریف شده. درسته که امتیاز هردو متعلق به مایکروسافت هست، ولی عملا دو موضوع مجزا هستند.

حالا در مورد اینکه هدف چی بوده، فکر میکنم به خاطر سازگاری با زبان C و ++C ساختارهای قدیمی به این صورت حفظ شده و سعی شده که برنامه نویسهای C هم راحت باشن. از طرفی در #C سعی شده تا حد ممکن امکان اشتباه کم بشه و بنابراین در ساختارهای جدیدتر این آکولادها الزامی شده اند.
ضمنا، فقط try نیست که آکولاد اجباری داره. مثلا آکولاد خود تعریف تابع هم اجباری هست.

[alireza_tavakol]

شما زمانی که این دو دستور رو مینویسی در واقع این دو یک دستور کلی هستند و این یک قانون درمورد این گونه دستورات است

من فکر نمیکنم که بلوک try catch یک دستور حساب بشه .واسه اثبات حرفم دو تا دلیل میارم

1- در ساختار زبان C قانونی وجود دارد به این مضمون : در پایان هر دستور باید کاراکتر ; قرار گیرد . غلظت این قانون تا حدی است که در زبان C وقتی struct تعریف میکنی حتما" باید ; را بعد از { قرار دهید! و چون C# از فرزندان خلف C حساب میشه به قوانین C پایبنده و اگه try دستور حساب می شود حتما" بعد از { نیاز بود که کاراکتر ; قید شود
2- همیشه دستورات یک ساختار ثابت و مشخصی دارند ولی بلوک ساختاری انتخابی دارند! مثلا" در بلوک if مختاری که از بخش else استفاده بکنی یا استفاده نکنی . در بلوک tay شما مختاری که از حالت های مختلف استفاده کنی مثلا" می تونی try catch بنویسی یا try finally بنویسی یا از هر سه بخش try catch finally استفاده کنی

_______________________________________
شما فرمودین این قضیه اجباری بودن {} یک قانون است. منم قبول دارم که یک قانونه ولی پش هر قانونی یک هدفی وجود داره ! من از شما می پرسم هدف این قانون چیه؟

[alireza_tavakol]

ولي وقتي شما Try catch رو به روش دوم مي نويسيد عملاً دو خط كد نوشته ايد و چون دستوري به نام catch نداريم و همچنين ادامه Try قابل دنبالكردن نيست اون ارور رو مي ده پس كامپايلر نويس مجبور بوده اينطوري عمل كنه

اگر فرض رو بر صحت نظریه جناب عالی بگذاریم پس نظر شما در مورد بلوک شرطی if چیه؟

if(true)
...;
else
...;

پس لابد وقتی دستور بالا رو ما می نویسیم دو خط کد باید حساب بشه و چون دستوری به نام else نداریم ادامه دستور if غیر قابل دنبال باید بشه و error بده! چرا توی ساختار if کامپایلر گیج نمیشه و هیچ کدوم از این اتفاقات نمی افته؟

[alireza_tavakol]

اشتباه اصلی شما اینه که فکر میکنید که کامپایلر C#‎‎‎‎‎ همون زبان C#‎‎‎‎‎ هست در حالی که دو تا مبحث جدا هستند! اول ویژگیهای C#‎‎‎‎‎ به طور کامل تعریف میشه و بعد براش کامپایلر مینویسن.
حالا در مورد اینکه هدف چی بوده، فکر میکنم به خاطر سازگاری با زبان C و ++C ساختارهای قدیمی به این صورت حفظ شده و سعی شده که برنامه نویسهای C هم راحت باشن. از طرفی در C#‎‎‎ سعی شده تا حد ممکن امکان اشتباه کم بشه و بنابراین در ساختارهای جدیدتر این آکولادها الزامی شده اند.
ضمنا، فقط try نیست که آکولاد اجباری داره. مثلا آکولاد خود تعریف تابع هم اجباری هست.

اشتباه اصلی شما اینه که هنوز هدف از استفاده توابع* رو درک نکردین!

سوال : چرا و کی از توابع استفاده میکنیم ؟
جواب : وقتی قرار چند خط کد در چند جای مختلف برنامه اجرا بشه از توابع استفاده میکنیم
مفهوم : اگه قرار باشه یک خط کد در یک تابع قرار بگیره اصلا" نیازی به تعریف تابع نیست چون هر جا قرار اسم تابع رو call کنید همان یک خط کد را بنویسید

پس منطقی است که برای تعریف تابع نوشتن {} اجباری باشد
______________________________________
*در اینجا منظور از تابع ، همان متد است

[Exception]

اشتباه اصلی شما اینه که هنوز هدف از استفاده توابع* رو درک نکردین!

سوال : چرا و کی از توابع استفاده میکنیم ؟
جواب : وقتی قرار چند خط کد در چند جای مختلف برنامه اجرا بشه از توابع استفاده میکنیم
مفهوم : اگه قرار باشه یک خط کد در یک تابع قرار بگیره اصلا" نیازی به تعریف تابع نیست چون هر جا قرار اسم تابع رو call کنید همان یک خط کد را بنویسید

پس منطقی است که برای تعریف تابع نوشتن {} اجباری باشد
______________________________________
*در اینجا منظور از تابع ، همان متد است
میشه یک منبع برای جوابی که دادین ذکر کنین؟ چون به نظر من اصلا منطقی نیست جواب و مفهومی که گفتین. اما اگر یک منبع درست برای جواب ذکر کنید، حتما قبول میکنم.
ضمنا، فرق تابع و متد رو هم برام توضیح بدین. متوجه نشدم چرا اینقدر حساس بودین رو این مساله! اگر منظورتون اینه که تو C#‎ اسمش میشه متد، حق با شماست ولی با این تاکیدی که شما کردین، فکر کردم شاید تو C#‎ یک تابع داریم و یک متد که با هم فرق دارن!

PS: نمیدونم چرا احساس میکنم از لحن پست من ناراحت شده بودین. اگر اینجوری بوده، منظور بدی نداشتم.

[alireza_tavakol]

میشه یک منبع برای جوابی که دادین ذکر کنین؟ چون به نظر من اصلا منطقی نیست جواب و مفهومی که گفتین. اما اگر یک منبع درست برای جواب ذکر کنید، حتما قبول میکنم.
ضمنا، فرق تابع و متد رو هم برام توضیح بدین. متوجه نشدم چرا اینقدر حساس بودین رو این مساله! اگر منظورتون اینه که تو C#‎‎‎‎‎‎ اسمش میشه متد، حق با شماست ولی با این تاکیدی که شما کردین، فکر کردم شاید تو C#‎‎‎‎‎‎ یک تابع داریم و یک متد که با هم فرق دارن!

PS:
من در اکثر موارد نمی تونم منبع معتبری واسه گفته هام ارائه بدم ولی فکر کنم توی کتاب پاسکل که توی سال اول هنرستان تدریس میشه خواندم!:افسرده:

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

نمیدونم چرا احساس میکنم از لحن پست من ناراحت شده بودین. اگر اینجوری بوده، منظور بدی نداشتم.:چشمک: