try تو در تو

[قله بلند]

با سلام
دو برنامه زیر، دو شیوه استفاده از کلاس های استثناء تعریف شده توسط کاربر را با try تودرتو نشان می دهد. سوال من راجع به نحوه عملکرد try تو در تو می باشد.
ابتدا برنامه اول:
class TemperatureException extends Exception {}
class TooColdException extends TemperatureException {}
class TooHotException extends TemperatureException {}
class NestedTry3
{
public static void main (String args[])throws TemperatureException
{
try
{
try
{
throw new TooHotException();
}
catch (TooHotException the)
{
System.out.println("TooHotException");
throw the;
}
}
catch(TemperatureException te)
{
System.out.println("TemperatureException");
throw te;
}
}
}

output is:
TooHotException
TemperatureException
Exception in thread “main” TooHotException
at NestedTry3.main(NestedTry3.java:21)و برنامه دوم:
class TemperatureException extends Exception {}
class TooColdException extends TemperatureException {}
class TooHotException extends TemperatureException {}
class NestedTry3
{
public static void main (String args[])throws TemperatureException
{
try
{
try
{
throw new TooHotException();
}
catch (TooHotException the)
{
System.out.println("TooHotException");
throw new TooColdException();
}
}
catch(TooColdException tce)
{
System.out.println("TooColdException");
throw tce;
}
}
}

output is:
TooHotException
TooColdException
Exception in thread “main” TooColdException
at NestedTry3.main(NestedTry3.java:26)و اما سوال من:
در هر دو برنامه، من در catch آخر، استثنائی را پرتاب می کنم که گرفته نمی شود و موجب چاپ اثر و رد پشته جاوا می شود، یعنی برنامه به صورت عادی به کار خودش پایان نمی دهد بلکه به صورت ناگهانی تمام می شود. مگر نه اینکه پرتاب استثنائ آخرین catch موجب اتمام ناگهانی برنامه می شود پس در چاپ اثر و رد پشته جاوا باید آن استثناء چاپ شود، پس چرا اینگونه نمی شود؟

[قله بلند]

از دوستان کسی نمی تونه کمکی بکنه؟ شاید یک اشاره کوچک هم بتونه مشکل رو حل کنه.

[jlover]

بنده این برنامه ی شما رو به دقت بررسی کردم و هیچیش هم به نظرم غیرعادی نیست،اگر اونطور که من فهمیدم انتظار داشتین در خروجی برنامه ی اول بجای Exception in thread “main” TooHotException ، و در برنامه ی دوم بجای TooColdException بیاد و TemperatureException رو نمایش بده،باید بگم به علت زیر بیجاست :

آرگومانی که وارد بستار catch آخر میشه - مستقیمن - از نوع TemperatureException نیست بلکه از نوع ...TooCold و ...TooHot هست ، بنابراین اسم متناظر رو به درستی و به دقت چاپ میکنه

در کل هم این موردی که شما مطرح کردی من فکر میکنم در موارد واقعی به چنین طراحی ای نمیرسیم ...
ولی خب به عنوان یه کنجکاوی ذهنی می پسندمش :لبخندساده: ( آخه خودم همین الان گفتاری که به تشریح موضوع استثنا میپرداخت رو مرورشو تکمیل کردم :چشمک: )

[قله بلند]

آرگومانی که وارد بستار catch آخر میشه - مستقیمن - از نوع TemperatureException نیست بلکه از نوع ...TooCold و ...TooHot هست ، بنابراین اسم متناظر رو به درستی و به دقت چاپ میکنهسلام. ممنونم که توجه کردید. سوال من هم دقیقاً همین مطلب هست. وقتی کلاس فرزند پرتاب می شود یعنی یک نمونه از آن ساخته می شود که منجر به تولید کلاس پدر نیز می شود. یعنی با پرتاب کلاس فرزند، کلاس پدر نیز پرتاب می شود وگرنه نمی توانست شئی از کلاس فرزند را که پرتاب شده است بگیرد و اداره نماید. لطفاً برنامه اول را ببینید. در catch آخر از برنامه اول، شیئی از کلاس پدر در حال پرتاب شدن است. درست است؟ اگر درست است پس چرا ردیاب پشته، اسم کلاس فرزند را پاپ می کند نه اسم کلاس پدر را؟ مگر پرتاب شیء کلاس پدر باعث اتمام ناگهانی برنامه نشد؟

[jlover]

