গতকাল আমি সহকর্মীর সাথে উত্তপ্ত বিতর্ক করে যাচ্ছিলাম পছন্দের ত্রুটি প্রতিবেদন করার পদ্ধতিটি কী হবে on মূলত আমরা অ্যাপ্লিকেশন স্তর বা মডিউলগুলির মধ্যে ত্রুটিগুলি রিপোর্ট করার জন্য ব্যতিক্রম বা ত্রুটি কোডের ব্যবহার নিয়ে আলোচনা করছিলাম।
যদি আপনি ব্যতিক্রম নিক্ষেপ করেন বা ত্রুটি প্রতিবেদনের জন্য ত্রুটি কোডগুলি ফেরত দেন তবে সিদ্ধান্ত নিতে আপনি কোন বিধিগুলি ব্যবহার করেন?
উত্তর:
উচ্চ-স্তরের স্টাফগুলিতে, ব্যতিক্রম; নিম্ন স্তরের স্টাফ, ত্রুটি কোডগুলিতে।
একটি ব্যতিক্রমের ডিফল্ট আচরণ হ'ল স্ট্যাকটি খুলে ফেলা এবং প্রোগ্রামটি বন্ধ করা, যদি আমি কোনও স্ক্রিপ্ট লিখছি এবং আমি এমন একটি কীটির জন্য যাচ্ছি যা অভিধানে নেই এটি সম্ভবত একটি ত্রুটি, এবং আমি প্রোগ্রামটি থামিয়ে দিয়ে আমাকে যেতে দিতে চাই সব সম্পর্কে জানি।
তবে, আমি যদি কোনও কোডের টুকরো লিখছি যা অবশ্যই প্রতিটি সম্ভাব্য পরিস্থিতিতে আমার আচরণ সম্পর্কে জানতে হবে , তবে আমি ত্রুটি কোডগুলি চাই। অন্যথায় আমাকে কী করতে হবে তা জানার জন্য আমার ফাংশনটিতে প্রতিটি লাইন দ্বারা ছুঁড়ে দেওয়া যায় এমন প্রতিটি ব্যতিক্রম জানতে হবে (এটি কতটা ছদ্মবেশী তা সম্পর্কে ধারণা পেতে একটি এয়ারলাইন গ্রাউন্ডড একটি ব্যতিক্রম পড়ুন )। কোডটি লেখা কষ্টকর এবং কঠিন যা প্রতিটি পরিস্থিতিতে যথাযথভাবে প্রতিক্রিয়া জানায় (অসন্তুষ্ট ব্যক্তিরা সহ), তবে এটি ত্রুটিমুক্ত কোড লেখার জন্য কষ্টকর এবং কঠোর কারণ আপনি ত্রুটি কোডগুলি পাস করছেন না।
রেমন্ড চেন এবং জোয়েল উভয়ই ব্যতিক্রমী কিছু বাদ দিয়ে কিছু বিতর্ক করেছেন।
nodiscardবৈশিষ্ট্যটির সাথে পরিচয় করিয়ে দেয় যা কোনও ফাংশনের রিটার্ন মান সংরক্ষণ না করা হলে একটি সংকলক সতর্কতা দেয়। ভুলে যাওয়া ত্রুটি কোড চেক করতে কিছুটা সহায়তা করে। উদাহরণ: Godbolt.org/g/6i6E0B
আমি সাধারণত ব্যতিক্রমগুলি পছন্দ করি, কারণ তাদের কাছে আরও প্রাসঙ্গিক তথ্য রয়েছে এবং প্রোগ্রামারকে ত্রুটিটি আরও পরিষ্কার ফ্যাশনে জানাতে পারে।
অন্যদিকে, ত্রুটি কোডগুলি ব্যতিক্রমগুলির চেয়ে বেশি হালকা তবে এটি বজায় রাখা শক্ত। ত্রুটি পরীক্ষা করার সময় অজান্তেই বাদ দেওয়া যেতে পারে। ত্রুটি কোডগুলি বজায় রাখা শক্ত কারণ আপনাকে সমস্ত ত্রুটি কোড সহ একটি ক্যাটালগ রাখতে হবে এবং তারপরে কোন ত্রুটি নিক্ষেপ করা হয়েছিল তা দেখতে ফলাফলটি স্যুইচ করতে হবে। ত্রুটি ব্যাপ্তিগুলি এখানে সহায়ক হতে পারে, কারণ আমরা যদি আগ্রহী একমাত্র জিনিসটি যদি আমরা ত্রুটির উপস্থিতিতে থাকি বা না থাকি তবে এটি পরীক্ষা করা সহজ eg উদাহরণস্বরূপ, এইচআরসিলেট ত্রুটি কোডটি বৃহত্তর বা 0 সমান সাফল্য এবং শূন্যের চেয়ে কম ব্যর্থতা)। এগুলি অজান্তেই বাদ দেওয়া যেতে পারে কারণ এমন কোনও প্রোগ্রামিক জোর করে নেই যে বিকাশকারী ত্রুটি কোডগুলি যাচাই করবে। অন্যদিকে, আপনি ব্যতিক্রম উপেক্ষা করতে পারবেন না।
সংক্ষিপ্তসার হিসাবে আমি প্রায় সমস্ত পরিস্থিতিতে ত্রুটি কোডের চেয়ে ব্যতিক্রম পছন্দ করি।
আমি ব্যতিক্রম পছন্দ করি কারণ
goto
ত্রুটি কোডগুলি ব্যতিক্রম, এটি সম্পর্কে কোনও সন্দেহ নেই। আপনি ত্রুটি কোডগুলি যেমন করেন তেমনি ব্যতিক্রমগুলি থেকে অনেকগুলি একই সুবিধা পান তবে ত্রুটি কোডের ত্রুটিগুলি ছাড়াই আরও অনেক কিছু। ব্যতিক্রমগুলির মধ্যে একমাত্র নক হ'ল এটি সামান্য বেশি ওভারহেড; তবে এই দিন এবং যুগে, ওভারহেডটি প্রায় সমস্ত অ্যাপ্লিকেশনের জন্য নগণ্য বলে বিবেচিত হওয়া উচিত।
দুটি কৌশল নিয়ে আলোচনা, তুলনা এবং বিপরীতে কিছু নিবন্ধ এখানে দেওয়া হল:
সেগুলিতে কয়েকটি ভাল লিঙ্ক রয়েছে যা আপনাকে আরও পড়তে পারে।
আমি দুটি মডেলকে কখনই মিশ্রিত করব না ... আপনি স্ট্যাকের যে এক অংশ থেকে ত্রুটি কোডগুলি ব্যবহার করছেন এটির একটি অংশ থেকে ব্যতিক্রমগুলি ব্যবহার করে এমন একটি উচ্চতর টুকরোতে স্থানান্তরিত করা খুব শক্ত।
ব্যতিক্রমগুলি হ'ল "যে কোনও কিছু যা পদ্ধতি বা সাব্রোটিনকে আপনি যা করতে বলেছেন তা করতে বাধা দেয়" এর জন্য ... ... অনিয়ম বা অস্বাভাবিক পরিস্থিতি, বা সিস্টেমের অবস্থা ইত্যাদির বিষয়ে বার্তা প্রেরণ না করা ইত্যাদি রিটার্ন মান বা রেফ ব্যবহার করুন (বা আউট) এর জন্য পরামিতি।
ব্যতিক্রমগুলি পদ্ধতিটির ফাংশনের উপর নির্ভরশীল শব্দার্থসমূহের সাথে পদ্ধতিগুলি লেখার (এবং ব্যবহারযোগ্য) মঞ্জুরি দেয়, অর্থাত কোনও কর্মচারী বস্তু বা কর্মচারীদের তালিকা ফিরিয়ে দেয় এমন একটি পদ্ধতি কেবল এটি করতে টাইপ করা যেতে পারে, এবং আপনি কল করে এটি ব্যবহার করতে পারবেন।
Employee EmpOfMonth = GetEmployeeOfTheMonth();
ত্রুটি কোডগুলি সহ, সমস্ত পদ্ধতি একটি ত্রুটি কোড ফেরত দেয়, সুতরাং, কলিং কোডটি ব্যবহার করার জন্য যাদের অন্য কোনও কিছু ফেরত নেওয়া দরকার তাদের জন্য আপনাকে সেই ডেটা দিয়ে পপুলেশন করার জন্য একটি রেফারেন্স ভেরিয়েবল পাস করতে হবে এবং এর জন্য ফেরতের মান পরীক্ষা করতে হবে ত্রুটি কোড, এবং এটি প্রতিটি ফাংশন বা পদ্ধতি কল এ হ্যান্ডেল করুন।
Employee EmpOfMonth;
if (getEmployeeOfTheMonth(ref EmpOfMonth) == ERROR)
// code to Handle the error here
যদি আপনি কোড করেন যাতে প্রতিটি পদ্ধতি একটি এবং কেবল একটি সাধারণ কাজ করে, তবে যখনই পদ্ধতিটি পদ্ধতিটির পছন্দসই উদ্দেশ্য অর্জন করতে পারে না তখন আপনাকে ব্যতিক্রম করা উচিত। ব্যতিক্রমগুলি ত্রুটি কোডগুলির চেয়ে এই পদ্ধতিতে ব্যবহার করা আরও সমৃদ্ধ এবং সহজ। আপনার কোডটি অনেক পরিচ্ছন্ন - "স্বাভাবিক" কোড পথের স্ট্যান্ডার্ড প্রবাহটি সেই ক্ষেত্রে কঠোরভাবে উত্সর্গ করা যেতে পারে যেখানে পদ্ধতিটি আপনি এটি করতে চেয়েছিলেন তা সম্পাদন করতে সক্ষম হয়েছে ... এবং তারপরে কোডটি পরিষ্কার করতে, বা পরিচালনা করতে হবে "ব্যতিক্রমী" পরিস্থিতিতে যখন কোনও খারাপ কিছু ঘটে যা পদ্ধতিটিকে সফলভাবে শেষ করতে বাধা দেয় তখন সাধারণ কোড থেকে দূরে সই করা যায়। অতিরিক্ত হিসাবে, যদি আপনি যেখানে ব্যতিক্রম ঘটেছিল তা হ্যান্ডেল করতে না পারেন এবং অবশ্যই এটি অবশ্যই একটি ইউআইতে স্ট্যাকটি দিয়ে দিতে হবে, (বা আরও খারাপভাবে, মাঝারি স্তরের উপাদান থেকে একটি ইউআইতে তারের পেরিয়ে), তবে ব্যতিক্রম মডেল সহ,
অতীতে আমি ত্রুটি কোডের শিবিরে যোগদান করেছি (খুব বেশি সি প্রোগ্রামিং করেছি)। তবে এখন আমি আলো দেখেছি।
হ্যাঁ ব্যতিক্রমগুলি সিস্টেমে কিছুটা বোঝা। তবে তারা কোডটি সরল করে ত্রুটির সংখ্যা হ্রাস করে (এবং ডাব্লুটিএফ এর)।
সুতরাং ব্যতিক্রম ব্যবহার করুন তবে তাদের জ্ঞানী ব্যবহার করুন। এবং তারা আপনার বন্ধু হবে।
পার্শ্ব নোট হিসাবে। কোন পদ্ধতি থেকে কোন ব্যতিক্রম ছুঁড়ে ফেলা যায় তা নথিভুক্ত করতে শিখেছি। দুর্ভাগ্যক্রমে এটি বেশিরভাগ ভাষায় প্রয়োজন হয় না। তবে এটি সঠিক স্তরে সঠিক ব্যতিক্রমগুলি পরিচালনা করার সুযোগ বাড়ে।
কয়েকটি পরিস্থিতি থাকতে পারে যেখানে একটি পরিষ্কার, পরিষ্কার, সঠিক উপায়ে ব্যতিক্রমগুলি ব্যবহার করা জটিল, তবে ব্যতিক্রম সময়ের বেশিরভাগ অংশই সুস্পষ্ট পছন্দ। ত্রুটি কোডগুলির ওপরে হ'ল সবচেয়ে বড় সুবিধা ব্যতিক্রম হ্যান্ডলিংটি হ'ল এটি কার্যকর করার প্রবাহকে বদলে দেয় যা দুটি কারণে গুরুত্বপূর্ণ।
যখন কোনও ব্যতিক্রম ঘটে, অ্যাপ্লিকেশনটি আর এটি 'স্বাভাবিক' সম্পাদনের পথে অনুসরণ করে না। এটি এত গুরুত্বপূর্ণ হওয়ার প্রথম কারণটি হ'ল কোডটির লেখক যদি ভাল এবং সত্যই তাদের খারাপ দিক থেকে বের না হন তবে প্রোগ্রামটি থামবে এবং অনির্দেশ্য জিনিসগুলি চালিয়ে যাওয়া হবে না। যদি কোনও ত্রুটি কোডটি যাচাই না করা হয় এবং কোনও ত্রুটিযুক্ত কোডের প্রতিক্রিয়ায় যথাযথ পদক্ষেপ নেওয়া না হয় তবে প্রোগ্রামটি এটি করছে যা চালিয়ে যাবে এবং কে জানবে যে সেই ক্রিয়াকলাপের ফলাফল কী হবে। এমন অনেকগুলি পরিস্থিতি রয়েছে যেখানে প্রোগ্রামটি 'যাই হোক না কেন' করায় খুব ব্যয়বহুল হয়ে যায়। এমন একটি প্রোগ্রাম বিবেচনা করুন যা কোনও সংস্থা বিক্রয় করে বিভিন্ন আর্থিক উপকরণের জন্য পারফরম্যান্সের তথ্য পুনরুদ্ধার করে এবং দালাল / পাইকারদের কাছে সেই তথ্য সরবরাহ করে। যদি কিছু ভুল হয়ে যায় এবং প্রোগ্রামটি চলতে থাকে, এটি দালাল এবং পাইকারদের ভ্রান্ত কর্মক্ষমতা ডেটা পাঠাতে পারে। আমি অন্য কারও সম্পর্কে জানি না, তবে আমার কোড কেন কোম্পানিকে নিয়ন্ত্রক জরিমানার জন্য--পরিসংখ্যান পেয়েছে তা ব্যাখ্যা করে কোন ভিপি অফিসে বসে থাকতে চাই না। গ্রাহকদের একটি ত্রুটি বার্তা সরবরাহ করা সাধারণত 'সত্য' বলে মনে হতে পারে এমন ভুল ডেটা পৌঁছে দেওয়ার চেয়ে পছন্দনীয়, এবং পরবর্তী পরিস্থিতি ত্রুটি কোডের মতো অনেক কম আক্রমণাত্মক পদ্ধতির সাথে চালানো খুব সহজ easier
আমি কেন ব্যতিক্রম পছন্দ করি এবং তাদের সাধারণ সম্পাদন ভাঙার দ্বিতীয় কারণ হ'ল এটি 'সাধারণ বিষয়গুলি ঘটছে' যুক্তিটিকে 'কিছু ভুল হয়ে গেছে' থেকে আলাদা করে রাখা অনেক সহজ করে তোলে। আমার কাছে এটি:
try {
// Normal things are happening logic
catch (// A problem) {
// Something went wrong logic
}
... এটি এর চেয়ে ভাল:
// Some normal stuff logic
if (errorCode means error) {
// Some stuff went wrong logic
}
// Some normal stuff logic
if (errorCode means error) {
// Some stuff went wrong logic
}
// Some normal stuff logic
if (errorCode means error) {
// Some stuff went wrong logic
}
ব্যতিক্রম সম্পর্কে অন্যান্য ছোট ছোট জিনিস রয়েছে যা খুব ভাল। কোনও কার্যক্রমে ডেকে আনা কোনও পদ্ধতিতে ত্রুটি কোডটি ফিরে এসেছে কিনা তা খতিয়ে রাখার জন্য শর্তাধীন যুক্তির একগুচ্ছ থাকা এবং সেই ত্রুটি কোডটি উচ্চতর করে ফিরিয়ে দেওয়া অনেকগুলি বয়লার প্লেট। আসলে, এটি অনেকগুলি বয়লার প্লেট যা ভুল হতে পারে। 'ফ্রেশ-আউট-অফ-কলেজ' ফ্রেড লিখেছিল যে-ইফ-অন্য-যদি-অন্য বক্তব্যগুলির ইঁদুরের বাসা করার চেয়ে বেশিরভাগ ভাষার ব্যতিক্রমী সিস্টেমে আমার অনেক বেশি বিশ্বাস আছে এবং আমার আরও অনেক ভাল কাজ করার আছে কোড পর্যালোচনার চেয়ে আমার সময়ের সাথে ইঁদুরের বাসা বলেছিল।
আপনার উভয় ব্যবহার করা উচিত। জিনিসটি প্রতিটি ব্যবহার করার সময় সিদ্ধান্ত নেওয়া হয় ।
একটা হয় কয়েক পরিস্থিতিতে যেখানে ব্যতিক্রম সুস্পষ্ট পছন্দ :
কিছু পরিস্থিতিতে আপনি ত্রুটি কোডটি দিয়ে কিছু করতে পারবেন না , এবং আপনার কেবল কল স্ট্যাকের একটি উচ্চ স্তরে এটি পরিচালনা করতে হবে , সাধারণত কেবল ত্রুটিটি লগ করুন, ব্যবহারকারীর কাছে কিছু প্রদর্শন করুন বা প্রোগ্রামটি বন্ধ করুন। এই ক্ষেত্রে, ত্রুটি কোডগুলির জন্য আপনাকে ত্রুটি কোডগুলি ম্যানুয়ালি স্তরের স্তরে স্তরের করতে হবে যা ব্যতিক্রমগুলির সাথে স্পষ্টতই করা সহজ। মুল বক্তব্যটি এটি অপ্রত্যাশিত এবং অবিচ্ছিন্ন পরিস্থিতিতে জন্য for
তবুও পরিস্থিতি 1 সম্পর্কে (যেখানে অপ্রত্যাশিত এবং অবিচ্ছিন্ন কিছু ঘটে যা আপনি কেবল এটি লগ করতে চান না), ব্যতিক্রমগুলি সহায়ক হতে পারে কারণ আপনি প্রাসঙ্গিক তথ্য যুক্ত করতে পারেন । উদাহরণস্বরূপ, যদি আমি আমার নিম্ন-স্তরের ডেটা সহায়কগুলিতে একটি SQL এ এক্সসেপশন পেয়ে থাকি তবে আমি ত্রুটিটি নিম্ন-স্তরে ধরতে চাই (যেখানে আমি এসকিউএল কমান্ড জানি যা ত্রুটির কারণ হয়েছিল) তাই আমি সেই তথ্যটি ক্যাপচার করতে পারি এবং অতিরিক্ত তথ্যের সাথে পুনর্বিবেচনা করতে পারি । দয়া করে এখানে যাদু শব্দটি নোট করুন: পুনর্বিবেচনা করুন এবং গিলে ফেলবেন না । ব্যতিক্রম হ্যান্ডলিংয়ের প্রথম নিয়ম: ব্যতিক্রমগুলি গ্রাস করবেন না । এছাড়াও, নোট করুন যে আমার অভ্যন্তরীণ ক্যাচটিতে কোনও লগ করার দরকার নেই কারণ বাইরের ক্যাচটিতে পুরো স্ট্যাকের চিহ্ন থাকবে এবং এটি লগ হতে পারে।
কিছু পরিস্থিতিতে আপনার কমান্ডগুলির একটি ক্রম থাকে এবং যদি সেগুলির মধ্যে কোনওটি ব্যর্থ হয় তবে আপনার সংস্থানগুলি (*) পরিষ্কার করা / নিষ্পত্তি করা উচিত , এটি একটি অপ্রাপ্তযোগ্য পরিস্থিতি (যা নিক্ষেপ করা উচিত) বা পুনরুদ্ধারযোগ্য পরিস্থিতি (যা ক্ষেত্রে আপনি করতে পারেন) স্থানীয়ভাবে বা কলার কোডে হ্যান্ডেল করুন তবে আপনার ব্যতিক্রমের দরকার নেই)। স্পষ্টতই প্রতিটি পদ্ধতির পরে ত্রুটি কোডগুলি পরীক্ষা করার পরিবর্তে এবং শেষ অবধি ক্লিনআপ / নিষ্পত্তি করার পরিবর্তে এই সমস্ত কমান্ডকে একক চেষ্টা করে রাখা আরও সহজ। দয়া করে নোট করুন যে আপনি যদি ত্রুটিটি বুদ্বুদ করতে চান (যা সম্ভবত আপনি চান) তবে আপনার এটি ধরারও দরকার নেই - আপনি কেবল পরিচ্ছন্নতা / নিষ্পত্তি করার জন্য শেষটি ব্যবহার করেন - আপনি চাইলে কেবল ক্যাচ / রেট্রো ব্যবহার করা উচিত প্রাসঙ্গিক তথ্য যুক্ত করতে (বুলেট ২ দেখুন)।
একটি উদাহরণ হ'ল লেনদেনের ব্লকের ভিতরে এসকিউএল স্টেটমেন্টের ক্রম হবে। আবার এটিও "অবিচ্ছিন্ন" পরিস্থিতি, এমনকি যদি আপনি তাড়াতাড়ি ধরার সিদ্ধান্ত নেন (শীর্ষে বুদবুদ করার পরিবর্তে স্থানীয়ভাবে এটি আচরণ করুন) এটি এখনও মারাত্মক পরিস্থিতি যেখানে সবচেয়ে ভাল ফলাফল হ'ল সবকিছু বাতিল করা বা কমপক্ষে একটি বৃহত্ গর্ভপাত বন্ধ করা where প্রক্রিয়া অংশ।
(*) এটি on error gotoপুরানো ভিজ্যুয়াল বেসিকের মতো
কনস্ট্রাক্টরগুলিতে আপনি কেবল ব্যতিক্রম ছুঁড়ে ফেলতে পারেন।
এটি বলার পরে, অন্যান্য সমস্ত পরিস্থিতিতে যেখানে আপনি কিছু তথ্য ফিরিয়ে দিচ্ছেন যার উপর কলকারীরা কিছু ব্যবস্থা নিতে পারে , রিটার্ন কোডগুলি ব্যবহার করা সম্ভবত একটি ভাল বিকল্প। এটিতে সমস্ত প্রত্যাশিত "ত্রুটি" অন্তর্ভুক্ত রয়েছে , কারণ সম্ভবত এগুলি তাত্ক্ষণিক কলার দ্বারা পরিচালিত হওয়া উচিত এবং স্ট্যাকের মধ্যে খুব বেশি স্তরের স্তূপিত হওয়া খুব কমই দরকার।
অবশ্যই প্রত্যাশিত ত্রুটিগুলি ব্যাতিক্রম হিসাবে গণ্য করা এবং তত্ক্ষণাত্ একপর্যায়ে উপরের এক স্তরকে ধরে ধরা সবসময়ই সম্ভব এবং প্রতিটি সম্ভাব্য ত্রুটির জন্য কোডের প্রতিটি লাইনকে অন্তর্ভুক্ত করা এবং প্রতিটি সম্ভাব্য ত্রুটির জন্য পদক্ষেপ নেওয়াও সম্ভব। আইএমও, এটি খারাপ নকশা, এটি কেবলমাত্র আরও বেশি ভার্বোস নয়, বিশেষত কারণ সম্ভাব্য ব্যতিক্রমগুলি যে উত্সবদ্ধ কোডগুলি পড়ে তা উত্স কোডটি না পড়ে সুস্পষ্ট নয় - এবং ব্যতিক্রমগুলি কোনও গভীর পদ্ধতি থেকে ফেলে দেওয়া যেতে পারে, অদৃশ্য গোটো তৈরি করে । তারা একাধিক অদৃশ্য বহির্গমন পয়েন্ট তৈরি করে কোডের কাঠামো ভঙ্গ করে যা কোডটি পড়া এবং পরীক্ষা করা শক্ত করে তোলে। অন্য কথায়, আপনার প্রবাহ-নিয়ন্ত্রণ হিসাবে কখনও ব্যতিক্রম ব্যবহার করা উচিত নয়, কারণ এটি বুঝতে এবং বজায় রাখা অন্যদের পক্ষে কঠিন। এটি পরীক্ষার জন্য সমস্ত সম্ভাব্য কোড প্রবাহ বুঝতে অসুবিধা পেতে পারে।
আবার: সঠিক পরিষ্কার-পরিচ্ছন্নতার জন্য / নিষ্পত্তি করার জন্য আপনি কিছু না ধরেই শেষ পর্যন্ত চেষ্টা করতে পারেন ।
রিটার্ন কোডগুলি সম্পর্কে সর্বাধিক জনপ্রিয় সমালোচনাটি হ'ল "কেউ ত্রুটি কোডগুলি উপেক্ষা করতে পারে তবে একই অর্থে কেউ ব্যতিক্রমগুলিও গ্রাস করতে পারে। উভয় পদ্ধতিতে খারাপ ব্যতিক্রম হ্যান্ডলিং সহজ But তবে ভাল ত্রুটি-কোড-ভিত্তিক প্রোগ্রাম লেখার জন্য এখনও অনেক সহজ ব্যতিক্রম-ভিত্তিক প্রোগ্রাম লেখার চেয়ে বেশি । এবং যে কোনও কারণে যদি সমস্ত ত্রুটি (পুরানো on error resume next) উপেক্ষা করার সিদ্ধান্ত নেয় , আপনি সহজেই রিটার্ন কোডগুলি সহ এটি করতে পারেন এবং প্রচুর চেষ্টা-বয়লারপ্লেট ছাড়া আপনি এটি করতে পারবেন না।
রিটার্ন কোডগুলি সম্পর্কে দ্বিতীয় সর্বাধিক জনপ্রিয় সমালোচনাটি হ'ল "বুদবুদ করা কঠিন" - তবে এর কারণ লোকেরা বুঝতে পারে না যে ব্যতিক্রমগুলি পুনরুদ্ধারযোগ্য পরিস্থিতিতে নয়, যখন ত্রুটি-কোডগুলি নয়।
ব্যতিক্রম এবং ত্রুটি কোডগুলির মধ্যে সিদ্ধান্ত নেওয়া ধূসর অঞ্চল। এটি এমনকি সম্ভব যে আপনাকে কিছু পুনরায় ব্যবহারযোগ্য ব্যবসায়ের পদ্ধতি থেকে একটি ত্রুটি কোড পাওয়া দরকার এবং তারপরে আপনি এটিকে একটি ব্যতিক্রম (সম্ভবত তথ্য যুক্ত করে) গুটিয়ে রাখুন এবং এটি বুদবুদ হতে দিন। তবে সমস্ত ত্রুটিগুলি ব্যতিক্রম হিসাবে নিক্ষেপ করা উচিত বলে ধরে নিতে এটি একটি ডিজাইনের ভুল।
এটি যোগ করা:
আমার যখন অপ্রত্যাশিত পরিস্থিতি হয় তখন আমি ব্যতিক্রমগুলি ব্যবহার করতে চাই, যেখানে খুব বেশি কিছু করার নেই এবং সাধারণত আমরা একটি বড় কোড বা এমনকি পুরো অপারেশন বা প্রোগ্রামটি বাতিল করতে চাই ort এটি পুরানো "ত্রুটি গোটো" এর মতো।
কলার কোডটি কিছু ব্যবস্থা নিতে পারে / এমন পরিস্থিতিতে আমি প্রত্যাশা করি যখন আমি রিটার্ন কোডগুলি ব্যবহার করতে চাই। এর মধ্যে বেশিরভাগ ব্যবসায়ের পদ্ধতিগুলি, এপিআই, বৈধতা ইত্যাদি রয়েছে।
ব্যতিক্রম এবং ত্রুটি কোডগুলির মধ্যে এই পার্থক্যটি জিও ভাষার অন্যতম নকশা নীতি, যা মারাত্মক অপ্রত্যাশিত পরিস্থিতিতে "আতঙ্ক" ব্যবহার করে, যখন নিয়মিত প্রত্যাশিত পরিস্থিতি ত্রুটি হিসাবে ফিরে আসে।
তবুও জিও সম্পর্কে, এটি একাধিক রিটার্ন মানকেও মঞ্জুরি দেয় , যা এমন কিছু যা রিটার্ন কোডগুলি ব্যবহারে অনেক সহায়তা করে, যেহেতু আপনি একই সাথে একটি ত্রুটি এবং অন্য কোনও কিছু ফিরিয়ে দিতে পারেন। সি # / জাভাতে আমরা প্যারামিটার, টিপলস বা (আমার প্রিয়) জেনেরিক্সের সাহায্যে এটি অর্জন করতে পারি, যা এনামগুলির সাথে মিলিতভাবে ফোনকারীকে পরিষ্কার ত্রুটি কোড সরবরাহ করতে পারে:
public MethodResult<CreateOrderResultCodeEnum, Order> CreateOrder(CreateOrderOptions options)
{
....
return MethodResult<CreateOrderResultCodeEnum>.CreateError(CreateOrderResultCodeEnum.NO_DELIVERY_AVAILABLE, "There is no delivery service in your area");
...
return MethodResult<CreateOrderResultCodeEnum>.CreateSuccess(CreateOrderResultCodeEnum.SUCCESS, order);
}
var result = CreateOrder(options);
if (result.ResultCode == CreateOrderResultCodeEnum.OUT_OF_STOCK)
// do something
else if (result.ResultCode == CreateOrderResultCodeEnum.SUCCESS)
order = result.Entity; // etc...যদি আমি আমার পদ্ধতিতে একটি নতুন সম্ভাব্য রিটার্ন যুক্ত করি, তবে সমস্ত কলকারীরা উদাহরণস্বরূপ একটি স্যুইচ স্টেটমেন্টে সেই নতুন মানটি coveringেকে রাখছে কিনা তা আমি চেক করতে পারি। আপনি ব্যতিক্রম ছাড়া সত্যই তা করতে পারবেন না। আপনি যখন রিটার্ন কোডগুলি ব্যবহার করেন, আপনি সাধারণত সমস্ত সম্ভাব্য ত্রুটিগুলি আগাম জানতেন এবং সেগুলির জন্য পরীক্ষা করান। ব্যতিক্রমগুলি সহ আপনি সাধারণত জানেন না কী হতে পারে। ব্যতিক্রম (জেনেরিক্সের পরিবর্তে) এনামগুলিকে আবৃত করা একটি বিকল্প (যতক্ষণ না এটি প্রতিটি পদ্ধতির যে ব্যতিক্রমগুলির ধরণের স্পষ্টতা স্পষ্ট থাকে), তবে আইএমও এটি এখনও খারাপ নকশা।
আমার যুক্তিটি হ'ল যদি আপনি কোনও নিম্ন-স্তরের ড্রাইভার লিখছেন যা সত্যিই পারফরম্যান্সের প্রয়োজন হয় তবে ত্রুটি কোডগুলি ব্যবহার করুন। তবে আপনি যদি সেই কোডটি একটি উচ্চ-স্তরের অ্যাপ্লিকেশনটিতে ব্যবহার করেন এবং এটি কিছুটা ওভারহেড পরিচালনা করতে পারে, তবে সেই কোডটি এমন একটি ইন্টারফেসের সাথে মোড়ক করুন যা এই ত্রুটি কোডগুলি পরীক্ষা করে এবং ব্যতিক্রম উত্থাপন করে।
অন্যান্য সমস্ত ক্ষেত্রে, ব্যতিক্রমগুলি সম্ভবত যাওয়ার উপায়।
আমি এখানে বেড়া উপর বসে থাকতে পারে, কিন্তু ...
পাইথনে, ব্যতিক্রমগুলির ব্যবহার মানক অনুশীলন এবং আমি নিজের ব্যতিক্রমগুলি সংজ্ঞায়িত করতে বেশ খুশি। সি তে আপনার মোটেই ব্যতিক্রম নেই।
সি ++ এ (কমপক্ষে এসটিএলে) ব্যতিক্রমগুলি সাধারণত সত্যিকারের ব্যতিক্রমী ত্রুটির জন্য নিক্ষেপ করা হয় (আমি কার্যত সেগুলিকে নিজে দেখি না)। আমি নিজের কোডে আলাদা কিছু করার কোনও কারণ দেখছি না। হ্যাঁ রিটার্নের মানগুলি উপেক্ষা করা সহজ, তবে সি ++ আপনাকে ব্যতিক্রমগুলি ধরতে বাধ্য করে না। আমি মনে করি আপনাকে এটি করার অভ্যাসে উঠতে হবে।
আমি যে কোড বেসটিতে কাজ করি তা বেশিরভাগ সি ++ থাকে এবং আমরা প্রায় সব জায়গাতেই ত্রুটি কোডগুলি ব্যবহার করি তবে এমন একটি মডিউল রয়েছে যা খুব ত্রুটিযুক্ত ও কোনও ত্রুটির জন্য ব্যতিক্রম ঘটায় এবং সেই মডিউলটি ব্যবহার করে এমন সমস্ত কোড বেশ ভয়াবহ। তবে এটি কেবল কারণ হতে পারে আমরা ব্যতিক্রম এবং ত্রুটি কোডগুলি মিশ্রিত করেছি। ধারাবাহিকভাবে ত্রুটি কোডগুলি ব্যবহার করে এমন কোডটি কাজ করা অনেক সহজ। যদি আমাদের কোড ধারাবাহিকভাবে ব্যতিক্রমগুলি ব্যবহার করে তবে সম্ভবত এটি খারাপ হবে না। দুজনের মিশ্রণটি তেমন ভাল কাজ করে না বলে মনে হচ্ছে।
যেহেতু আমি সি ++ নিয়ে কাজ করি এবং তাদের ব্যবহারে সুরক্ষিত করার জন্য আরআইআইআই রয়েছে তাই আমি ব্যতিক্রমগুলি প্রায় একচেটিয়াভাবে ব্যবহার করি। এটি সাধারণ প্রোগ্রাম প্রবাহের বাইরে পরিচালনা করতে ত্রুটি টেনে তোলে এবং অভিপ্রায়টিকে আরও স্পষ্ট করে তোলে।
যদিও আমি ব্যতিক্রমী পরিস্থিতিতে ব্যতিক্রম ছেড়ে দিই। যদি আমি প্রত্যাশা করি যে একটি নির্দিষ্ট ত্রুটি অনেক ঘটতে চলেছে তবে আমি পরীক্ষা করে দেখব যে এটি সম্পাদন করার আগে অপারেশনটি সফল হবে, বা ত্রুটি কোডগুলি ব্যবহার করে এমন ফাংশনের একটি সংস্করণ কল করবে (লাইক TryParse())
পদ্ধতিটি স্বাক্ষর করে পদ্ধতিটি কী করে তা আপনার সাথে যোগাযোগ করা উচিত। লম্বা ত্রুটি কোডের মতো কিছু = getErrorCode (); ভাল হতে পারে, তবে দীর্ঘ ত্রুটি কোড = ফেচরেকর্ড (); বিভ্রান্তিকর
আমার দৃষ্টিভঙ্গি হ'ল আমরা একই সাথে ব্যতিক্রম এবং ত্রুটি কোড উভয়ই ব্যবহার করতে পারি।
আমি বেশ কয়েকটি প্রকারের ব্যতিক্রম সংজ্ঞায়িত করতে ব্যবহৃত হয়েছি (উদা: ডেটাভিডিলেশনএক্সসেপশন বা প্রসেসি ইনটারপ্রেট এক্সপশন) এবং প্রতিটি ব্যতিক্রমের অভ্যন্তরে প্রতিটি সমস্যার আরও বিশদ বিবরণ সংজ্ঞায়িত করা হয়।
জাভার একটি সহজ উদাহরণ:
public class DataValidationException extends Exception {
private DataValidation error;
/**
*
*/
DataValidationException(DataValidation dataValidation) {
super();
this.error = dataValidation;
}
}
enum DataValidation{
TOO_SMALL(1,"The input is too small"),
TOO_LARGE(2,"The input is too large");
private DataValidation(int code, String input) {
this.input = input;
this.code = code;
}
private String input;
private int code;
}
এইভাবে আমি বিভাগ সম্পর্কিত ত্রুটিগুলি সংজ্ঞায়িত করতে ব্যতিক্রম এবং সমস্যা সম্পর্কিত আরও বিস্তারিত তথ্য সংজ্ঞায়িত করতে ত্রুটি কোডগুলি ব্যবহার করি।
throw new DataValidationException("The input is too small")? ব্যতিক্রমগুলির একটি সুবিধা হল বিস্তারিত তথ্যের অনুমতি দেওয়া।
ব্যতিক্রমগুলি ব্যতিক্রমী পরিস্থিতিতে - যেমন, যখন তারা কোডের স্বাভাবিক প্রবাহের অংশ না হন for
এটি ব্যতিক্রম এবং ত্রুটি কোডগুলি মিশ্রিত করা বেশ বৈধ, যেখানে ত্রুটি কোডগুলি সেওর জন্য কোডটি চালনার ক্ষেত্রে ত্রুটির পরিবর্তে কোনও কিছুর স্থিতি উপস্থাপন করে (যেমন একটি শিশু প্রক্রিয়া থেকে রিটার্ন কোড পরীক্ষা করা)।
তবে যখন কোনও ব্যতিক্রমী পরিস্থিতি দেখা দেয় তখন আমি বিশ্বাস করি ব্যতিক্রমগুলি সর্বাধিক অভিব্যক্তিপূর্ণ মডেল।
ব্যতিক্রমগুলির স্থলে আপনি ত্রুটি কোডগুলি ব্যবহার করতে পছন্দ করতে পারেন বা থাকতে পারেন এবং এগুলি ইতিমধ্যে পর্যাপ্তভাবে আবৃত হয়েছে (সংকলক সমর্থন হিসাবে অন্যান্য সুস্পষ্ট বাধা ব্যতীত)।
তবে অন্য দিকে যেতে, ব্যতিক্রমগুলি ব্যবহার করে আপনাকে ত্রুটি পরিচালনার ক্ষেত্রে আরও উচ্চ স্তরের বিমূর্ততা তৈরি করতে দেয় যা আপনার কোডটিকে আরও স্পষ্ট করে তোলে এবং প্রাকৃতিকও করে তোলে। আমি সি ++ বিশেষজ্ঞ আন্দ্রেই আলেকজান্দ্রেস্কু যেটিকে "এনফোর্সমেন্টস" বলেছেন সে বিষয়ে এই দুর্দান্ত, তবুও আন্ডাররেটেড, নিবন্ধটি পড়ার জন্য আমি তাকে সুপারিশ করব: http://www.ddj.com/cpp/184403864 । যদিও এটি একটি সি ++ নিবন্ধগুলি নীতিগুলি সাধারণত প্রযোজ্য হয় এবং আমি প্রয়োগগুলি ধারণাটি সি # তে বেশ সফলভাবে অনুবাদ করেছি।
প্রথমত, আমি টমের উত্তরের সাথে একমত যে উচ্চ স্তরের স্টাফগুলি ব্যতিক্রম ব্যবহার করে এবং নিম্ন স্তরের স্টাফগুলিতে ত্রুটি কোডগুলি ব্যবহার করা হয়, যতক্ষণ না এটি পরিষেবা ওরিয়েন্টেড আর্কিটেকচার (এসওএ) না থাকে।
এসওএতে, যেখানে বিভিন্ন মেশিনে পদ্ধতিগুলি কল করা যেতে পারে, তারের ব্যতিক্রম ব্যতিক্রমগুলি অতিক্রম করা হতে পারে না, পরিবর্তে, আমরা নীচের (সি #) এর মতো কাঠামোর সাথে সাফল্য / ব্যর্থতার প্রতিক্রিয়াগুলি ব্যবহার করি:
public class ServiceResponse
{
public bool IsSuccess => string.IsNullOrEmpty(this.ErrorMessage);
public string ErrorMessage { get; set; }
}
public class ServiceResponse<TResult> : ServiceResponse
{
public TResult Result { get; set; }
}
এবং এটির মতো ব্যবহার করুন:
public async Task<ServiceResponse<string>> GetUserName(Guid userId)
{
var response = await this.GetUser(userId);
if (!response.IsSuccess) return new ServiceResponse<string>
{
ErrorMessage = $"Failed to get user."
};
return new ServiceResponse<string>
{
Result = user.Name
};
}
এগুলি যখন আপনার পরিষেবাদি প্রতিক্রিয়াগুলিতে ধারাবাহিকভাবে ব্যবহৃত হয় তখন এটি প্রয়োগে সাফল্য / ব্যর্থতাগুলি পরিচালনা করার খুব সুন্দর প্যাটার্ন তৈরি করে। এটি পরিষেবাগুলির পাশাপাশি পরিষেবা জুড়ে async কলগুলিতে পরিচালনা করার সহজ ত্রুটি মঞ্জুরি দেয়।
আমি সমস্ত ত্রুটি ক্ষেত্রে ব্যতিক্রমগুলি পছন্দ করব, ব্যর্থতা ব্যতীত যখন কোনও ফাংশন প্রত্যাশিত বাগ-মুক্ত ফলাফল হয় যা কোনও আদিম ডেটাটাইপ ফেরত দেয় dat উদাহরণস্বরূপ, বৃহত্তর স্ট্রিংয়ের মধ্যে একটি স্ট্রিংয়ের সূচকগুলি সন্ধান করা একটি নটফাউন্ডএক্সেপশন উত্থাপনের পরিবর্তে সাধারণত -1 না পাওয়া যায়।
অবৈধ পয়েন্টারগুলি প্রত্যাখ্যান করা হতে পারে (যেমন জাভাতে নুলপয়েন্টারএক্সসেপশন ঘটায়) গ্রহণযোগ্য নয়।
একই ফাংশনের রিটার্ন মান হিসাবে একাধিক পৃথক সংখ্যাসূচক ত্রুটি কোডগুলি (-1, -2) ব্যবহার করা সাধারণত খারাপ শৈলী, কারণ ক্লায়েন্টরা "<0" এর পরিবর্তে "== -1" চেক করতে পারে।
এখানে একটি জিনিস মনে রাখতে হবে, সময়ের সাথে সাথে এপিআইগুলির বিবর্তন। একটি ভাল এআইপি ক্লায়েন্টদের না ভেঙে বিভিন্ন উপায়ে ব্যর্থতার আচরণ পরিবর্তন এবং প্রসারিত করতে দেয়। উদাহরণস্বরূপ, যদি কোনও ক্লায়েন্ট ত্রুটি হ্যান্ডেল 4 টি ত্রুটির ক্ষেত্রে পরীক্ষা করে থাকে এবং আপনি আপনার ফাংশনে একটি পঞ্চম ত্রুটি মান যুক্ত করেন, ক্লায়েন্ট হ্যান্ডলার এটি পরীক্ষা করে এবং বিরতি দিতে পারে না। আপনি যদি ব্যতিক্রমগুলি উত্থাপন করেন তবে এটি ক্লায়েন্টদের পক্ষে লাইব্রেরির নতুন সংস্করণে মাইগ্রেট করা সহজতর করে তোলে।
একটি দলে কাজ করার সময় আরও একটি বিষয় বিবেচনা করতে হবে, যেখানে এই সিদ্ধান্ত নিতে সমস্ত উন্নয়নকারীদের জন্য একটি স্পষ্ট লাইন আঁকতে হবে। উদাহরণস্বরূপ "উচ্চ-স্তরের স্টাফের জন্য ব্যতিক্রম, নিম্ন-স্তরের স্টাফগুলির জন্য ত্রুটি কোডগুলি" খুব সাবজেক্টিভ।
যাই হোক না কেন, যেখানে একাধিক তুচ্ছ ধরণের ত্রুটি সম্ভব হয়, উত্স কোডে কোনও ত্রুটি কোড ফেরত দেওয়ার জন্য বা এটি পরিচালনা করার জন্য সংখ্যাসূচক অক্ষরটি কখনই ব্যবহার করা উচিত নয় (রিটার্ন -7, যদি x == -7 ...) তবে সর্বদা একটি নাম ধ্রুবক (NO_SUCH_FOO, যদি x == NO_SUCH_FOO ফিরে আসে)।
আপনি যদি বড় প্রকল্পের অধীনে কাজ করেন তবে আপনি কেবল ব্যতিক্রম বা কেবল ত্রুটি কোডগুলি ব্যবহার করতে পারবেন না। বিভিন্ন ক্ষেত্রে আপনার বিভিন্ন পন্থা ব্যবহার করা উচিত।
উদাহরণস্বরূপ, আপনি কেবল ব্যতিক্রমগুলি ব্যবহার করার সিদ্ধান্ত নেন। তবে একবার আপনি অ্যাসিঙ্ক ইভেন্ট প্রসেসিং ব্যবহার করার সিদ্ধান্ত নেন। এই পরিস্থিতিতে ত্রুটি পরিচালনার জন্য ব্যতিক্রমগুলি ব্যবহার করা খারাপ ধারণা। তবে অ্যাপ্লিকেশনটিতে যে কোনও জায়গায় ত্রুটি কোডগুলি ব্যবহার করা ক্লান্তিকর।
সুতরাং আমার অভিমত যে একই সাথে ব্যতিক্রম এবং ত্রুটি কোড উভয়ই ব্যবহার করা স্বাভাবিক।
আমি মনে করি এটি ফলাফল থেকে স্ট্যাক ট্রেসের মতো আপনার সত্যিকারের তথ্যের প্রয়োজন কিনা তার উপরও এটি নির্ভর করে। যদি হ্যাঁ, তবে আপনি অবশ্যই ব্যাতিক্রমের জন্য যান যা সমস্যার বিষয়ে প্রচুর তথ্য দিয়ে বস্তুকে পূর্ণ সরবরাহ করে। তবে, আপনি যদি কেবল ফলাফলের বিষয়ে আগ্রহী হন এবং কেন ফলাফলটি যত্নশীল হন না তবে ত্রুটি কোডের জন্য যান।
উদাহরণস্বরূপ আপনি যখন ফাইলটি প্রসেস করছেন এবং আইওএক্সেপশনের মুখোমুখি হন, ক্লায়েন্ট কোথা থেকে এটি ট্রিগার হয়েছিল তা জানার বিষয়ে আগ্রহী হতে পারে, ফাইল খোলার ক্ষেত্রে বা পার্সিং ফাইল ইত্যাদি So সুতরাং আপনি আইওএক্সেপশন বা তার নির্দিষ্ট সাবক্লাসটি আরও ভালভাবে ফিরিয়ে দিতে পারেন। যাইহোক, আপনার মতো দৃশ্যের লগইন পদ্ধতি রয়েছে এবং আপনি এটি সফল কিনা তা জানতে চান, সেখানে আপনি কেবল বুলিয়ান ফিরিয়ে দেন বা সঠিক বার্তা প্রদর্শন করতে, ত্রুটি কোডটি দেখান। এখানে ক্লায়েন্ট যুক্তির কোন অংশটি ত্রুটি কোডের কারণ ঘটেছে তা জানতে আগ্রহী নয়। তিনি কেবল জানেন যে এটির শংসাপত্রটি অবৈধ বা অ্যাকাউন্ট লক ইত্যাদি if
আর একটি ইউজকেস যা আমি ভাবতে পারি তা হল যখন ডেটা নেটওয়ার্কে ভ্রমণ করে। আপনার দূরবর্তী পদ্ধতি ডেটা স্থানান্তর হ্রাস করতে ব্যতিক্রমের পরিবর্তে কেবল ত্রুটি কোডটি ফিরে আসতে পারে।
ত্রুটি কোডগুলিও কার্যকর হয় না যখন আপনার পদ্ধতিতে একটি সংখ্যাগত মান ব্যতীত অন্য কোনও কিছু ফেরত দেয় ...