কখন আমি ডিবাগ.আসার্ট () ব্যবহার করব?

Question

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

আমাদের প্রোডাকশন কোডটিতে যা আছে তা নিয়ে কোনও যুক্তি নেই এবং আমার প্রশ্নটি এটি ...

আমাদের প্রোডাকশন কোডে আমার কি এসার্ট ব্যবহার শুরু করা উচিত? এবং যদি তাই হয় তবে এর ব্যবহার কখন সবচেয়ে উপযুক্ত? এটি আরও বুদ্ধিমান করতে চান

Debug.Assert(val != null);

অথবা

if ( val == null )
    throw new exception();

Comments

আপনি যে দ্বৈতত্ত্ব স্থাপন করেছেন তা হ'ল ক্লু। এটি উভয়ই এবং ডিফেন্সিভ কোডের জন্য বা ব্যতিক্রম এবং দৃ .়তার জন্য প্রশ্ন নয় not কখন কোনটি করণীয় তা আপনি বুঝতে চাইছেন।

— ক্যাস্পার লিওন নিলসন

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

— মার্ক আমেরিকা

সম্পর্কিত: উত্সাহগুলি কখন কোডের কোডে থাকা উচিত?

— ডেভিডআরআর

ব্যক্তিগতভাবে আমি ব্যক্তিগত পদ্ধতিগুলির জন্য জনসাধারণের পদ্ধতিগুলির জন্য এবং ব্যতীত ব্যতিক্রমগুলি ব্যবহার করি।

— ফ্রেড

Answer 1

ইন ডিবাগ মাইক্রোসফট .NET 2.0 অ্যাপ্লিকেশন জন রবিন্স গবেষকেরা বড় অধ্যায় আছে। তার প্রধান বিষয়গুলি হ'ল:

1. উদারভাবে জোর দিন। আপনি কখনই খুব বেশি জোর দিতে পারবেন না।
2. জোর দেওয়া ব্যতিক্রমগুলি প্রতিস্থাপন করে না। ব্যতিক্রমগুলি আপনার কোডগুলির যে জিনিসগুলির দাবি করে; জোর দেওয়া জিনিসগুলি ধরে নেয় তা কভার করে।
3. একটি ভাল-লিখিত বক্তব্য আপনাকে কেবল কী ঘটেছে এবং কোথায় (একটি ব্যতিক্রমের মতো) তা নয়, তবে কেন তা বলতে পারে।
4. একটি ব্যতিক্রম বার্তা প্রায়শই ক্রিপ্টিক হতে পারে, আপনাকে ত্রুটির কারণ হিসাবে প্রসঙ্গটি পুনরায় তৈরি করতে কোডের মাধ্যমে পিছনের দিকে কাজ করতে হবে। ত্রুটি হওয়ার সময় একটি দৃser়তা প্রোগ্রামের অবস্থা সংরক্ষণ করতে পারে।
5. আপনার কোডের উপর নির্ভর করে অনুমানগুলি কী বোঝায় তা অন্য বিকাশকারীদের বলার সাথে ডকুমেন্টেশন হিসাবে দ্বিগুণ জোর দেওয়া হয়েছে।
6. একটি দৃser়তা ব্যর্থ হওয়ার পরে উপস্থিত হওয়া ডায়লগটি আপনাকে প্রক্রিয়াটিতে একটি ডিবাগার সংযুক্ত করতে দেয়, যাতে আপনি স্ট্যাকের চারপাশে ঝাঁকুনি দিতে পারেন যেন আপনি সেখানে ব্রেকআপপয়েন্ট রেখেছিলেন।

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

Comments

সংক্ষিপ্ত এবং সহায়ক সংক্ষিপ্তসার জন্য +1। খুব সরাসরি প্রযোজ্য। আমার জন্য যে প্রধান জিনিসটি অনুপস্থিত তা হ'ল ট্রেস.আসর্ট বনাম ট্রেস.আসর্ট ব্যবহার করার সময়। অর্থাত্ আপনার প্রযোজনা কোডে আপনি কখন / না চান সে সম্পর্কে কিছু something

