সেরা অনুশীলন: বৈশিষ্ট্য থেকে ব্যতিক্রম ছোঁড়া

Question

সম্পত্তি প্রাপ্তি বা সেটারের মধ্যে থেকে কখন ব্যতিক্রম ছুঁড়ে ফেলা উপযুক্ত? কখন এটি উপযুক্ত নয়? কেন? বিষয়টিতে বাহ্যিক নথিগুলির লিঙ্কগুলি সহায়ক হবে ... গুগল আশ্চর্যরকমভাবে সামান্য পরিণত হয়েছিল।

Comments

আরও দেখুন: স্ট্যাকওভারফ্লো.com

— জন বি

এছাড়াও সম্পর্কিত: স্ট্যাকওভারফ্লো

— ব্রায়ান রাসমুসেন

আমি এই দুটি প্রশ্নই পড়েছি, তবে এই প্রশ্নের সম্পূর্ণ উত্তর দেয়নি আইএমও।

— জন সেগেল

যখনই প্রয়োজন. পূর্ববর্তী প্রশ্ন এবং উত্তর উভয়ই দেখায় যে এটির অনুমতিদাতা এবং গেটর বা সেটটার থেকে ব্যতিক্রম উত্থাপন করার জন্য প্রশংসা করেছে, যাতে আপনি "স্মার্ট হতে" সহজ হন।

— লেক্স লি

Answer 1

মাইক্রোসফ্টের http://msdn.microsoft.com/en-us/library/ms229006.aspx এ কীভাবে বৈশিষ্ট্যগুলি ডিজাইন করা যায় সে সম্পর্কে তার প্রস্তাবনা রয়েছে

মূলত, তারা প্রস্তাব দেয় যে সম্পত্তি প্রাপ্তারা হালকা ওজনের অ্যাক্সেসর হতে হবে যা কল করা সর্বদা নিরাপদ। যদি ব্যতিক্রমগুলি আপনার ছুঁড়ে ফেলার দরকার হয় তবে তারা পুনরায় ডিজাইনিং গেটারদেরকে পদ্ধতি হিসাবে প্রস্তাব দেয়। সেটারদের জন্য তারা নির্দেশ করে যে ব্যতিক্রমগুলি উপযুক্ত এবং গ্রহণযোগ্য ত্রুটি পরিচালনার কৌশল।

সূচকদের জন্য, মাইক্রোসফ্ট ইঙ্গিত দেয় যে এটি প্রাপ্তি এবং সেটটার উভয়েরই ব্যতিক্রম ছুঁড়ে ফেলার জন্য গ্রহণযোগ্য। এবং প্রকৃতপক্ষে। নেট গ্রন্থাগারের অনেক সূচক এটি করে। সর্বাধিক সাধারণ ব্যতিক্রম হচ্ছে ArgumentOutOfRangeException।

সম্পত্তি অর্জনকারীদের ব্যতিক্রম আপনি ছুঁড়ে ফেলতে চান না এমন কয়েকটি বেশ কয়েকটি ভাল কারণ রয়েছে:

• বৈশিষ্ট্যগুলি ক্ষেত্র হিসাবে "উপস্থিত" হওয়ার কারণে এটি সর্বদা স্পষ্ট হয় না যে তারা (বাই-ডিজাইন) ব্যতিক্রম ছুঁড়ে ফেলতে পারে; যদিও পদ্ধতিগুলির সাথে প্রোগ্রামাররা ব্যতিক্রমগুলি পদ্ধতিটি আহ্বান করার প্রত্যাশিত পরিণতি কিনা তা প্রত্যাশা এবং তদন্ত করতে প্রশিক্ষিত হয়।
• গেটারগুলি প্রচুর .NET অবকাঠামো দ্বারা ব্যবহৃত হয়, যেমন সিরিয়ালাইজার এবং ডেটাবাইন্ডিং (উদাহরণস্বরূপ উইনফোর্ডস এবং ডাব্লুপিএফ এ) - এই জাতীয় প্রসঙ্গে ব্যতিক্রমগুলি মোকাবেলা করা দ্রুত সমস্যাযুক্ত হয়ে উঠতে পারে।
• প্রোপার্টি গেটরগুলি ডিবাগার দ্বারা স্বয়ংক্রিয়ভাবে মূল্যায়ন করা হয় যখন আপনি কোনও বিষয় দেখেন বা পরীক্ষা করেন। এখানে একটি ব্যতিক্রম বিভ্রান্তিকর হতে পারে এবং আপনার ডিবাগিং প্রচেষ্টা ধীর করে দিতে পারে। একই কারণে বৈশিষ্ট্যগুলিতে অন্যান্য ব্যয়বহুল ক্রিয়াকলাপগুলি (যেমন একটি ডাটাবেস অ্যাক্সেস করার জন্য) অনাকাঙ্ক্ষিত।
• শৃঙ্খলাবদ্ধ কনভেনশনে প্রায়শই বৈশিষ্ট্যগুলি ব্যবহৃত হয়: obj.PropA.AnotherProp.YetAnother- এই ধরণের সিনট্যাক্সের সাহায্যে ব্যতিক্রম ক্যাপ স্টেটমেন্টগুলি ইনজেক্ট করার সিদ্ধান্ত নিতে সমস্যা হয়।

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