لطفاً برنامه اول را ببینید. در catch آخر از برنامه اول، شیئی از کلاس پدر در حال پرتاب شدن است. درست است؟
نه دیگه عزیز برادر،اینجا من یاد تاپیک جالب دیگه ای افتادم که شما ایجاد کردید(نگاهی دوباره به تساوی ) و اونجا پستم رو اگه خونده باشید،کاملن مرتبط هست به جوابی که الان بهتون میدم :

دقت بفرمایید تنها یکبار از کلمه کلیدی new در کلاس اول استفاده شده و اون هم برای ساختن شیئی از کلاس TooHotException بوده،بنابراین تنها شیئی که دقیقن ساخته شده،وجود داره و به اون حافظه اختصاص داده شده،همون THE هستش که البته فرزند TE میباشه . و شیئ متعلق به همین کلاس TooHotException هست که همینطور پاسکاری میشه

مسئله ی دیگه ای که سبب کژفهمی شما میشه اینه که :

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

و در آخر هم فراموش نکنید هر شیئی از کلاس THO یا TCE به نوعی یک TE هم هست ، یک Exception هم هست ، یک Throwable هم هست و در آخر یک Obgect هم هست ، پس حتی اگر در بستار catch از پارامتر Exception هم استفاده میکردید،مجاز بودید ولی این دلیل نمیشه که آرگومان ورودی دقیقن از نوع Exception باشه

این یک موضوع عمومی در رابطه با سلسله مراتب کلاسها و وراثته و مختص بحث حاضر هم نیست

پیروز باشید

[jlover]

انگار مدیریت کمی سرش شلوغه...
من خودم این پست تکراری رو حذف میکنم
:چشمک:

[قله بلند]

سلاممعلومه شما مطلب رو کامل فهمیدید و این من رو بسیار مسرور می کنه تا بالاخره جواب سوالم رو بتونم از زبون شما به دست بیارم. چیزی که خیلی ذهنم رو مشغول کرده ولی هنوز درک صحیحی از آن به دست نیاورده ام.بخش از متنی که مربوط به وراثت و ترکیب بود را ترجمه کرد. بخشی از آن به شرح زیر است:
از طریق وراثت، شما تصویر کلاس پایه را در تصویر شیء کلاس مشتق به محض ایجاد شیء کلاس مشتق به دست می­آورید و این تصویر تا زمانیکه شیء کلاس مشتق وجود دارد باقی می­ماند.این مطلب را کاملاً قبول دارم که کلاس مشتق از داده های غیر خصوصی کلاس پایه ارث بری می کند. آیا شما نیز جمله بالا را قبول دارید که کلاس پایه، سایه خود را در کلاس مشتق می اندازد و تا زمانیکه شیئی از کلاس فرزند وجود دارد، سایه پدر نیز برقرار است؟ پس می توان گفت که انگار، کلاس پایه، فیلدی از کلاس مشتق می شود؟شما فرمودید که کلاس فرزند با عملگر new ساخته شد و به آن فضا اختصاص داده شد و آدرس این فضا هم به متغیر ارجاع داده شد تا به نقطه مورد نظر در حافظه اشاره کند. کاملاً درست است.شما فرمودید که کلاس پدر با ساخت کلاس فرزند ساخته نمی شود پس چگونه قادر است که شیئ پرتابی کلاس فرزند را بگیرد و اداره نماید؟ وقتی می نویسیم
catch(TemperatureException te)یعنی te متغیر ارجاع است به کلاس TemperatureException . درست است؟ اگر TemperatureException ساخته نشود، برنامه خطای زمان کامپایل می دهد چون TemperatureException از نوع استثناء های RuntimeException نیست که در زمان اجرا، پرتاب می شوند. پس باید صریحاً اعلان و گرفته شوند.پاسخ شما را در تاپیک نگاهی جالب و دوباره به تساوی دوباره خواندم. ضمن تشکر باید بگویم که چگونه این اتفاق در مورد مثال اول این تاپیک می افتد؟TemperatureException te=the;منظور شما هم همینه؟ واقعاً من که گیج شدم. امیدوارم شما را گیج نکنم.

[jlover]

از طریق وراثت، شما تصویر کلاس پایه را در تصویر شیء کلاس مشتق به محض ایجاد شیء کلاس مشتق به دست می­آورید و این تصویر تا زمانیکه شیء کلاس مشتق وجود دارد باقی میماند.

این جمله توصیفی از یکی از مفاهیم جنبی وراثت هست.
آیا درسته؟
با در نظر گرفتن اینکه اولین باریه که به این جمله برمیخورم،میتونم بگم پذیرفتنیه،اما قدری گیج کننده !