— জন Coombs

জোনকুমবস কি "ট্রেস.আসর্ট বনাম ট্রেস.আসর্ট" টাইপো?

— থিম

@ থেলেম সম্ভবত জনের অর্থ Debug.Assertবনাম Trace.Assert। দ্বিতীয়টি একটি রিলিজ বিল্ডের পাশাপাশি একটি ডিবাগ বিল্ডে কার্যকর করা হয়।

— ডেভিডআরআর

কেন আমি ডিবাগকে পছন্দ করব? ছোঁড়া ব্যতিক্রমের জন্য কী?

— বারে আক্কুর্ট

Answer 2

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

কল করার আগে আপনার এখনও ব্যতিক্রম ছুঁড়ে ফেলা উচিত Debug.Assert()। প্রতিস্থাপনটি নিশ্চিত করে তোলে যে আপনি যখন এখনও বিকাশ করছেন তখন সবকিছু প্রত্যাশার মতো।

Comments

আপনি যদি স্পষ্ট করে বলতে পারেন যে কেন আপনি যদি এটির ডাকার আগেও একটি ব্যতিক্রম ছুঁড়ে বলেন তবে কেন একটি দৃ in়তা এনে দেওয়া হয়েছে? নাকি আমি আপনার উত্তর ভুল বুঝেছি?

— রোমান স্টারকভ

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

— অস্কার মেডেরোস

@ অস্কার আমি ভেবেছিলাম যে এটি প্রথম স্থানে দাবী ব্যবহার করার পুরো বিষয় ছিল ... ঠিক আছে, তাই আপনি তাদের ব্যতিক্রমগুলি তাদের সামনে রেখেছিলেন - তবে কেন দৃser়তার পরে দৃser়তা রাখলেন?

— রোমান স্টারকভ

@ সুপেরজোস: আমাকে একমত হতে হবে: ম্যাকলিউডের উত্তরে পয়েন্ট # 2 বলছে যে আপনার সত্যিকারের দৃ as়তা এবং ব্যতিক্রমগুলি দরকার তবে একই জায়গায় নয়। কোনও ভেরিয়েবলের উপরে নুলআরএফএক্স ছুঁড়ে ফেলা নিষ্ক্রিয় এবং ঠিক তারপরে এ্যাসেট করার পরেও (দৃsert়পদ্ধতি পদ্ধতিটি এই ক্ষেত্রে কোনও ডায়ালগবক্স কখনই প্রদর্শন করবে না, যা দৃsert়তার সম্পূর্ণ দিক)। ম্যাকলিউড বলতে যা বোঝায় তা হ'ল কোনও জায়গায় আপনার একটি ব্যতিক্রম প্রয়োজন হবে, অন্যদের মধ্যে একটি সংস্থান যথেষ্ট হবে।

— ডেভিড

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

— সুপারহোজ

Answer 3

কোড সম্পূর্ণ থেকে

8 ডিফেন্সিভ প্রোগ্রামিং

৮.২ জোর

একটি প্রতিস্থাপন হ'ল এমন কোড যা বিকাশের সময় ব্যবহৃত হয় - সাধারণত একটি রুটিন বা ম্যাক্রো — যা কোনও প্রোগ্রামকে চালিত হওয়ার সাথে সাথে নিজেকে যাচাই করতে দেয়। যখন একটি দৃ true়তা সত্য হয়, তার অর্থ প্রত্যাশার সাথে সবকিছু পরিচালনা করছে। যখন এটি মিথ্যা হয়, তার মানে এটি কোডটিতে একটি অপ্রত্যাশিত ত্রুটি সনাক্ত করেছে। উদাহরণস্বরূপ, যদি সিস্টেমটি ধরে নেয় যে কোনও গ্রাহক-তথ্য ফাইলে কখনই 50,000 রেকর্ডের বেশি রেকর্ড থাকবে না, প্রোগ্রামটিতে এমন একটি মন্তব্য থাকতে পারে যে রেকর্ডের সংখ্যাটি 50,000 এর চেয়ে কম বা সমান। যতক্ষণ রেকর্ডের সংখ্যা 50,000 এর থেকে কম বা সমান হয়, ততক্ষণ দৃ .়তা নিরব থাকবে। এটি যদি ৫০,০০০ রেকর্ডেরও বেশি রেকর্ডের মুখোমুখি হয় তবে এটি উচ্চস্বরে "জোর দিয়ে" বলবে যে প্রোগ্রামটিতে একটি ত্রুটি রয়েছে।

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