Comments

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

— এরিক লিপার্ট

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

— পাভেল মিনায়েভ

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

— এল বুশকিন

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

— ঝাফ - বেন ডুগুইড

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

— এরিক লিপার্ট

Answer 2

সেটারগুলি থেকে ব্যতিক্রম ছোঁড়াতে কোনও ভুল নেই। সর্বোপরি, কোন প্রদত্ত সম্পত্তির জন্য মানটি বৈধ নয় তা বোঝানোর জন্য এর চেয়ে ভাল উপায় কী?

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

আমি জানি একটি ব্যতিক্রম আছে এবং এটি আসলে একটি বরং প্রধান এক: যে কোনও বস্তু বাস্তবায়ন করছে IDisposable। Disposeঅবৈধ অবস্থায় অবজেক্ট আনার উপায় হিসাবে নির্দিষ্টভাবে লক্ষ্যযুক্ত ObjectDisposedExceptionএবং সেই ক্ষেত্রে ব্যবহার করার জন্য একটি বিশেষ ব্যতিক্রম শ্রেণি রয়েছে । ObjectDisposedExceptionসম্পত্তি Disposeনিষ্পত্তির (এবং নিজেকে বাদ দিয়ে) কোনও শ্রেণীর সদস্যের কাছ থেকে ফেলে দেওয়া অবজেক্টটি নিষ্পত্তি হওয়ার পরে একেবারে স্বাভাবিক ।

Comments

ধন্যবাদ পাভেল এই উত্তরটি 'কেন' এর পরিবর্তে কেবল আবার উল্লেখ করার পরিবর্তে যায় যে সম্পত্তি থেকে কোনও ব্যতিক্রম ছুঁড়ে ফেলা ভাল ধারণা নয়।

— SolutionYogi

আমি এ ধারণাটি অপছন্দ করি যে একেবারে সমস্ত সদস্যকে একটি এর IDisposableপরে অকেজো করা উচিত Dispose। সদস্যকে আহ্বান জানাতে যদি এমন কোনও সংস্থান ব্যবহারের প্রয়োজন হয় যা Disposeঅনুপলব্ধ হয়ে উঠেছে (যেমন সদস্যটি কোনও প্রবাহ বন্ধ করা হয়েছে যা থেকে ডেটা পড়বে) ObjectDisposedExceptionসদস্যটিকে যেমন ফাঁস হওয়ার পরিবর্তে নিক্ষেপ করা উচিত ArgumentException, তবে যদি কারও সাথে এমন একটি বৈশিষ্ট্য রয়েছে যা প্রতিনিধিত্ব করে নির্দিষ্ট ক্ষেত্রের মানগুলি, প্রয়োজনের তুলনায় এই জাতীয় সম্পত্তিগুলি নিষ্পত্তির পরে পড়ার অনুমতি দেওয়া (শেষ ধরণের মানগুলি উপস্থাপন করা) অনেক বেশি সহায়ক বলে মনে হচ্ছে ...

— সুপারক্যাট