پس می توان گفت که انگار، کلاس پایه، فیلدی از کلاس مشتق می شود؟

نه خیر
بدون هیچ توضیح اضافی.چرا؟چون مفهوم وراثت تعریفهای خود را دارد.
این جمله ذهن رو منحرف میکنه ! دقیقن داره میگه : یکی(یا تعدادی ) از فیلدهای شیئ کلاس اشتقاقی ، دقیقن در خود کلاس اشتقاقی وجود دارند،حال آنکه اینطور نیست و در کلاس پایه هستند و البته در کلاس مشتق شده هم میتوانند مورد استفاده قرار گیرند...
هر توضیح اضافه تری در توجیه این مطلب فقط به گمراهی بیشتر منتج میشه ( به نظر من ! )


شما فرمودید که کلاس پدر با ساخت کلاس فرزند ساخته نمی شود پس چگونه قادر است که شیئ پرتابی کلاس فرزند را بگیرد و اداره نماید؟ وقتی می نویسیم

catch(TemperatureException te)

یعنی te متغیر ارجاع است به کلاس TemperatureException . درست است؟

در مورد عبارت قرمز شده :
اصلا و ابدا ، به هیچ وجه من الوجوه ، not at all
و البته توصیه نمیکنم برای پذیرش این مسئله به عباراتی که مورب کردم استناد کنید ! به تجربه ی عملیتون در هنگام کدنویسی رو بیارید،به تجربه ای که از نوشتن همین برنامه بدست آوردید تکیه کنید
te پارامتر ی هست که به آرگومان وارد شونده اشاره داره.آرگومان چیزی هست که واقعن وجود داره( اگر چه یک ارجاع باشه ! ).و آرگومان مورد نظر ما ( در اینجا the ) از نوع TooHotException هست مستقیمن و صد البته به طور غیر مستقیم از نوع TemperatureException هم هست،همونطور که از نوع تک تک کلاسهای مافوق ( Exception تا Object ) هم هست( باز هم به طور غیر مستقیم ) و به همین علت هست که توسط کلاس TemperatureException هم میتونه اداره بشه و باز هم به طور کل دقیقن به همین خاطر هست که متدهای رایجی چون
toString() , eaual() هم قابل استفاده برای همین اشیای کلاس مثلن THE نیز هست.
حتی شما اگر از Exception هم به جای TemperatureException استفاده میکردید،ایرادی وجود نداشت و همین خروجی تولید میشد( بد نیست یکبار امتحان کنید! )


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

عجب !

حالا مگه شما تو برنامه تون ساختینش که برنامه بدون ایراد اجرا شده ؟!

باید صریحاً اعلان و گرفته شوند.
باید از یا استفاده بشه
میدونید چرا اگر از throws در اعلان استفاده نکنید خطا میده ؟ چون شما سه تا پرتاب داری ولی دو تا catch ،استثنای آخر گرفته نمیشه، پس باید اعلان بشه ( برای گواهی میتونید throws رو از اعلان سر کلاس حذف کنید و آخرین دستور پرتاب رو هم همینطور،خاهید دید که بدون مشکل برنامه اجرا میشه - چون گرفته شدند،پس احتیاجی به اعلان صریحشون نیست )
و اینجا برای اینکه به سوالی که همین الان در ذهنتون شکل میگیره دوباره پاسخ داده باشم : وقتی TemperatureException رو اعلان میکنید،میتونه برای هر نوع اشتقاقی از این کلاس هم مورد استفاده قرار بگیره ، حتی مثلن TooXxxException ( اگر زیرکلاسی از TemperatureException باشه )

این هم برای اینکه چیزی از قلم نیفتاده باشه :

TemperatureException te=the

No :
TemperatureException te just refers to the belongs to class TooHotException

تمام چیزی که شما باید بدونید اینه که the و tce علاوه بر اینکه صریحن از نوع کلاس خودشون هستند،غیر مستقیم هم از نوع TemperatureException هستند و همینطور برو بالا تا خود Object
ولی یک TemperatureException یک THE یا TCE نیست

[قله بلند]

سلام
من در ابتدا در برنامه ام از استثناء هایی استفاده می کنم که غیر RuntimeException باشند یعنی زیر کلاسی از RuntimeException نباشند. در زمان کامپایل من پیغام خطا دریافت می کنم:
class NestedTry3
{
public static void main (String args[])throws IOException
{
try
{
throw new IOException();
}
catch (IllegalAccessException the)
{
System.out.println("IllegalAccessException");
}
}
}