একটি দৃser়তা সাধারণত দুটি যুক্তি গ্রহণ করে: একটি বুলিয়ান এক্সপ্রেশন যা সত্য বলে মনে করা হয় এমন ধারণাটি বর্ণনা করে এবং যদি তা না হয় তবে প্রদর্শন করার জন্য একটি বার্তা।

(...)

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

Comments

সুতরাং, যদি কোনও গ্রাহক-তথ্য ফাইলে উত্পাদনের মুখোমুখি হয় তবে কী হবে 50,000 এরও বেশি রেকর্ড রয়েছে? যদি দাবিটি প্রোডাকশন কোডের বাইরে সঙ্কলিত হয় এবং এই পরিস্থিতি অন্যথায় পরিচালিত হয় না, তাহলে এই বানানটি সমস্যা হয় না?

— ডেভিডআরআর

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

— মার্চ

Answer 4

FWIW ... আমি দেখতে পেয়েছি যে আমার সর্বজনীন পদ্ধতিগুলি if () { throw; }সঠিকভাবে ডাকা হচ্ছে কিনা তা নিশ্চিত করার জন্য প্যাটার্নটি ব্যবহার করে । আমার ব্যক্তিগত পদ্ধতি ব্যবহার করতে ঝোঁক Debug.Assert()।

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

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

Comments

এটি একটি ভাল অনুশীলনের খুব স্পষ্ট বর্ণনা এবং এটি জিজ্ঞাসিত প্রশ্নের একটি খুব যুক্তিসঙ্গত উত্তর দেয়।

— ক্যাস্পার লিওন নীলসেন

Answer 5

পরিবেশগত অনুমানগুলি যাচাই করতে বিকাশকারী অনুমান এবং ব্যতিক্রমগুলি যাচাই করতে সংস্থানগুলি ব্যবহার করুন।

Answer 6

আমি আপনি হলে আমি করতাম:

Debug.Assert(val != null);
if ( val == null )
    throw new exception();

অথবা বারবার শর্ত পরীক্ষা করা এড়াতে

if ( val == null )
{
    Debug.Assert(false,"breakpoint if val== null");
    throw new exception();
}

Comments

এটি কীভাবে সমস্যার সমাধান করছে? এটির সাহায্যে ডিবাগ.এসার্ট অর্থহীন হয়ে যায়।

— কুইবলসোম

না এটি হয় না - এটি ব্যতিক্রম ছোঁড়ার ঠিক আগে পয়েন্টে কোডে বিভক্ত হয়। আপনার কোডে অন্য কোথাও চেষ্টা / ধরা থাকলে, আপনি ব্যতিক্রমটিও নজরে নাও পেতে পারেন!

— ইঙ্গ্রামটি

+1 আমার অনেক সমস্যা হয়েছে যেখানে লোকেরা কিছু না করে কেবল ব্যতিক্রমগুলি চেষ্টা করে / ট্র্যাকিং বাগের সমস্যা

— হ'ল

আমি মনে করি এমন কোনও মামলা রয়েছে যেখানে আপনি এটি করতে চাইতে পারেন, তবে আপনার কখনও সাধারণ ব্যতিক্রম ধরা উচিত নয়!

— কেসব্যাশ