... Disposeএগুলি সমস্ত সম্পত্তি পড়ার আগে পর্যন্ত পিছিয়ে দেওয়া হবে। কিছু ক্ষেত্রে যেখানে একটি থ্রেড কোনও অবজেক্টে ব্লকিং রিডিং ব্যবহার করতে পারে যখন অন্যটি এটি বন্ধ করে দেয় এবং যেখানে ডেটা আগে যে কোনও সময় Disposeআসতে পারে Dispose, আগত ডেটাগুলি কেটে ফেলতে সহায়ক হতে পারে তবে আগের প্রাপ্ত ডেটাগুলি পড়ার অনুমতি দেয় allow কারওর মধ্যে Closeএবং Disposeএমন পরিস্থিতিতে কোনও কৃত্রিম পার্থক্য জোর করা উচিত নয় যেখানে অন্যথায় কারও অস্তিত্বের প্রয়োজন নেই।

— সুপারক্যাট

নিয়মের কারণ বোঝা আপনাকে নিয়মটি কখন ভাঙতে হবে তা জানতে দেয় (রেমন্ড চেন)। এই ক্ষেত্রে, আমরা দেখতে পাচ্ছি যে যদি কোনও প্রকারের অপরিবর্তনযোগ্য ত্রুটি থাকে তবে আপনাকে এটিকে গিটারে আড়াল করা উচিত নয়, কারণ এই জাতীয় ক্ষেত্রে অ্যাপ্লিকেশনটিকে ASAP ছাড়তে হবে।

— বেন

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

— পাভেল মিনায়েভ

Answer 3

এটি মোটামুটিভাবে কখনও কখনও উপযুক্ত হিসাবে পাওয়া যায় না এবং কখনও কখনও সেটারের জন্যও উপযুক্ত appropriate

এই ধরণের প্রশ্নের সর্বোত্তম উত্স হ'ল কোয়ালিনা এবং আব্রামের "ফ্রেমওয়ার্ক ডিজাইনের গাইডলাইনস"; এটি একটি সীমাবদ্ধ বই হিসাবে উপলভ্য এবং এর বড় অংশগুলি অনলাইনেও উপলব্ধ।

বিভাগ 5.2 থেকে: সম্পত্তি নকশা

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

মনে রাখবেন যে এই নির্দেশিকাটি কেবল সম্পত্তি প্রাপ্তদের ক্ষেত্রে প্রযোজ্য। কোনও সম্পত্তি সেটারে একটি ব্যতিক্রম ছুঁড়ে ফেলা ঠিক।

Comments

যদিও (সাধারণভাবে) আমি এই ধরণের নির্দেশিকাগুলির সাথে একমত, এগুলি কেন অনুসরণ করা উচিত - এবং তাদের উপেক্ষা করা হলে কী ধরণের পরিণতি ঘটতে পারে সে সম্পর্কে কিছু অতিরিক্ত অন্তর্দৃষ্টি প্রদান করা কার্যকর বলে মনে হয়।

— এল বুশকিন

এটি ডিসপোজেবল বস্তুগুলির সাথে কীভাবে সম্পর্কিত এবং সেই নির্দেশিকা যা আপনার ObjectDisposedExceptionঅবজেক্টটি একবার ডাকার পরে নিক্ষেপ করার কথা বিবেচনা করবে Dispose()এবং পরবর্তীকালে কোনও সম্পত্তির মান জিজ্ঞাসা করবে? দেখে মনে হচ্ছে দিকনির্দেশটি "সম্পত্তি প্রাপ্তদের থেকে ব্যতিক্রম ছোঁড়া এড়াতে হবে, যদি না অবজেক্টটি নিষ্পত্তি না করা হয় তবে কোন ক্ষেত্রে আপনি অবজেক্টডিসপোজড এক্সেকপশন নিক্ষেপ করার বিষয়টি বিবেচনা করা উচিত"।

— স্কট ডরম্যান

নকশা হ'ল বিবাদী প্রয়োজনীয়তার মুখে যুক্তিসঙ্গত আপসগুলি সন্ধান করার শিল্প ও বিজ্ঞান। যে কোনও উপায়ে যুক্তিসঙ্গত আপস বলে মনে হচ্ছে; কোনও সম্পত্তির উপর নিষ্পত্তিযোগ্য বস্তু নিক্ষেপ করে আমি অবাক হই না; না হলে আমি অবাক হব না। যেহেতু কোনও নিষ্পত্তিযোগ্য অবজেক্ট ব্যবহার করা একটি ভয়ানক প্রোগ্রামিং অনুশীলন, তাই এর কোন প্রত্যাশা থাকা বুদ্ধিমানের কাজ হবে না।

