.NET- এ অ্যাপ্লিকেশনএক্সসেপশন কী?

Question

ব্যতিক্রম নিক্ষেপ করার জন্য, আমি সাধারণত বিল্ট-ইন ব্যতিক্রম ক্লাস, যেমন ব্যবহার ArgumentNullExceptionএবং NotSupportedException। তবে, কখনও কখনও আমাকে একটি কাস্টম ব্যতিক্রম ব্যবহার করতে হবে এবং সেই ক্ষেত্রে আমি লিখি:

class SlippedOnABananaException : Exception { }
class ChokedOnAnAppleException : Exception { }

ইত্যাদি। তারপরে আমি এগুলি আমার কোডে ফেলে দিই। কিন্তু আজ আমি ApplicationExceptionক্লাস জুড়ে এসেছি - আমি কি পরিবর্তে এটি ব্যবহার করা উচিত? এটা কীসের জন্য?

বিভিন্ন নামের সাথে কার্যকরভাবে অভিন্ন ব্যতিক্রমী ক্লাসগুলি পাওয়া অসম্ভব বলে মনে হচ্ছে (আমার সাধারণত কোনও পৃথক কার্যকারিতা প্রয়োজন হয় না) need তবে জেনেরিক ধরা ApplicationExceptionএবং ত্রুটিটি কী তা নির্ধারণ করতে অতিরিক্ত কোড ব্যবহার করার ধারণাটি আমি অপছন্দ করি ।

ApplicationExceptionআমার কোডের সাথে কোথায় ফিট করা উচিত ?

Comments

দুর্দান্ত প্রশ্ন, চতুরতার সাথে নামযুক্ত নমুনা ব্যতিক্রমগুলির জন্যও +1

— কোডি গ্রে

সম্পর্কিত: স্ট্যাকওভারফ্লো . com / প্রশ্নগুলি / 16603065/… ।

Answer 1

এমএসডিএন-তে মন্তব্য অনুসারে :

ব্যবহারকারী অ্যাপ্লিকেশনগুলি, সাধারণ ভাষার রানটাইম নয়, অ্যাপ্লিকেশনএক্সেপশন ক্লাস থেকে প্রাপ্ত কাস্টম ব্যতিক্রমগুলি ফেলে দেয়। অ্যাপ্লিকেশন এক্সসেপশন শ্রেণি অ্যাপ্লিকেশন দ্বারা সংজ্ঞায়িত ব্যতিক্রমগুলি সিস্টেমের দ্বারা সংজ্ঞায়িত ব্যতিক্রমগুলির মধ্যে পার্থক্য করে।

আপনি যদি এমন কোনও অ্যাপ্লিকেশন ডিজাইন করছেন যা এর নিজস্ব ব্যতিক্রমগুলি তৈরি করতে প্রয়োজন, তবে আপনাকে ব্যতিক্রম শ্রেণি থেকে কাস্টম ব্যতিক্রমগুলি গ্রহণ করার পরামর্শ দেওয়া হচ্ছে। এটি প্রাথমিকভাবে ভাবা হয়েছিল যে কাস্টম ব্যতিক্রমগুলি অ্যাপ্লিকেশন এক্সেসপশন ক্লাস থেকে নেওয়া উচিত; তবে বাস্তবে এটি উল্লেখযোগ্য মান যুক্ত করতে পাওয়া যায় নি। আরও তথ্যের জন্য, ব্যতিক্রমগুলি পরিচালনা করার জন্য সেরা অভ্যাসগুলি দেখুন।

এগুলি থেকে বের করুন Exception। এছাড়াও, যতক্ষণ না এটির ওয়্যারেন্টেড থাকে ততক্ষণ আমি আপনার ক্ষেত্রে নতুন ব্যতিক্রম তৈরি করতে সমস্যা দেখছি না see যদি আপনি এমন কোনও মামলার মুখোমুখি হন যেখানে ফ্রেমওয়ার্কটিতে ইতিমধ্যে একটি ব্যতিক্রম রয়েছে, তবে এটি ব্যবহার করুন, অন্যথায়, আপনার নিজের রোল করুন।