আপনার উত্তরে @ মার্ককিগ্রাম -1, এবং আপনার মন্তব্যটিকে ন্যায্য প্রমাণ করে +1 করুন। নির্দিষ্ট কিছু অদ্ভুত পরিস্থিতিতে এটি দুর্দান্ত কৌশল তবে এটি সমস্ত বৈধতার জন্য সাধারণভাবে করা উদ্ভট বিষয় বলে মনে হয়।

— মার্ক আমেরিকা

Answer 7

আপনি যদি নিজের প্রোডাকশন কোডে (যেমন রিলিজ বিল্ডস) সংস্থানগুলি চান তবে আপনি ডিবাগ.আস্রেটের পরিবর্তে ট্রেস.আসর্ট ব্যবহার করতে পারেন।

এটি অবশ্যই আপনার উত্পাদন কার্যকর করতে ওভারহেড যুক্ত করে।

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

আপনি এই আচরণটি ডিফল্টট্রেসলিস্টনার অপসারণ করে ওভাররাইড করতে পারেন: এমএসডিএন-তে ট্রেস.লিস্টনারদের জন্য ডকুমেন্টেশনটি দেখুন।

সংক্ষেপে,

• ডিবাগ বিল্ডগুলিতে বাগগুলি ধরার জন্য উদারপন্থী ডিবাগ ব্যবহার করুন।

• আপনি যদি ব্যবহারকারী-ইন্টারফেস মোডে ট্রেস.আসর্ট ব্যবহার করেন তবে আপনি সম্ভবত ব্যবহারকারীদের বিরক্তি থেকে বাঁচতে ডিফল্টট্রেসলিস্টনারটি সরাতে চান।

• আপনি যে শর্তটি পরীক্ষা করছেন সেটি যদি আপনার অ্যাপ্লিকেশনটি পরিচালনা করতে না পারে তবে মৃত্যুদন্ড কার্যকর না হয় তা নিশ্চিত করার জন্য আপনি সম্ভবত একটি ব্যতিক্রম ছুঁড়ে ফেলা ভাল। সচেতন হন যে কোনও ব্যবহারকারী দৃ an়তা উপেক্ষা করার জন্য বেছে নিতে পারেন।

Comments

ডিবাগ.আসর্ট এবং ট্রেস.আসর্টের মধ্যে গুরুত্বপূর্ণ পার্থক্যটি নির্দেশ করার জন্য +1, যেহেতু ওপি বিশেষত উত্পাদন কোড সম্পর্কে জিজ্ঞাসা করেছিল।

— জন কমবস

Answer 8

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

আমি যখন নিশ্চিত না থাকি তখন সাধারণত আমি দৃ over়তার তুলনায় ব্যতিক্রমকে সমর্থন করি।

Answer 9

সংক্ষেপে

Asserts গার্ডের জন্য এবং চুক্তি বাধার দ্বারা ডিজাইন পরীক্ষা করার জন্য ব্যবহৃত হয়, যেমন:

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

জোরের সুবিধাগুলি রয়েছে:

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

... আরো বিস্তারিত

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

কখন আপনার ব্যবহার করা উচিত Asserts? - সিস্টেমের যে কোনও বিন্দুতে, বা লাইব্রেরি এপিআই, বা পরিষেবা যেখানে কোনও শ্রেণীর ফাংশন বা রাজ্যের ইনপুটগুলি বৈধ বলে ধরে নেওয়া হয় (যেমন যখন সিস্টেমের উপস্থাপনা স্তরটিতে ব্যবহারকারীর ইনপুটটিতে ইতিমধ্যে বৈধতা দেওয়া হয়ে থাকে) , ব্যবসায় এবং ডেটা স্তর শ্রেণিগুলি সাধারণত ধরে নেয় যে ইনপুটটিতে নাল চেক, রেঞ্জ চেক, স্ট্রিং দৈর্ঘ্যের চেক ইত্যাদি ইতিমধ্যে সম্পন্ন হয়েছে)। - সাধারণ Assertপরীক্ষাগুলিতে অন্তর্ভুক্ত রয়েছে যেখানে কোনও অবৈধ অনুমানের ফলে নাল বস্তুর অবচয়, শূন্য বিভাজক, সংখ্যাসূচক বা তারিখের গাণিতিক ওভারফ্লো হতে পারে এবং ব্যান্ডের বাইরে সাধারণ / আচরণের জন্য ডিজাইন করা হয়নি (যেমন যদি কোনও 32 বছরের বিস্তৃত কোনও মানুষের বয়সের মডেল ব্যবহার করা হত) , এটি বুদ্ধিমানের কাজ হবে Assertযে বয়সটি আসলে 0 থেকে 125 বা এর মধ্যে - 100-10 এবং 10 ^ 10 এর মানগুলি ডিজাইন করা হয়নি)।

