দৃ by়তা বা ব্যতিক্রম ব্যবহার করে চুক্তি দ্বারা ডিজাইন? [বন্ধ]

Question

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

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

আপনি কোনটি পছন্দনীয় বলে মনে করেন?

রিলেটেড প্রশ্ন এখানে দেখুন

Comments

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

— void.pointer

দুর্দান্ত প্রশ্ন, তবে আমি মনে করি আপনার গ্রহণযোগ্য উত্তরটিও বদলে দেওয়া উচিত (যেমন ভোটগুলিও দেখায়)!

— ডেভফার

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

— এরিক জি

এই প্রতিক্রিয়াটিতে খুব সংক্ষিপ্ত প্রতিক্রিয়া দেওয়া হয়েছে : "অন্য কথায়, ব্যতিক্রমগুলি আপনার প্রয়োগের দৃust়ত্বকে সম্বোধন করে, যদিও দৃ .়তাগুলি এর যথার্থতাকে সম্বোধন করে।"

— শমুয়েল লেভাইন

Answer 1

রিলিজ বিল্ডগুলিতে দৃsert়তা অক্ষম করা "রিলিজ বিল্ডে আমার কোনও সমস্যা হবে না" বলার মতো, যা প্রায়শই হয় না। সুতরাং দৃsert়তা একটি রিলিজ বিল্ডে অক্ষম করা উচিত নয়। কিন্তু আপনি যখনই ত্রুটিগুলি প্রকাশ করেন তখনই বিল্ডিং ক্র্যাশিং বিল্ডিং চান না, তাই না?

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

Comments

দৃ least়তা যাচাই করা সেই ক্ষেত্রে ক্ষেত্রে যথাযথভাবে কার্যকর হয় যেখানে সঠিকভাবে পরীক্ষা করা সঠিকভাবে পরীক্ষা করা অক্ষম বা অদক্ষ হয়ে থাকে।

— কেসব্যাশ

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

— জলফ

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

— কোপপ্রো ২

@ জালফ, যদিও আপনি আপনার ডিবাগারে রিলিজ বিল্ডগুলিতে একটি হুক রাখতে পারবেন না, আপনি লগিংটি উত্তোলন করতে পারেন যাতে বিকাশকারীরা আপনার দাবির সাথে সম্পর্কিত তথ্য ব্যর্থ হয়। এই দস্তাবেজটিতে ( মার্টিনফাউলটার / আইইআইসফটওয়্যার / ফেইলফাস্ট.পিডিএফ ) জিম শোর উল্লেখ করেছেন, "মনে রাখবেন, গ্রাহকের সাইটে ঘটে যাওয়া একটি ত্রুটি এটি আপনার পরীক্ষার প্রক্রিয়াটির মাধ্যমে তৈরি করেছে You সম্ভবত আপনাকে পুনরুত্পাদন করতে সমস্যা হবে। এই ত্রুটিগুলি হ'ল খুঁজে পাওয়া সবচেয়ে শক্তিশালী এবং সমস্যাটি ব্যাখ্যা করার মতো একটি ভালভাবে বলা দৃ you়তা আপনাকে প্রচেষ্টার দিনগুলি বাঁচাতে পারে। "

— স্ট্রিপলিং ওয়ারিয়র

ব্যক্তিগতভাবে আমি চুক্তি পদ্ধতির দ্বারা নকশার জন্য দৃser় সংস্থানগুলি পছন্দ করি। ব্যতিক্রমগুলি ডিফেন্সিভ এবং ফাংশনের ভিতরে যুক্তি যাচাই করে নিচ্ছেন। এছাড়াও, ডিবিসি পূর্ববর্তী শর্তাদি "আপনি যদি কাজের পরিসরের বাইরে মানগুলি ব্যবহার করেন তবে আমি কাজ করব না" বলে না তবে "আমি সঠিক উত্তর দেওয়ার গ্যারান্টি দিচ্ছি না, তবে আমি এখনও করতে পারি"। জরিপগুলি বিকাশকারীকে প্রতিক্রিয়া সরবরাহ করে যে তারা কোনও শর্ত লঙ্ঘন করে একটি ফাংশন কল করছে, তবে তারা আরও ভাল জানেন যদি তাদের মনে হয় তবে এটি ব্যবহার করা থেকে তাদের বিরত করবেন না। লঙ্ঘন ব্যতিক্রম ঘটতে পারে, কিন্তু আমি এটি একটি ভিন্ন জিনিস হিসাবে দেখছি।