Comments

সুতরাং এটি মনে ApplicationExceptionহয় নিরর্থক এবং কেবল পিছনে সামঞ্জস্যের কারণে?

— বিটলস 1692

নতুন এমএসডিএন ডকুমেন্টেশন, কমপক্ষে ৪.7.২, এই মন্তব্যটি মিস করে। কুতোয়ের জন্য ধন্যবাদ: ডি

— অ্যালেক্স

Answer 2

সংক্ষিপ্ত উত্তরটি: কোথাও নেই।

এটি অতীতের একটি নিদর্শন, যেখানে মাইক্রোসফ্ট ডেভেলপারদের অ্যাপ্লিকেশন এক্সসেপশন থেকে তাদের সমস্ত কাস্টম ব্যতিক্রম উত্তরাধিকারী করার উদ্দেশ্যে নিয়েছিল। খুব শীঘ্রই, তারা তাদের মতামত পরিবর্তন করেছিল এবং পরামর্শ দিয়েছিল যে কাস্টম ব্যতিক্রমগুলি বেস ব্যতিক্রম শ্রেণীর থেকে নেওয়া উচিত। এমএসডিএন-এ ব্যতিক্রমগুলি পরিচালনা করার জন্য সেরা অভ্যাসগুলি দেখুন ।

এর আরও বহুল প্রচারিত কারণগুলির মধ্যে একটি ফ্রেমওয়ার্ক ডিজাইনের গাইডলাইনসের জেফারি রিখটারের একটি উত্স থেকে এসেছে :

সিস্টেম.এপ্লিকেশনএক্সেপশন একটি শ্রেণি যা। নেট ফ্রেমওয়ার্কের অংশ হওয়া উচিত নয়। আসল ধারণাটি ছিল যে সিস্টেমএক্সেপশন থেকে প্রাপ্ত ক্লাসগুলি সিএলআর (বা সিস্টেম) থেকে নিজেকে ফেলে দেওয়া ব্যতিক্রমগুলি নির্দেশ করবে, অন্যদিকে সিএলআর ব্যতিক্রমগুলি অ্যাপ্লিকেশন এক্সসেপশন থেকে নেওয়া হবে । যাইহোক, প্রচুর ব্যতিক্রম শ্রেণি এই প্যাটার্নটি অনুসরণ করে নি। উদাহরণস্বরূপ, টার্গেটইনভোকেশনএক্সসেপশন (যা সিএলআর দ্বারা নিক্ষেপ করা হয়) অ্যাপ্লিকেশন এক্সসেপশন থেকে প্রাপ্ত । সুতরাং, অ্যাপ্লিকেশনএক্সেপশন ক্লাসটি সমস্ত অর্থ হারিয়েছে। এই বেস শ্রেণি থেকে প্রাপ্ত কারণ হ'ল কিছু কোড উচ্চ স্তরের কল স্ট্যাককে বেস বর্গটি ধরতে দেওয়া। সমস্ত অ্যাপ্লিকেশন ব্যতিক্রম ধরা এখন আর সম্ভব ছিল না।

তাই সেখানে যদি আপনি এটি আছে। নির্বাহী সারসংক্ষেপ যে ApplicationException নয় ক্ষতিকর , শুধু বেহুদা ।

Comments

কেউ কেন জানেন কেন ? দেখে মনে হচ্ছে এটি বোধগম্য হয় যাতে আপনি অ্যাপ ব্যতিক্রমগুলি প্রদর্শন করতে পারেন তবে "প্রোগ্রামার স্ক্রুযুক্ত" ব্যতিক্রমগুলি না not

— জোশ কোডরফ

বিটিডাব্লু, এই ব্যাখ্যা থেকে মনে হয় এটি প্রতি সেজে কোনও খারাপ নকশা নয় তবে এমএসএফটি বাস্তবায়নকে ত্রুটিযুক্ত করেছে। অন্য কেউ কি একইভাবে পড়েন?

— জোশ কোডরফ