— এরিক লিপার্ট

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

— ট্র্যাপ

Answer 4

ব্যতিক্রমগুলির একটি দুর্দান্ত উপায় হ'ল এটিকে নিজের এবং অন্যান্য বিকাশকারীদের নীচের মত কোড নথিতে ব্যবহার করুন:

ব্যতিক্রম ব্যতিক্রমী প্রোগ্রামের রাজ্যের ক্ষেত্রে হওয়া উচিত। এর অর্থ এটি যেখানে খুশি লিখতে ভাল!

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

এগুলি একটি সাবসিস্টেম / পদ্ধতি / যাই হোক না কেন অনুমান এবং গণ্ডিগুলি ডকুমেন্ট করার একটি উপায়। সাধারণ ক্ষেত্রে এগুলি ধরা উচিত নয়! এটি এ কারণেইও হয় যে এগুলি কখনই ছুঁড়ে ফেলা হয় না যদি সিস্টেমটি প্রত্যাশিতভাবে একসাথে কাজ করে: যদি কোনও ব্যতিক্রম ঘটে তা দেখায় যে কোডের কোনও অংশের অনুমানগুলি পূরণ হয় নি - যেমন এটি চারপাশের বিশ্বের সাথে যোগাযোগ করছে না এটি মূলত ছিল আপনি যদি এই লক্ষ্যে লেখা একটি ব্যতিক্রম ধরা পড়েন তবে এর অর্থ সম্ভবত সিস্টেমটি একটি অনির্দেশীয় / অসঙ্গত অবস্থায় প্রবেশ করেছে - এটি শেষ পর্যন্ত ডেটা বা অনুরূপের ক্রাশ বা দুর্নীতিতে ডেকে আনতে পারে যা সনাক্ত / ডিবাগ করা খুব কঠিন হতে পারে।

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

এই নিয়মের ব্যতিক্রম (হা হা!) আইও এর মতো জিনিস যেখানে ব্যতিক্রমগুলি আপনার নিয়ন্ত্রণে থাকে না এবং আগাম পরীক্ষা করা যায় না।

Comments

এই বৈধ এবং প্রাসঙ্গিক উত্তরটি কীভাবে নিম্নচাপে উঠল? স্ট্যাক ওভারফ্লোতে কোনও রাজনীতি হওয়া উচিত নয় এবং যদি এই উত্তরটি বুলসায়কে মিস করে বলে মনে হয় তবে সেই প্রভাবটিতে একটি মন্তব্য যুক্ত করুন। ডাউনভোটিং এমন উত্তরগুলির জন্য যা অপ্রাসঙ্গিক বা ভুল।

— বিতর্ককারী

Answer 5

এটি সমস্ত এমএসডিএন-তে নথিভুক্ত করা হয়েছে (অন্যান্য উত্তরের সাথে যুক্ত হিসাবে) তবে এখানে থাম্বের একটি সাধারণ নিয়ম ...

সেটারে, আপনার সম্পত্তিটি উপরে এবং প্রকারের বাইরে বৈধ হওয়া উচিত। উদাহরণস্বরূপ, ফোননম্বার নামে পরিচিত কোনও সংস্থার সম্ভবত রেজেক্স বৈধতা থাকা উচিত এবং ফর্ম্যাটটি বৈধ না হলে একটি ত্রুটি ছুঁড়ে ফেলা উচিত।

প্রাপ্তদের জন্য, সম্ভবত যখন মানটি শূন্য থাকে তবে সম্ভবত কলিং কোডটি (ডিজাইনের নির্দেশিকা অনুসারে) আপনি হ্যান্ডেল করতে চান এমন সম্ভবত।

Answer 6

এমএসডিএন: স্ট্যান্ডার্ড ব্যাতিক্রমের ধরণগুলি ছোঁড়াচ্ছে

http://msdn.microsoft.com/en-us/library/ms229007.aspx

Answer 7

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