— ম্যাট_জেডি

Answer 2

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

Comments

বিভিন্ন মডিউল / অ্যাপ্লিকেশনগুলিতে বসে সিরিয়ালাইজ / ডিসরিয়ালাইজ করা এবং শেষ পর্যন্ত সিঙ্কের বাইরে চলে যাওয়ার বিষয়ে কী? আমি পাঠকদের অংশে বোঝাতে চাইছি যদি আমি বিষয়গুলি ভুলভাবে পড়ার চেষ্টা করি তবে সর্বদা আমার ভুল হয় তাই আমি দৃ use়ভাবে ব্যবহার করার প্রবণতা রাখি তবে অন্যদিকে আমার কাছে বাহ্যিক ডেটা রয়েছে যা অবশেষে বিনা বিজ্ঞপ্তিতে বিন্যাস পরিবর্তন করতে পারে।

— স্লাভা

যদি ডেটা বাহ্যিক হয় তবে আপনার ব্যতিক্রমগুলি ব্যবহার করা উচিত। এই বিশেষ ক্ষেত্রে আপনার সম্ভবত সেই ব্যতিক্রমগুলিও ধরা উচিত এবং আপনার প্রোগ্রামটিকে কেবল মরতে না দিয়ে কিছু যুক্তিসঙ্গত উপায়ে সেগুলি পরিচালনা করা উচিত। এছাড়াও, আমার উত্তরটি থাম্বের নিয়ম, প্রকৃতির কোনও আইন নয়। :) সুতরাং আপনাকে প্রতিটি কেস পৃথকভাবে বিবেচনা করতে হবে।

— ডিমা

যদি আপনার ফাংশন f (int * x) এর মধ্যে একটি লাইন x-> লেন থাকে তবে f (v) যেখানে v নাল হিসাবে প্রমাণিত হয় তা ক্র্যাশ হওয়ার নিশ্চয়তা দেয় is তদ্ব্যতীত, এমনকি যদি v এর আগেও শূন্য প্রমাণিত হয় তবে চ (ভি) বলা হয় প্রমাণিত হয়, আপনার যৌক্তিক দ্বন্দ্ব রয়েছে। এটি একটি / বি থাকার সমান যেখানে খ শেষ পর্যন্ত 0 হিসাবে প্রমাণিত হয় আদর্শভাবে, এই জাতীয় কোডটি সংকলন করতে ব্যর্থ হওয়া উচিত। ধারণাটি চেকগুলির ব্যয় না হলে অনুমানের চেকগুলি বন্ধ করা সম্পূর্ণ বোকামি, কারণ এটি সেই অবস্থানটিকে অস্পষ্ট করে যেখানে অনুমান লঙ্ঘিত হয়েছিল। এটি অবশ্যই কমপক্ষে লগ করা উচিত। যাইহোক আপনার পুনঃসূচনা অন ক্রাশ নকশা করা উচিত।

— রব

Answer 3

যে নীতিটি আমি অনুসরণ করি তা হ'ল: যদি কোনও পরিস্থিতি কোডিংয়ের মাধ্যমে বাস্তবতাকে এড়ানো যায় তবে একটি দৃ .়তা ব্যবহার করুন। অন্যথায় একটি ব্যতিক্রম ব্যবহার করুন।

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