Result: Error in time of compiling:Exception IllegalAccessException never thrown in the body of corresponding try statement.حالا کدی که از RuntimeException ها استفاده می کند:
class NestedTry3
{
public static void main (String args[])
{
try
{
throw new ArithmeticException();
}
catch (ArrayIndexOutOfBoundsException the)
{
System.out.println("ArrayIndexOutOfBoundsException");
}
}
}

Result:Exception in thread “main” in java.lang.ArithmeticExceptionAt NestedTry3.main(NestedTry3.java:30)یعنی دیگر خطای زمان کامپایل اتفاق نیفتاد. یعنی اینکه زیرکلاس­های کلاس RuntimeException در زمان اجرای برنامه پرتاب می شوند و اصلاً لزومی به پرتاب دستی برنامه نویس یا اعلان در throws ندارند.

[قله بلند]

سلام
من عمداً این دو پست رو جداگانه ایجاد کردم چون می خواستم خواننده با ترکیب کد و نوشته گیج نشه و راحت تر مطلب رو درک کنه.
اینطور که معلومه، گیری که من دارم و باعث شده این سوال ها را مطرح کنم عدم درک صحیح وراثت هست.
اجازه بدید من چند نکته رو راجع به وراثت بیان کنم:
1-با ارث بری، کلاس مشتق شده، اساساً همانند کلاس پایه است.

2-کلاس مشتق شده، خصوصی تر از کلاس پایه خود است و گروه کوچکتری از اشیاء را نشان می دهد.

3-یک کلاس مشتق شده می تواند بزرگتر از کلاس پایه خود باشد.

4-شیء کلاس مشتق شده، یک شیء از کلاس پایه است اما عکس آن درست نیست. برای مثال می توانیم تعداد زیادی از اشیاء مختلف مرتبط به هم را از طریق ارث بری در لیست پیوندی اشیاء کلاس به هم وصل کنیم. این کار اجازه می دهد که اشیاء مختلف به صورت کلی مورد پردازش قرار گیرند.
آیا این مطلب به این معنی است؟
Object__Throwable__Exception­­__TemperatureExcep tion__TooHotException
OR
Object__Throwable__Exception­­__TemperatureExcep tion__ TooColdException5-در رابطه ارث بری، یک شیء از کلاس مشتق شده را می توان به صورت شیئی از نوع کلاس پایه در نظر گرفت.

6-اغلب اوقات یک شیء از یک کلاس، عملاً یک شیء از کلاس دیگر است. مستطیل مطمئناً یک چهار ضلعی است. بنابراین می توان گفت که کلاس مستطیل از کلاس چهارضلعی مشتق می شود. مستطیل یک نوع خاص از چهار ضلعی است ولی نمی توان گفت که چهار ضلعی یک مستطیل است.

و اما گیری که من دارم و قفلی که در مغز من ایجاد شده و به دنبال کلید آن هستم. مورد 4 و 5و 6 که به نظر یک چیز هستند.
این جمله به چه معنا است: اغلب اوقات یک شیء از یک کلاس، عملاً یک شیء از کلاس دیگر است.
این جمله به چه معنا است: در رابطه ارث بری، یک شیء از کلاس مشتق شده را می توان به صورت شیئی از نوع کلاس پایه در نظر گرفت.
شیء کلاس مشتق شده، یک شیء از کلاس پایه است یعنی چه؟ یعنی شیء کلاس مستطیل همان شیء کلاس چهار ضلعی است؟ یعنی باید از هر دو کلاس شیء درست کنیم؟

[jlover]

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

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

5-در رابطه ارث بری، یک شیء از کلاس مشتق شده را می توان به صورت شیئی از نوع کلاس پایه در نظر گرفت.

و برای همین نمیشه گفت کاملن غلطه،شما باید بدونی که در نظر گرفتن یعنی فرض کردن،روشی که به ذهن برای حفظ برداشت مناسب از مطلب کمک می کنه ! پس نگفته واقعن،دقیقن،مستقیمن

6-اغلب اوقات یک شیء از یک کلاس، عملاً یک شیء از کلاس دیگر است. مستطیل مطمئناً یک چهار ضلعی است. بنابراین می توان گفت که کلاس مستطیل از کلاس چهارضلعی مشتق می شود. مستطیل یک نوع خاص از چهار ضلعی است ولی نمی توان گفت که چهار ضلعی یک مستطیل است.
این هم کم و بیش مثل مورد قبلشه،میگه به خاطر شمار زیادی از عناصری که به ارث میبره از کلاس(یا کلاسهای ) مافوق خودش،مثل این میمونه که یک شی ئ دیگه ست !
نگفت دقیقن،نگفت واقعن ! نگفت صریحن و مستقیمن !
این یک انگاشته !
این کتاب رو بذارید کنار تا اینجوری نشدین :عصبانی++:
:چشمک:
و بد نیست موارد مهم پستهای قبلیم رو اینجا بسته بندی کنم :

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