"দেরি বাইন্ডিং" এর অর্থ বৈশিষ্ট্যগুলি প্রতিবিম্বের মাধ্যমে পাওয়া যায়। উদাহরণস্বরূপ সিরিয়ালাইজেবল "অ্যাট্রিবিউটটি কোনও বস্তুর বৈশিষ্ট্যগুলির মাধ্যমে সিরিয়ালাইজ / ডিজাইরিয়ালাইজ করার জন্য ব্যবহৃত হয় this এই ধরণের পরিস্থিতিতে একটি ব্যতিক্রম নিক্ষেপ করা জিনিসকে একটি বিপর্যয়কর উপায়ে ভেঙে দেয় এবং আরও দৃ .় কোড তৈরি করতে ব্যতিক্রম ব্যবহার করার ভাল উপায় নয়।

"প্রারম্ভিক বাঁধাই" এর অর্থ একটি সংকলক কর্তৃক কোনও সম্পত্তি ব্যবহার কোডে আবদ্ধ। উদাহরণস্বরূপ, যখন আপনার লেখা কিছু কোড কোনও সম্পত্তি গেটারের রেফারেন্স দেয়। এই ক্ষেত্রে ব্যতিক্রমগুলি বোঝার পরে তা ছুঁড়ে ফেলা ঠিক হবে।

অভ্যন্তরীণ বৈশিষ্ট্যযুক্ত কোনও অবজেক্টের সেই বৈশিষ্ট্যগুলির মানগুলির দ্বারা নির্ধারিত একটি রাষ্ট্র থাকে। বৈশিষ্ট্যগুলি প্রকাশ করে এমন বৈশিষ্ট্য যা অবজেক্টের অভ্যন্তরীণ অবস্থার প্রতি সচেতন এবং সংবেদনশীল তারা দেরীতে বাইন্ডিংয়ের জন্য ব্যবহার করা উচিত নয়। উদাহরণস্বরূপ, আসুন আমরা বলতে পারি যে আপনার কাছে এমন একটি অবজেক্ট রয়েছে যা অবশ্যই খোলা হবে, অ্যাক্সেস করতে হবে, তারপরে বন্ধ হবে। এক্ষেত্রে প্রথমে ওপেন না করে संपत्तीগুলি অ্যাক্সেস করার ব্যতিক্রম হওয়া উচিত। মনে করুন, এই ক্ষেত্রে, আমরা একটি ব্যতিক্রম ছুঁড়ে না ফেলেছি এবং আমরা কোনও ব্যতিক্রম ছুঁড়ে না দিয়ে কোডটিকে কোনও মান অ্যাক্সেসের অনুমতি দিই? কোডটি বুদ্ধিমানের মতো কোনও গেটারের কাছ থেকে একটি মান পেয়েছে যদিও তা খুশি মনে হবে। এখন আমরা কোডটি এমন একটি খারাপ অবস্থার মধ্যে রেখেছি যেহেতু এটি একটি খারাপ পরিস্থিতিতে called এর অর্থ কোডটি যাচাই করার জন্য অবশ্যই সম্পত্তি গেটারের কাছ থেকে পাওয়া মূল্য সম্পর্কে অনুমান করা উচিত। এভাবেই খারাপ কোড লেখা হয়।

Answer 8

আমার এই কোডটি ছিল যেখানে আমার কোন ব্যতিক্রম নিক্ষেপ করার বিষয়ে অনিশ্চিত ছিল।

public Person
{
    public string Name { get; set; }
    public boolean HasPets { get; set; }
}

public void Foo(Person person)
{
    if (person.Name == null) {
        throw new Exception("Name of person is null.");
        // I was unsure of which exception to throw here.
    }

    Console.WriteLine("Name is: " + person.Name);
}

আমি মডেলটিকে নির্মাণকারীর পক্ষে যুক্তি হিসাবে জোর করে প্রথম স্থানে সম্পত্তি বাতিল হতে বাধা দিয়েছিলাম।

public Person
{
    public Person(string name)
    {
        if (name == null) {
            throw new ArgumentNullException(nameof(name));
        }
        Name = name;
    }

    public string Name { get; private set; }
    public boolean HasPets { get; set; }
}

public void Foo(Person person)
{
    Console.WriteLine("Name is: " + person.Name);
}