ব্যতিক্রমগুলি এমন পরিস্থিতিতে রয়েছে যা ক্লায়েন্ট এবং সার্ভার উভয়েরই নিয়ন্ত্রণের বাইরে। একটি ব্যতিক্রমের অর্থ হ'ল কিছু ভুল হয়েছে এবং এটি এড়াতে এমন কিছুই করা যাচ্ছিল না। উদাহরণস্বরূপ, নেটওয়ার্ক কানেক্টিভিটি অ্যাপ্লিকেশন নিয়ন্ত্রণের বাইরে রয়েছে তাই নেটওয়ার্ক ত্রুটি এড়াতে এমন কিছুই করা যায় না।

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

Answer 4

দাবিগুলি কোনও বিকাশকারী অন্যায় করেছে এমন কিছু ধরার জন্য (কেবল নিজেরাই নয় - আপনার দলের অন্য বিকাশকারীও)। যদি এটি যুক্তিযুক্ত যে কোনও ব্যবহারকারীর ভুলটি এই শর্তটি তৈরি করতে পারে তবে এটি ব্যতিক্রম হওয়া উচিত।

তেমনি পরিণতি সম্পর্কে চিন্তা করুন। একটি দাবী সাধারণত অ্যাপ্লিকেশনটি বন্ধ করে দেয়। যদি শর্তটি পুনরুদ্ধার হতে পারে এমন কোনও বাস্তব প্রত্যাশা থাকে তবে আপনার সম্ভবত একটি ব্যতিক্রম ব্যবহার করা উচিত।

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

Answer 5

এটি ঠিক সত্য নয় যে "দাবী কেবলমাত্র ডিবাগ মোডে ব্যর্থ হয়।"

ইন ওরিয়েন্টড সফটওয়্যার নির্মাণ, 2nd সংস্করণ অবজেক্ট বারট্রান্ড মেয়ার, লেখক পাতার একটি দরজা মুক্তি মোডে পূর্বশর্ত চেক করার জন্য খোলা দ্বারা। সেক্ষেত্রে, দৃ an়তা ব্যর্থ হলে কী ঘটে তা হ'ল ... একটি প্রতিবেদন লঙ্ঘন ব্যতিক্রম উত্থাপিত হয়! এই ক্ষেত্রে, পরিস্থিতি থেকে কোনও পুনরুদ্ধার নেই: যদিও কার্যকর কিছু করা যেতে পারে, এবং এটি স্বয়ংক্রিয়ভাবে একটি ত্রুটি প্রতিবেদন তৈরি করা এবং কিছু ক্ষেত্রে অ্যাপ্লিকেশনটি পুনরায় চালু করা হয়।

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

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

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

সংক্ষিপ্তসার হিসাবে, আপনার দৃ as়তা থাকতে পারে এবং তারপরেও ব্যতিক্রমগুলি স্বয়ংক্রিয়ভাবে পেতে পারেন, যদি আপনি এগুলি সক্ষম করে রাখেন - কমপক্ষে আইফেলে। আমার মনে হয় সি ++ এ একই কাজ করতে আপনার নিজের এটি টাইপ করা দরকার।

আরও দেখুন: উত্সব কোডগুলিতে কবে থাকা উচিত?

Comments

আপনার বক্তব্য অবশ্যই কার্যকর। সুতরাং একটি বিশেষ ভাষা নির্দিষ্ট করা হয়নি - C # এর ক্ষেত্রে মান জাহির System.Diagnostics.Debug.Assert, যা নেই শুধুমাত্র একটি ডিবাগ বিল্ড ব্যর্থ, এবং একটি রিলিজ Build এ কম্পাইল সময়ে সরানো হবে।

— yoyo

Answer 6

কমপ্লেং.এল.সি.সি.আর.কে রিলিজ বিল্ডিংয়ে দৃser়ভাবে দাবিগুলি সক্ষম / নিষ্ক্রিয় করার বিষয়ে একটি বিশাল থ্রেড ছিল , যা আপনার কাছে কয়েক সপ্তাহ থাকলে আপনি দেখতে পাবেন যে এই বিষয়ে মতামতটি কতটা বিচিত্র। :)