@ জোশকোডরফ: আমি মনে করি যে সমস্যাটি হ'ল যদি অ্যাপ্লিকেশন Whizbangসিদ্ধান্ত নেয় যে এটি কিছু সাধারণ শ্রেণিবদ্ধের অধীনে তার সমস্ত ব্যতিক্রম পেতে চায়, ApplicationExceptionসেই উদ্দেশ্যে ব্যবহার করে একটি কাস্টম WhizbangExceptionবেস শ্রেণি ব্যবহারের পক্ষে সত্যিকার অর্থে কোনও সুবিধা দেওয়া সম্ভব হবে না । নেট এর ব্যতিক্রম শ্রেণিবদ্ধের ক্ষেত্রে আরও গুরুতর সমস্যা ApplicationExceptionযদিও নেই, তবে ব্যতিক্রমগুলি সম্ভবত প্রয়োগ-মারাত্মক, সম্ভবত থ্রেড-মারাত্মক এবং স্থানীয়-সমস্যা সম্পর্কিত বিভাগে পৃথকীকরণের ব্যর্থতার সাথে অক্ষমতার পাশাপাশি রয়েছে ability অর্থবহ "যৌগিক" ব্যতিক্রম।

— সুপারক্যাট

@ জোশকোডরফ: সঠিকভাবে নকশাকৃত ব্যতিক্রম কাঠামোয়, আইএমএইচও, যদি finallyঅন্য কোনও ব্যতিক্রম মুলতুবি থাকা অবস্থায় ব্লকের সময় কোনও ব্যতিক্রম ছুঁড়ে ফেলা হয়, তবে যদি কোনও নেস্টেড ব্যতিক্রম catchমেলে তবে কল স্ট্যাকটি ব্লক করা উচিত , তবে অন্যান্য ব্যতিক্রমগুলি মুলতুবি রেখে দিন যাতে প্রস্থান একটি ব্লক অন্য এগিয়ে যাবে একই মধ্যে ব্লক ব্লক (যদি থাকে উপযুক্ত ছিল), এবং একটি থেকে প্রস্থান মুলতুবী পরবর্তী বাইরের ঝাঁপ হবে কোনো ব্যতিক্রম ব্লক বা । catchcatchtryfinallycatchfinally

— সুপারক্যাট

@ জোশকড্রফ আরও একটি জিনিস রয়েছে যা আমি অবাক করে দিয়েছি যাতে বেশি মনোযোগ না আসে। "অ্যাপ্লিকেশন" আসলে কী? তৃতীয় পক্ষের গ্রন্থাগারগুলি সম্পর্কে কী ? যেহেতু এগুলি। নেট ফ্রেমওয়ার্কের অংশ নয়, এগুলি মূল নির্দেশিকা অনুসারে অ্যাপ্লিকেশন এক্সেসসেপশন থেকে উত্তরাধিকার সূত্রে প্রাপ্ত হওয়া উচিত। এখন আপনি যখন নিজের অ্যাপ্লিকেশনটিতে সেই লাইব্রেরিটি ব্যবহার করেন এবং আপনার নিজের অ্যাপ্লিকেশন ব্যতিক্রমগুলিও তৈরি করেন, আপনি তার ভিত্তিতে লাইব্রেরির ব্যতিক্রম থেকে আর আপনার নিজের ব্যতিক্রমগুলি চিনতে পারবেন না। সুতরাং এটি অকেজো। পরিবর্তে, সুপারক্যাট বর্ণিত হিসাবে প্রতিটি উপাদান কেবল তাদের নিজস্ব ব্যতিক্রম বেস প্রকারটি সংজ্ঞায়িত করা উচিত।

— ওসকার বার্গগ্রেন

Answer 3

.NET 1.0 এ প্রাথমিক নকশায়, এটি পরিকল্পনা করা হয়েছিল যে কাঠামোটি নিজেই নিক্ষেপ করবে SystemExceptionএবং উত্পন্ন হবে; যখন ব্যবহারকারী অ্যাপ্লিকেশনগুলি - ছোঁড়াবে ApplicationExceptionএবং উত্পন্ন হবে।

তবে পরে। নেট 2.0 এ তা বাদ দেওয়া হয়েছিল that

এইভাবে থেকে প্রাপ্ত Exception।