। নেট কোড চুক্তি
। নেট স্ট্যাকে কোড চুক্তিগুলি ছাড়াও বা ব্যবহারের বিকল্প হিসাবে ব্যবহার করা যেতে পারে Debug.Assert। কোড চুক্তিগুলি রাষ্ট্রীয় চেকিংকে আরও আনুষ্ঠানিক করতে পারে এবং ump সংকলন সময়ে (বা তারপরে খুব শীঘ্রই, কোনও আইডিইতে ব্যাকগ্রাউন্ড চেক হিসাবে চালিত হলে) অনুমানের লঙ্ঘন সনাক্ত করতে সহায়তা করতে পারে।

কন্ট্রাক্ট বাই ডিজিট (ডিবিসি) চেকগুলি উপলভ্য:

• Contract.Requires - চুক্তিবদ্ধ পূর্বশর্ত
• Contract.Ensures - চুক্তিবদ্ধ পোস্টকন্ডিশনগুলি
• Invariant - কোনও সামগ্রীর আয়ুটির সমস্ত পয়েন্টে তার অবস্থান সম্পর্কে ধারণা অনুধাবন করে।
• Contract.Assumes - অ-চুক্তিযুক্ত অলঙ্কৃত পদ্ধতিতে কল করা হলে স্থিতিশীল পরীক্ষককে প্রশান্তি দেয়।

Comments

দুর্ভাগ্যক্রমে, এমএস এর বিকাশ বন্ধ করার পরে কোড চুক্তিগুলি সমস্ত মারা গেছে।

— মাইক লোরে

Answer 10

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

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

আমার কাছে এটি ডিবাগ ব্যবহার করে পরামর্শ দেয় s সমস্যাগুলি আপনি অন্য কারও কাছে পিছিয়ে দিচ্ছেন, সমস্যাটি নিজেই ডিল করুন। যদি কিছু মনে করা হয় এবং এটি নিক্ষেপ করা হয় না।

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

Comments

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

— ক্যাস্পার লিওন নিলসন

জন্য +1 "আমি অপছন্দ করি যে এটি একটি ডিবাগ বিল্ড বৈশিষ্ট্যগুলি মুক্তি গড়ে তুলতে বিভিন্ন তোলে। একটি ডিবাগ জাহির ব্যর্থ কিন্তু কার্যকারিতা রিলিজে কাজ করে তারপর কিভাবে এটার কোন মানে হয়, তাহলে?" .NET- এ, System.Diagnostics.Trace.Assert()একটি রিলিজ বিল্ডের পাশাপাশি একটি ডিবাগ বিল্ডে কার্যকর করে।

— ডেভিডআরআর

Answer 11

আইডিজাইন স্ট্যান্ডার্ড অনুসারে আপনার উচিত

প্রতিটি অনুমান জোর দিন। গড়ে, প্রতিটি পঞ্চম লাইনে একটি জোর দেওয়া হয়।

using System.Diagnostics;

object GetObject()
{...}

object someObject = GetObject();
Debug.Assert(someObject != null);

অস্বীকৃতি হিসাবে আমার উল্লেখ করা উচিত আমি এই আইআরএল বাস্তবায়নের জন্য ব্যবহারিক পাই নি। তবে এটি তাদের মান।