কোপপ্রো এর বিপরীতে , আমি বিশ্বাস করি যে আপনি যদি নিশ্চিত হন না যে একটি দৃ release়তা একটি রিলিজ বিল্ডে অক্ষম করা যেতে পারে, তবে এটি জোর দেওয়া উচিত হয়নি। জোর দেওয়া প্রোগ্রামের আক্রমণকারীদের ভাঙ্গা থেকে রক্ষা করা হয়। এই জাতীয় ক্ষেত্রে, আপনার কোডের ক্লায়েন্ট যতদূর উদ্বিগ্ন, দুটি সম্ভাব্য ফলাফলের মধ্যে একটি হতে পারে:

1. কোনও ধরণের ওএস টাইপ ব্যর্থতার সাথে মরে যা ফলস্বরূপ বাতিল করতে বাধ্য হয়। (দৃ Without়তা ছাড়াই)
2. প্রত্যাহার করার জন্য সরাসরি কলের মাধ্যমে মরা। (জোর দিয়ে)

ব্যবহারকারীর মধ্যে কোনও পার্থক্য নেই, তবে, এটি সম্ভবত সম্ভব যে কোডগুলি ব্যর্থ হয় না এমন সংখ্যক রানের সংখ্যাটিতে উপস্থিত কোডটিতে একটি অপ্রয়োজনীয় কর্মক্ষমতা ব্যয় করা সম্ভব।

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

ব্যক্তিগতভাবে, তবে আমি নিশ্চিত না যে আমি এই ক্ষেত্রেও ব্যাতিক্রম করব। ব্যতিক্রমগুলি যেখানে পুনরুদ্ধারের উপযুক্ত ফর্মটি নিতে পারে তার পক্ষে আরও উপযুক্ত। উদাহরণস্বরূপ, এটি হতে পারে আপনি মেমরি বরাদ্দ করার চেষ্টা করছেন। আপনি যখন 'std :: Bad_alloc' ব্যতিক্রম ধরেন তখন মেমরিটি মুক্ত করে আবার চেষ্টা করা সম্ভব।

Answer 7

আমি এখানে বিষয়টি সম্পর্কে আমার দৃষ্টিভঙ্গি তুলে ধরেছি: আপনি কীভাবে কোনও সামগ্রীর অভ্যন্তরীণ অবস্থাকে বৈধতা দেবেন? । সাধারণত, আপনার দাবির উপর চাপ দিন এবং অন্যরা লঙ্ঘনের জন্য নিক্ষেপ করুন। রিলিজ বিল্ডগুলিতে দৃser় অক্ষম করার জন্য, আপনি এটি করতে পারেন:

• ব্যয়বহুল চেকগুলির জন্য দাবী অক্ষম করুন (যেমন একটি সীমা অর্ডার করা হয়েছে কিনা তা পরীক্ষা করা)
• তুচ্ছ পরীক্ষাগুলি সক্ষম করে রাখুন (যেমন নাল পয়েন্টার বা বুলিয়ান মান পরীক্ষা করা)

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

Answer 8

আপনি ডিজাইন-সময় এবং রান-টাইম ত্রুটির মধ্যে পার্থক্য সম্পর্কে জিজ্ঞাসা করছেন।

'হেই প্রোগ্রামার হ'ল, এটি নষ্ট হয়ে গেছে' বিজ্ঞপ্তিগুলি জোর দিয়ে জানিয়েছে, তারা যখন আপনাকে ত্রুটিগুলি স্মরণ করিয়ে দেওয়ার জন্য আসে যে তারা কখন ঘটেছিল সেদিকে খেয়াল করবেন না।

ব্যতিক্রমগুলি 'ওহে ব্যবহারকারী, কিছুটা ভুল হয়ে গেছে' বিজ্ঞপ্তিগুলি (স্পষ্টত আপনি তাদের ধরার জন্য কোড করতে পারেন যাতে ব্যবহারকারী কখনই না বলে) তবে জো ব্যবহারকারী যখন অ্যাপটি ব্যবহার করছেন তখন এগুলি ডিজাইন করা হয়েছে run

