ডিবাগ.এসার্ট বনাম ব্যতিক্রম ছোঁড়া

Question 1

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

সুতরাং, কেন আমি, যদি কিছু না হয়, তবে Debug.Assertএকটি সরল ব্যতিক্রমের পরিবর্তে ব্যবহার করব ? এটি হওয়া উচিত নয় যেখানে একটি দৃ as়তা রাখা কেবলমাত্র সমস্ত ধরণের "অযাচিত আচরণ" সৃষ্টি করতে পারে, সুতরাং আমার দৃষ্টিতে আমি ব্যতিক্রম ছোঁড়ার পরিবর্তে একটি দৃ using়তা ব্যবহার করে কিছুই অর্জন করতে পারি না। আপনি কি আমার সাথে একমত, বা আমি এখানে কিছু মিস করছি?

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

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

Question 2

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

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

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

সে কারণেই আমি একটি ব্যতিক্রমের সাথে একটি দৃ replace় প্রতিস্থাপন করব না। যদি দাবিটি প্রকৃতপক্ষে আগুন দিতে না পারে, তবে এটির ব্যতিক্রমের সাথে প্রতিস্থাপনের অর্থ আপনার প্রোগ্রামে একটি অস্ট্রেলীয় কোড পাথ রয়েছে । আমি অচিরাচরিত কোড পাথ অপছন্দ করি।

Question 3

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

"ঘটতে পারে না" এমন শর্তগুলির জন্য পরীক্ষা জোর দেয়। ব্যতিক্রম এমন শর্তের জন্য যা "ঘটবে না তবে করা উচিত" for

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

যদি আপনি দৃser়তার পরিবর্তে ব্যতিক্রমগুলি ব্যবহার করেন তবে আপনি কিছু মান হারাবেন:

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

আরও এখানে: http://nedbatchelder.com/text/assert.html

Question 4

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

আমি আমার নিজের কথায় একটি উত্তর লিখতে যাচ্ছিলাম তবে এটি ধারণার চেয়ে আমার চেয়ে ভাল ন্যায়বিচার করবে:

সি # স্টেশন: জোর

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

অবস্থার পরীক্ষা করার জন্য একটি দৃser়তা সর্বোত্তমভাবে ব্যবহৃত হয় কেবল যখন নীচের সমস্তগুলি হোল্ড করে:
* the condition should never be false if the code is correct,
* the condition is not so trivial so as to obviously be always true, and
* the condition is in some sense internal to a body of software.
সফ্টওয়্যারটির স্বাভাবিক ক্রিয়াকলাপের সময় উদ্ভূত পরিস্থিতি সনাক্ত করতে দৃ never়তার সাথে প্রায়শই ব্যবহার করা উচিত নয়। উদাহরণস্বরূপ, সাধারণত দৃ as়তাগুলি কোনও ব্যবহারকারীর ইনপুটটিতে ত্রুটিগুলি পরীক্ষা করার জন্য ব্যবহার করা উচিত নয়। তবে, একজন কলার ইতিমধ্যে কোনও ব্যবহারকারীর ইনপুটটি চেক করেছেন কিনা তা যাচাই করতে এই অবস্থানগুলি ব্যবহার করার জন্য এটি বোধগম্য হতে পারে।

মূলত, উত্পাদনের অ্যাপ্লিকেশনটিতে যে জিনিসগুলি ধরা / মোকাবেলা করা দরকার সেগুলির জন্য ব্যতিক্রমগুলি ব্যবহার করুন, যৌক্তিক চেকগুলি সম্পাদনের জন্য দৃ use়তাগুলি ব্যবহার করুন যা উন্নয়নের পক্ষে কার্যকর তবে উত্পাদন বন্ধ হয়ে যায়।

Question 5

আমি মনে করি একটি (অনুমোদিত) ব্যবহারিক উদাহরণ পার্থক্য আলোকিত করতে সহায়তা করতে পারে:

( মোরলিঙ্কের ব্যাচের এক্সটেনশান থেকে অভিযোজিত )

// 'public facing' method
public int DoSomething(List<string> stuff, object doohickey, int limit) {

    // validate user input and report problems externally with exceptions

    if(stuff == null) throw new ArgumentNullException("stuff");
    if(doohickey == null) throw new ArgumentNullException("doohickey");
    if(limit <= 0) throw new ArgumentOutOfRangeException("limit", limit, "Should be > 0");

    return DoSomethingImpl(stuff, doohickey, limit);
}

// 'developer only' method
private static int DoSomethingImpl(List<string> stuff, object doohickey, int limit) {

    // validate input that should only come from other programming methods
    // which we have control over (e.g. we already validated user input in
    // the calling method above), so anything using this method shouldn't
    // need to report problems externally, and compilation mode can remove
    // this "unnecessary" check from production

    Debug.Assert(stuff != null);
    Debug.Assert(doohickey != null);
    Debug.Assert(limit > 0);

    /* now do the actual work... */
}

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

Question 6

কোড সম্পূর্ণ থেকে আর একটি ন্যাগেট :

"একটি দৃser়তা হ'ল একটি ফাংশন বা ম্যাক্রো যা যদি অনুমানটি সত্য না হয় তবে উচ্চস্বরে অভিযোগ করে code কোডে তৈরি অনুমানগুলি নথি করতে এবং অপ্রত্যাশিত অবস্থার বাইরে বেরিয়ে আসার জন্য দৃser়তা ব্যবহার করুন ... ...

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

কী জোর দেওয়া উচিত এবং কী করা উচিত নয় সে সম্পর্কে তিনি কিছু গাইডলাইন যুক্ত করেন।

অন্যদিকে, ব্যতিক্রমগুলি:

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

আপনার কাছে এই বইটি না থাকলে আপনার এটি কিনতে হবে।

Question 7

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

Question 8

যে জিনিসগুলি সম্ভব হয়েছে তার জন্য দৃser়তাগুলি ব্যবহার করুন তবে এটি হওয়া উচিত নয় (যদি এটি অসম্ভব হত তবে আপনি কেন দৃ .় বক্তব্য রাখবেন?)।

একটি শব্দ ব্যবহার করে কেসের মতো না Exception? আপনি কেন একটি পরিবর্তে একটি দৃ use়তা ব্যবহার করবেন Exception?

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

সাধারণত আপনার আগে এমন কোনও কোড নেই Exceptionযা গ্যারান্টি দেয় যে এটি ফেলে দেওয়া হবে না।

Debug.Assert()প্রোডে সংকলিত এটি কেন ভাল ? আপনি যদি ডিবাগ-এ এটি সম্পর্কে জানতে চান তবে আপনি কি প্রোডে এটি সম্পর্কে জানতে চান না?

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

Question 9

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