Comments

দেখে মনে হচ্ছে জুভাল লোই নিজেকে উদ্ধৃত করতে পছন্দ করে।

— devlord

Answer 12

আপনি কেবলমাত্র রিলিজ বিল্ডগুলির জন্য চেক অপসারণ করতে চান সেখানেই দৃser়তাগুলি ব্যবহার করুন। মনে রাখবেন, আপনি যদি ডিবাগ মোডে সংকলন না করেন তবে আপনার দৃ fire় প্রতিবেদনগুলি অজানা হবে না।

আপনার চেক-অফ-নাল উদাহরণ দেওয়া হয়েছে, এটি যদি কেবলমাত্র অভ্যন্তরীণ এপিআইতে থাকে, আমি সম্ভবত একটি প্রতিস্থাপন ব্যবহার করতে পারি। যদি এটি সর্বজনীন এপিআইতে থাকে তবে আমি স্পষ্টত চেক এবং নিক্ষেপ করব।

Comments

.NET- এ, System.Diagnostics.Trace.Assert()একটি রিলিজ (উত্পাদন) বিল্ডে একটি দৃ exec়তা কার্যকর করতে ব্যবহার করতে পারে।

— ডেভিডআরআর

কোড বিশ্লেষণের নিয়ম CA1062: সর্বজনীন পদ্ধতির যথাযথ যুক্তিগুলির জন্য একটি যুক্তি যাচাই করা দরকারnull : "বাহ্যিকভাবে দৃশ্যমান পদ্ধতিটি এই যুক্তিটি নাল কিনা তা যাচাই না করেই তার একটি রেফারেন্স আর্গুমেন্টকে dereferences "। এমন পরিস্থিতিতে পদ্ধতি বা সম্পত্তি নিক্ষেপ করা উচিত ArgumentNullException।

— ডেভিডআরআর

Answer 13

সমস্ত দাবীগুলি এমন কোড হওয়া উচিত যা এতে অনুকূলিত হতে পারে:

Debug.Assert(true);

কারণ এটি এমন কিছু যাচাই করে যা আপনি ইতিমধ্যে ধরে নিয়েছেন সত্য। উদাহরণ:

public static void ConsumeEnumeration<T>(this IEnumerable<T> source)
{
  if(source != null)
    using(var en = source.GetEnumerator())
      RunThroughEnumerator(en);
}
public static T GetFirstAndConsume<T>(this IEnumerable<T> source)
{
  if(source == null)
    throw new ArgumentNullException("source");
  using(var en = source.GetEnumerator())
  {
    if(!en.MoveNext())
      throw new InvalidOperationException("Empty sequence");
    T ret = en.Current;
    RunThroughEnumerator(en);
    return ret;
  }
}
private static void RunThroughEnumerator<T>(IEnumerator<T> en)
{
  Debug.Assert(en != null);
  while(en.MoveNext());
}

উপরে, নাল প্যারামিটারে তিনটি পৃথক পদ্ধতি রয়েছে appro প্রথমটি এটি অনুমোদিত হিসাবে গ্রহণ করে (এটি কেবল কিছুই করে না)। দ্বিতীয়টি কলিং কোডটি হ্যান্ডেল করার জন্য একটি ব্যতিক্রম ছুঁড়েছে (বা না, ত্রুটির বার্তার ফলে)। তৃতীয় ধরে নিয়েছে এটি সম্ভবত ঘটতে পারে না, এবং দৃser়ভাবে জানায় যে এটি এমনই।

প্রথম ক্ষেত্রে, কোনও সমস্যা নেই।

দ্বিতীয় ক্ষেত্রে, কলিং কোডটিতে একটি সমস্যা আছে - এটি GetFirstAndConsumeনাল দিয়ে কল করা উচিত নয় , সুতরাং এটি একটি ব্যতিক্রম ফিরে পায়।