সুতরাং, আপনি যদি মনে করেন যে আপনি আপনার সমস্ত বাগ বের করতে পারেন তবে কেবল ব্যতিক্রমগুলি ব্যবহার করুন। আপনি যদি ভাবেন যে আপনি পারবেন না ..... ব্যতিক্রম ব্যবহার করুন। আপনি অবশ্যই ব্যতিক্রম সংখ্যা অবশ্যই কম করার জন্য ডিবাগ এজেন্টস ব্যবহার করতে পারেন।

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

শেষ অবধি, আমি উভয়ই ব্যবহার করব না - ত্রুটি কোডগুলি ত্রুটিগুলির তুলনায় অনেক বেশি উন্নত যা আপনি ভাবেন যে নিয়মিত হবে। :)

Answer 9

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

Answer 10

পূর্ববর্তী উত্তরগুলি সঠিক: পাবলিক এপিআই কার্যক্রমে ব্যতিক্রমগুলি ব্যবহার করুন। আপনি যখন এই নিয়মটি বাঁকতে চান কেবল তখনই চেকটি কম্পিউটারের ব্যয়বহুল ব্যয় হয়। যে ক্ষেত্রে, আপনি করতে পারেন এটা একটা জাহির রাখা।

যদি আপনি মনে করেন যে পূর্ব শর্তটির লঙ্ঘন সম্ভবত, তবে এটি ব্যতিক্রম হিসাবে রাখুন, বা পূর্ববর্তী অবস্থাটিকে চুল্লি থেকে দূরে সরিয়ে রাখুন।

Answer 11

আপনার উভয় ব্যবহার করা উচিত। বিকাশকারী হিসাবে আপনার সুবিধার জন্য জোর দেওয়া। ব্যতিক্রমগুলি রানটাইম চলাকালীন যে জিনিসগুলি আপনি মিস করেছেন বা প্রত্যাশা করেননি সেগুলি ধরেন।

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

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

#ifdef DEBUG
#define RETURN_IF_FAIL(expr)      do {                      \
 if (!(expr))                                           \
 {                                                      \
     fprintf(stderr,                                        \
        "file %s: line %d (%s): precondition `%s' failed.", \
        __FILE__,                                           \
        __LINE__,                                           \
        __PRETTY_FUNCTION__,                                \
        #expr);                                             \
     ::print_stack_trace(2);                                \
     return;                                                \
 };               } while(0)
#define RETURN_VAL_IF_FAIL(expr, val)  do {                         \
 if (!(expr))                                                   \
 {                                                              \
    fprintf(stderr,                                             \
        "file %s: line %d (%s): precondition `%s' failed.",     \
        __FILE__,                                               \
        __LINE__,                                               \
        __PRETTY_FUNCTION__,                                    \
        #expr);                                                 \
     ::print_stack_trace(2);                                    \
     return val;                                                \
 };               } while(0)
#else
#define RETURN_IF_FAIL(expr)
#define RETURN_VAL_IF_FAIL(expr, val)
#endif

আমার যদি আর্গুমেন্টের রানটাইম চেকিংয়ের প্রয়োজন হয় তবে আমি এটি করতাম:

char *doSomething(char *ptr)
{
    RETURN_VAL_IF_FAIL(ptr != NULL, NULL);  // same as assert(ptr != NULL), but returns NULL if it fails.
                                            // Goes away when debug off.

    if( ptr != NULL )
    {
       ...
    }

    return ptr;
}

Comments

আমি মনে করি না আমি সি ++ এর সাথে সম্পর্কিত কোনও প্রশ্নে ওপি প্রশ্নে দেখেছি। আমি বিশ্বাস করি এটি আপনার উত্তরের অন্তর্ভুক্ত করা উচিত নয়।

— ফোর্স ম্যাজিক

@ ফোরস ম্যাজিক: ২০০৮ সালে যখন আমি এই উত্তরটি পোস্ট করলাম তখন প্রশ্নটির সি ++ ট্যাগ ছিল এবং আসলে সি ++ ট্যাগটি কেবল 5 ঘন্টা আগে সরানো হয়েছিল। নির্বিশেষে, কোডটি একটি ভাষা-স্বাধীন ধারণা চিত্রিত করে।