[قله بلند]

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

catch (TooHotException the)اینجا چه اتفاقی می افته؟ می شه لطف کنید و کلاً شرح دهید که چی می شه؟ کامپایلر این خط رو چگونه تفسیر می کنه؟
چقدر خوب می شد می فهمیدم شما چه طوری این مطلب براتون جا افتاد؟ چه طوری فهمیدید که قضیه از چه قراره؟ چون تا وقتی که مطلب برای کسی جا نیفتاده باشه نمی تونه برای کسی توضیح بده.

[jlover]

درود
اول از همه خواهش میکنم راحت باشید،خود من هم در حال یادگیری هستم...
اما برگردیم سر اصل مطلب :
وقتی که استثنایی پرتاب میشه ، کنترل برنامه از بستار try ی که استثنا از درون اون پرتاب شده خارج میشه و به اولین بستار catchی که پارامتر اون دربرگیرنده ی استثنای پرتاب شده - که به اون میگیم آرگومان - باشه ( یعنی از همون کلاسی که استثنا به اون تعلق داره یا کلاسهای مافوق اون ) میره و دستورات درون بستار رو اجرا میکنه . بعد هم به خطهای بعدی میره
اگر هم Catch مطابق رو پیدا نکنه ، برنامه به صورت ناموفقیت آمیز متوقف شده و پیغام استثنا و رد پشته ی فراخانی رو چاپ میکنه

من تمام ضروریات در مورد وراثت و داستان نمونه سازی (... new... ) رو در پستهای قبلی خدمتتون عرض کردم
پست قبلی هم مخصوصن به طور کل به این مسایل پرداخته

اینکه JVM چطور کار میکنه،داستان دیگه ای هست که من دقیقن نمیدونم،شاید - به احتمال زیاد - وقتی نمونه ای از هز کلاس که ساخته میشه،اطلاعات مربوط به کلاسهای مافوق اون هم توسط کامپایلر نگهداری میشه ...
اگه خیلی به این مسئله علاقه دارید،میتونید JVM specification رو بخونید
the java language specification هم به اکثر سوالات شما میتونه پاسخ بده(خود من حتمن میخونمش،الان چند صفحه اولشو فقط خوندم)
نسخه ی الکترونیکی هر دو کتاب به طور رایگان در سایت سان موجوده

باز هم فک میکنم مشکل شما اینه که نمیخاید قبول کنید که مثلن نمونه ی TooHotException و TooColdException ،گرچه دقیقن نمونه ای از کلاس(و کلاسهای ) مافوق خودشون نیستند،اما کامپایلر اونها رو متعلق به کل اون خونواده از سلسله مراتب میدونه،هر چند صریحن نمونه ای از کلاس های مافوق نیست
بنابراین شما هم باید اینطور در نظر بگیرید ! یعنی درست طوری که هست،نه اونطور که میل دارید!

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

اگر هم میل دارید بدونید که اینجور تفسیر کامپایلر چه مزیتی میتونه داسته باشه میتونید،پکیج ساده ای که درپست زیر قرار دادم رو نگاه کنید و ببینید که چطور در کلاس TestPrimes از یک کلاس انتزاعی نمونه سازی میکنم !!!
http://barnamenevis.org/forum/showthread.php?t=202273
سوالی بود بازم در خدمتم

[قله بلند]

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

Try
{
}
catch(Type1 id1)
{
}
catch(Type2 id2)
{
}
//...etc
هر شرط catch، شبیه یک تابع کوچک است که تنها یک آرگومان از یک نوع ویژه دارد. این شناسه(id1، id2 و...) می تواند درون یک اداره کننده، فقط شبیه آرگومان یک تابع مورد استفاده قرار گیرد. بعضی اوقات شما هرگز از این شناسه استفاده نخواهید کرد (نوع استثناء به شما اطلاعات کافی در مورد رفتار با آن استثناء را ارائه می کند)، اما این شناسه باید در محل مورد نظر وجود داشته باشد.
From Bruce[1].Eckel.Thinking.In.Java.4th.Edition.Dec.2007.eBook-BBL
یعنی در اینجا، این مقدار، آدرس شیء تازه ایجاد شده در حافظه است..