তৃতীয় ক্ষেত্রে, এই কোডটিতে একটি সমস্যা আছে, কারণ এটি ইতিমধ্যে এটি যাচাই করা উচিত ছিল en != null আগে কখনও বলা হয়েছিল আগে এটি আগেই ছিল, যাতে এটি সত্য না হয় এটি একটি বাগ। বা অন্য কথায়, এটি এমন কোড হওয়া উচিত যা তাত্ত্বিকভাবে অপ্টিমাইজ করা যেতে পারে Debug.Assert(true), sicne en != nullসর্বদা হওয়া উচিত true!

Comments

সুতরাং, তৃতীয় ক্ষেত্রে, en == nullপ্রযোজনায় কি হবে ? আপনি সম্ভবত এই বলে যে en == nullপারেন না ঘটতে উৎপাদনে (যেহেতু প্রোগ্রাম পুঙ্খানুপুঙ্খভাবে debugged হয়েছে)? যদি তা Debug.Assert(en != null)হয় তবে খুব কম সময়ে মন্তব্যের বিকল্প হিসাবে কাজ করে। অবশ্যই, যদি ভবিষ্যতে পরিবর্তনগুলি করা হয় তবে এটির সম্ভাব্য রিগ্রেশন সনাক্তকরণের মানও অবিরত রয়েছে।

— ডেভিডআরআর

@ ডেভিডআর, আমি সত্যিই দৃ am়ভাবে বলছি যে এটি কখনই বাতিল হতে পারে না, এবং কোডের মধ্যে দৃ .়তা, তাই নাম। আমি অবশ্যই ভুল হতে পারি, বা একটি পরিবর্তন দ্বারা ভুল হতে পারে, এবং এটি দাবী কল মূল্য।

— জন হান্না

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

— ডেভিডআরআর

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

— জন হান্না

Answer 14

আমি ভেবেছিলাম আমি আরও চারটি কেস যুক্ত করব, যেখানে ডিবাগ sএসেটরটি সঠিক পছন্দ হতে পারে।

1) আমি এখানে উল্লিখিত কিছু দেখিনি যা হ'ল স্বয়ংক্রিয় পরীক্ষার সময় সংস্থাগুলি অতিরিক্ত ধারণাগত কভারেজ সরবরাহ করতে পারে । একটি সাধারণ উদাহরণ হিসাবে:

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

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

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

2) অতিরিক্তভাবে, কিছু পরীক্ষা লিখতে সহজ, তবে প্রাথমিক অনুমানগুলি দেওয়া উচ্চ-ব্যয়বহুল এবং অপ্রয়োজনীয় । উদাহরণ স্বরূপ:

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

3) এরপরে, কিছু ক্ষেত্রে রিলিজ মোডে স্থাপনের সময় আপনার পণ্যটির সমস্ত বা তার ক্রিয়াকলাপের অংশগুলির জন্য কোনও সহায়ক ডায়াগোনস্টিক ইন্টারঅ্যাকশন নাও থাকতে পারে । উদাহরণ স্বরূপ:

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

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

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

Answer 15

প্র্যাকমেটিক প্রোগ্রামার থেকে নেওয়া উদ্ধৃতি : জার্নম্যান থেকে মাস্টার

জোর তদবির চালু করুন

সংস্থাগুলি এবং ভাষার পরিবেশ লেখেন এমন লোকেদের দ্বারা উত্থাপিত দাবি সম্পর্কে একটি সাধারণ ভুল ধারণা রয়েছে। এইটার মতো কিছু একটা হচ্ছে:

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

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

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

আপনি যখন কোনও প্রোগ্রাম উত্পাদনে পৌঁছে দেন তখন দৃser়তা বন্ধ করা জাল ছাড়াই একটি উচ্চ তারের অতিক্রম করার মতো কারণ আপনি একবারে বাস্তবে এটি তৈরি করেছিলেন । নাটকীয় মান রয়েছে তবে জীবন বীমা পাওয়া শক্ত।