— ইন্দিব

Answer 12

আমি এখানে আমার নিজের মতামত দিয়ে অন্য কয়েকটি উত্তর সংশ্লেষ করার চেষ্টা করেছি।

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

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

যুক্তি পুনরায় যুক্ত করুন যে দাবিগুলি ডিবাগ করা সহজ: সঠিকভাবে নামকরণ করা ব্যতিক্রম থেকে স্ট্যাক ট্রেস একটি দৃ as়তা হিসাবে পড়া সহজ। ভাল কোডে কেবলমাত্র নির্দিষ্ট ধরণের ব্যতিক্রম ধরা উচিত, তাই ধরা পড়ার কারণে ব্যতিক্রমগুলি নজরে না আসা উচিত। তবে আমি মনে করি জাভা কখনও কখনও আপনাকে সমস্ত ব্যতিক্রমগুলি ধরতে বাধ্য করে।

Answer 13

আমার কাছে থাম্বের নিয়মটি হ'ল বাহ্যিক ত্রুটির জন্য অভ্যন্তরীণ ত্রুটিগুলি এবং ব্যতিক্রমগুলি সন্ধান করতে এক্সপ্রেশনটিকে দৃ express়ভাবে ব্যবহার করুন। আপনি এখান থেকে গ্রেগ দ্বারা নিম্নলিখিত আলোচনা থেকে অনেক উপকার করতে পারেন ।

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

প্রোগ্রামে জোর কীভাবে যুক্ত হয় তা বোঝার জন্য, সি ++ প্রোগ্রামের একটি রুটিন বিবেচনা করুন যা কোনও পয়েন্টারকে অবজ্ঞা করতে চলেছে। এখন রুটিনটি পরীক্ষা করা উচিত যে ডিফারেন্সিংয়ের পূর্বে পয়েন্টারটি নুল হয় কিনা, বা এটি কি দৃsert়রূপে বলা উচিত যে পয়েন্টারটি নুল নয় এবং তারপরে নির্বিশেষে এটি এগিয়ে যাওয়া উচিত?

আমি কল্পনা করি যে বেশিরভাগ বিকাশকারী উভয়ই উভয়ই করতে চান, দৃ .় সংযোজন করতে পারেন, তবে একটি নূন্যমূল্যটির জন্য পয়েন্টারটিও পরীক্ষা করে দেখুন যাতে দৃ condition় শর্তটি ব্যর্থ হলে ক্রাশ না হয়। পৃষ্ঠতলে, পরীক্ষা এবং চেক উভয়ই সম্পাদন করা বুদ্ধিমানের সিদ্ধান্ত বলে মনে হতে পারে

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

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

পিএস: আপনি অনুরূপ প্রশ্নটি দেখতে চাইতে পারেন: ব্যতিক্রম বনাম দৃ As়তা ।

Answer 14

আরো দেখুন এই প্রশ্নের :

আমি কিছু ক্ষেত্রে, দৃser়তা মুক্তির জন্য নির্মাণের সময় অক্ষম করা হয়। এটির উপর আপনার নিয়ন্ত্রণ নাও থাকতে পারে (অন্যথায়, আপনি জোর দিয়ে তৈরি করতে পারেন), সুতরাং এটি এটি করা ভাল ধারণা হতে পারে।

ইনপুট মানগুলিকে "সংশোধন" করার সমস্যাটি হ'ল কলার তারা যা প্রত্যাশা করে তা পাবে না এবং এটি প্রোগ্রামের পুরো বিভিন্ন অংশে সমস্যা বা এমনকি ক্র্যাশ করতে পারে, যা একটি দুঃস্বপ্ন ডিবাগ করে।

আমি অক্ষম হওয়ার ক্ষেত্রে দাবী রাখার ভূমিকা নেওয়ার জন্য সাধারণত if-বিবৃতিতে একটি ব্যতিক্রম ছুঁড়ে ফেলি

assert(value>0);
if(value<=0) throw new ArgumentOutOfRangeException("value");
//do stuff