এমনকি আপনার যদি পারফরম্যান্স সংক্রান্ত সমস্যা না থাকে তবে কেবলমাত্র সেই উক্তিগুলি বন্ধ করুন যা আপনাকে সত্যই আঘাত করেছে ।

Answer 16

আপনার সর্বদা দ্বিতীয় পদ্ধতির ব্যবহার করা উচিত (ব্যতিক্রম ছোঁড়া)।

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

Comments

নাহ, এখানে অন্য কয়েকটি উত্তর হিসাবে একই: আপনি সত্যিকারের পার্থক্যটি বুঝতে পারবেন না তাই আপনি যে কোনও অফারটি বেছে নেবেন, প্রক্রিয়াটিতে তাদের মধ্যে একটি মিথ্যা দ্বিধ্বনি স্থাপন করুন। ডাব্লু

— ক্যাস্পার লিওন নিলসন

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

— justin.m.chase

এটি এখানে আপনার আলোচনায় ট্রেসকে অন্তর্ভুক্ত করা সহায়ক।

— জন কুমবস

Answer 17

আপনার প্রোগ্রামগুলিতে লজিকাল ত্রুটির জন্য পরীক্ষা করতে আপনার ডিবাগ.সেটার ব্যবহার করা উচিত। সংকলক কেবল সিনট্যাক্স ত্রুটি সম্পর্কে আপনাকে অবহিত করতে পারে। সুতরাং আপনার যৌক্তিক ত্রুটির জন্য পরীক্ষার জন্য সংজ্ঞা বিবরণী সংজ্ঞায়িতভাবে ব্যবহার করা উচিত। যেমন এমন কোনও গাড়ি বিক্রি করে এমন একটি প্রোগ্রামের পরীক্ষা করা বলুন যা কেবলমাত্র নীল রঙের BMWs একটি 15% ছাড় পান। আপনার প্রোগ্রামটি এটি সম্পাদন করার ক্ষেত্রে যুক্তিযুক্তভাবে সঠিক কিনা তবে জোর দেওয়া বিবৃতিটি পারে তা সম্পর্কে কমপ্লায়ার আপনাকে কিছুই বলতে পারে না।

Comments

দুঃখিত তবে ব্যতিক্রমগুলি একই জিনিসগুলি করে, তাই এই উত্তরটি আসল প্রশ্নের সমাধান করে না।

— রোমান স্টারকভ

Answer 18

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

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

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

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

using System.Diagnostics;

public class ExceptionTraceListener : DefaultTraceListener
{
    [DebuggerStepThrough]
    public override void Fail(string message, string detailMessage)
    {
        throw new AssertException(message);
    }
}

public class AssertException : Exception
{
    public AssertException(string message) : base(message) { }
}

এবং উত্পাদন কনফিগারেশন ফাইলটিতে:

<system.diagnostics>
  <trace>
    <listeners>
      <remove name="Default"/>
      <add name="ExceptionListener" type="Namespace.ExceptionTraceListener,AssemblyName"/>
    </listeners>
  </trace>
 </system.diagnostics>

Answer 19

এটি সি # এবং .NET- তে কীভাবে আছে তা আমি জানি না, তবে সি-তে কেবল () কাজ করবে যখন -DDEBUG- র সাথে সংকলিত হয় - এন্ডু ইউজার কখনই সংক্ষিপ্ত বিবরণ দেখতে পাবে না যদি এটি সংকলিত হয় তবে। এটি কেবল বিকাশকারীদের জন্য। আমি এটি প্রায়শই ব্যবহার করি, কখনও কখনও বাগগুলি ট্র্যাক করা সহজ।

Answer 20

আমি তাদের প্রডাকশন কোডে ব্যবহার করব না। ব্যতিক্রম নিক্ষেপ করুন, ধরুন এবং লগ করুন।

এ্যাসপ নেট-তে সাবধানতা অবলম্বন করা দরকার, যেমন একটি দৃsert়তা কনসোলে প্রদর্শিত হতে পারে এবং অনুরোধগুলি গুলি স্থির করে দিতে পারে।