দুষ্টের দোষ কি? [বন্ধ]

Question

Goভাষা স্রষ্টাদের লিখতে :

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

এ সম্পর্কে আপনার মতামত কী?

Comments

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

— অ্যালিওরকোড

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

— ইগর ডুবিনস্কি

না, আমি এটাই বলছি না। প্রতিবিম্ব ছাড়াই স্লাইস 1 == স্লাইস 2 বলে কোনও জিনিস নেই। অন্যান্য সমস্ত ভাষার এই সুপার বেসিক অপারেশনের সমতুল্য। গো না করার একমাত্র কারণ হল কুসংস্কার।

— এলিউরকোড

আপনি forগো (যেমন সি এর মত) ব্যবহার করে প্রতিচ্ছবি ছাড়াই দুটি স্লাইসের তুলনা করতে পারেন । এটা তোলে হবে , সত্যিই জেনেরিক ফালি অপারেশন আছে চমৎকার হতে যদিও তুলনা জটিল পরার যখন পয়েন্টার এবং structs জড়িত হয়।

— kbolino

Answer 1

না, assertযতক্ষণ আপনি এটি উদ্দেশ্য হিসাবে ব্যবহার করেন ততক্ষণ কোনও সমস্যা নেই ।

এটি, সাধারণ ত্রুটি পরিচালনার বিপরীতে, এটি ডিবাগিংয়ের সময়, "ঘটতে পারে না" এমন কেস ধরার জন্য বলে মনে করা হয়।

• জোর দেওয়া: প্রোগ্রামটির যুক্তিতে নিজেই একটি ব্যর্থতা।
• ত্রুটি পরিচালনায়: প্রোগ্রামে কোনও বাগের কারণে নয় এমন একটি ভ্রান্ত ইনপুট বা সিস্টেমের অবস্থা।

Answer 2

না, না gotoমন্দও নয় assert। তবে দু'জনেরই অপব্যবহার করা যায়।

দৃsert়তা চেক পরীক্ষা জন্য হয়। জিনিসগুলি সঠিক না হলে প্রোগ্রামটি মেরে ফেলা উচিত। বৈধতার জন্য বা ত্রুটি পরিচালনা করার জন্য প্রতিস্থাপন হিসাবে নয়।

Comments

gotoবুদ্ধিমান ব্যবহার কিভাবে ?

— ar2015

@ ar2015 কিছু লোক নিখুঁতভাবে gotoধর্মীয় কারণে এড়াতে পরামর্শ দেয় এমন অযৌক্তিকভাবে নিখুঁত নিদর্শনগুলির মধ্যে একটি খুঁজুন, তবে আপনি যা করছেন তা অবলম্বন না করে কেবল ব্যবহার করুন goto। অন্য কথায়: যদি আপনি প্রমাণ করতে পারেন যে আপনার সত্যই প্রয়োজন goto, এবং একমাত্র বিকল্প হ'ল অর্থহীন ভাস্কর্যটি বোঝানো যা শেষ পর্যন্ত একই কাজ করে কিন্তু গোটো পুলিশকে পরিবর্তন না করেই ... তবে কেবল ব্যবহার করুন goto। অবশ্যই, এর একটি পূর্বশর্ত হ'ল "যদি আপনি সত্যিকারের প্রয়োজন প্রমাণ করতে পারেন goto"। প্রায়শই, মানুষ না। তারপরেও এর অর্থ এই নয় যে এটি সহজাতভাবে একটি খারাপ জিনিস।

— আন্ডারস্কোর_

gotoকোড সাফ করার জন্য লিনাক্স কার্নেলে ব্যবহৃত হয়

— মালাত

Answer 3

এই যুক্তি অনুসারে ব্রেকপয়েন্টগুলিও খারাপ।

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

আপনারা, প্রোগ্রামারটিকে সনাক্ত করতে এবং সমস্যাগুলি সমাধান করতে এবং অস্তিত্বের অস্তিত্ব অবশ্যই নেই এবং আপনার অনুমানগুলি সত্য থেকে যায় তা যাচাই করার জন্য জোর রয়েছে।

ত্রুটি পরিচালনার সাথে তাদের কোনও যোগসূত্র নেই, তবে দুর্ভাগ্যক্রমে, কিছু প্রোগ্রামার তাদের এগুলি অপব্যবহার করে এবং তারপরে তাদের "দুষ্টু" বলে ঘোষণা করে।

Answer 4

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

দৃser়তার কারণে আমি কোডিং / ডিবাগিং প্রোগ্রামগুলিতে প্রচুর সময় ব্যয় করি।

আমি এটিও লক্ষ্য করেছি যে দাবীগুলি আমাকে আমার প্রোগ্রামগুলিকে ভেঙে দিতে পারে এমন অনেকগুলি বিষয় চিন্তা করতে সহায়তা করে।

Answer 5

অতিরিক্ত তথ্য হিসাবে, গো একটি অন্তর্নির্মিত ফাংশন সরবরাহ করে panic। এটি জায়গায় ব্যবহার করা যেতে পারে assert। যেমন

if x < 0 {
    panic("x is less than 0");
}

panicস্ট্যাক ট্রেস প্রিন্ট করবে, তাই কোনওভাবে এটির উদ্দেশ্য রয়েছে assert।

Answer 6

প্রোগ্রামে বাগ সনাক্ত করার জন্য এগুলি ব্যবহার করা উচিত। খারাপ ব্যবহারকারী ইনপুট নয়।

যদি সঠিকভাবে ব্যবহার করা হয় তবে এগুলি মন্দ নয় ।

Answer 7

এটি অনেকটা সামনে আসে এবং আমি মনে করি যে একটি সমস্যা যা বিভ্রান্তিকর দাবিগুলির সুরক্ষা তৈরি করে তা হ'ল তারা প্রায়শই যুক্তি যাচাইয়ের উপর ভিত্তি করে থাকে। সুতরাং আপনি কখন একটি দৃser়তা ব্যবহার করতে পারেন তার এই আলাদা উদাহরণটি বিবেচনা করুন:

build-sorted-list-from-user-input(input)

    throw-exception-if-bad-input(input)

    ...

    //build list using algorithm that you expect to give a sorted list

    ...

    assert(is-sorted(list))

end

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

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

Answer 8

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

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

দাবিগুলির সাথে আরও একটি সমস্যা রয়েছে। জোর কেবল রান-টাইমে পরীক্ষা করা হয়। তবে প্রায়শই এমন হয় যে আপনি যে চেকটি সম্পাদন করতে চান তা সংকলন-সময়ে সম্পাদন করা যেতে পারে। সংকলনের সময় কোনও সমস্যা সনাক্ত করা ভাল। সি ++ প্রোগ্রামারদের জন্য, BOOST_STATIC_ASSERT সরবরাহ করে যা আপনাকে এটি করতে দেয়। সি প্রোগ্রামারদের জন্য, এই নিবন্ধটি ( লিঙ্ক পাঠ্য ) এমন একটি কৌশল বর্ণনা করেছে যা সংকলন সময়ে দৃser়তার সাথে সম্পাদন করতে ব্যবহৃত হতে পারে।

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

Answer 9

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

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

Answer 10

আমি এমন কোড এড়ানো পছন্দ করি যা ডিবাগ এবং প্রকাশে বিভিন্ন কাজ করে।

একটি শর্তে ডিবাগারে ব্রেক এবং সমস্ত ফাইল / লাইন তথ্য থাকা দরকারী, সঠিক অভিব্যক্তি এবং সঠিক মানও।

"কেবলমাত্র ডিবাগের শর্তটি মূল্যায়ন করবে" এমন দৃsert়তা থাকা একটি পারফরম্যান্স অপটিমাইজেশন হতে পারে এবং যেমন কেবলমাত্র 0.0001% প্রোগ্রামে দরকারী - যেখানে লোকেরা জানে যে তারা কী করছে। অন্যান্য সমস্ত ক্ষেত্রে এটি ক্ষতিকারক, কারণ এক্সপ্রেশনটি আসলে প্রোগ্রামের স্থিতি পরিবর্তন করতে পারে:

assert(2 == ShroedingersCat.GetNumEars()); প্রোগ্রামটি ডিবাগ এবং প্রকাশের বিভিন্ন কাজ করতে পারে make

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

Comments

যুক্তিতে ব্যবহৃত 90% পরিসংখ্যান মিথ্যা।

— জোও পোর্তেলা

Answer 11

আমি দৃ intense়ভাবে দৃ dis়ভাবে দাবি অপছন্দ করি। তারা যতদূর খারাপ বলে আমি ততদূর যেতে চাই না।

মূলত একটি দাবী অচেনা ব্যতিক্রমের মতো একই কাজ করবে, একমাত্র ব্যতিক্রম হ'ল চূড়ান্ত পণ্যটির জন্য দৃsert়তা (সাধারণত) রাখা উচিত নয়।

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

সুতরাং আমি পুরোপুরি জমিগুলি সরিয়ে এবং প্রোগ্রামারদের পরিস্থিতি পরিচালনা করতে ব্যতিক্রমী ব্যবহার করে জোর করে গো এর নির্মাতাদের পুরোপুরি বুঝতে পারি। এর জন্য একটি সহজ ব্যাখ্যা আছে, ব্যতিক্রম হ'ল কাজের জন্য একটি আরও ভাল প্রক্রিয়া কেন প্রত্নসম্পর্কীয় দাবির সাথে লেগে থাকে?

Comments

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

— নীড় ফ্রিডম্যান

Answer 12

সংক্ষিপ্ত উত্তর: না, আমার বিশ্বাস দৃ as়তা কার্যকর হতে পারে

Answer 13

আমি সম্প্রতি আমার কোডে কিছু যুক্তি যুক্ত করা শুরু করেছি এবং আমি এটি এভাবেই করে যাচ্ছি:

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

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

void Class::f (int value) {
    assert (value < end);
    member = value;
}

এবং কোনও ফাংশন যা কোনও নেটওয়ার্ক থেকে ইনপুট পায় এটি পড়তে পারে:

void Class::g (InMessage & msg) {
    int const value = msg.read_int();
    if (value >= end)
        throw InvalidServerData();
    f (value);
}

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

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

Answer 14

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

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

জোর দেওয়ার কিছু বিকল্প:

• একটি ডিবাগার ব্যবহার করে,
• কনসোল / ডাটাবেস / অন্যান্য লগিং
• ব্যতিক্রমসমূহ
• অন্য ধরণের ত্রুটি পরিচালনা করা

কিছু তথ্যসূত্র:

• http://ftp.gnu.org/old-gnu/Manuals/nana-1.14/html_node/nana_3.html
• http://www.lenholgate.com/blog/2005/09/assert-is-evil.html
• গো দৃ as়তা প্রদান করে না এবং এর ভাল কারণ রয়েছে: http://golang.org/doc/faq# ঠিকানা ser
• http://c2.com/cgi/wiki?DoNotUseAssertions

এমনকি যে ব্যক্তিরা দৃsert়তার পক্ষে ছিলেন তাদের ধারণা তারা কেবলমাত্র উন্নয়নে নয় , উন্নয়নের ক্ষেত্রে ব্যবহার করা উচিত :

• http://codebetter.com/gregyoung/2007/12/12/asserts-are-not-evil/
• http://www.codeproject.com/Articles/6404/Assert-is-your-friend
• http://parabellumgames.wordpress.com/using-asserts-for-debugging/

এই ব্যক্তিটি বলেছেন যে মডিউলটি কোনও ব্যতিক্রম ছুঁড়ে ফেলার পরে অব্যাহত থাকার পরেও মডিউলটিতে সম্ভাব্যভাবে দূষিত ডেটা থাকবে তখন জমিগুলি ব্যবহার করা উচিত: http://www.advogato.org/article/949.html । এটি অবশ্যই একটি যুক্তিসঙ্গত পয়েন্ট, তবে, কোনও বহিরাগত মডিউল কখনই কল করে না যে কলিং প্রোগ্রামের জন্য দূষিত ডেটা (তাদের "জন্য" প্রস্থান করে) কতটা গুরুত্বপূর্ণ pres এটি পরিচালনা করার সঠিক উপায় হ'ল একটি ব্যতিক্রম ছুঁড়ে দেওয়া যা এটি স্পষ্ট করে দেয় যে প্রোগ্রামটি এখন কোনও বেমানান অবস্থায় থাকতে পারে। এবং যেহেতু ভাল প্রোগ্রামগুলি বেশিরভাগ মডিউল নিয়ে থাকে (মূল নির্বাহের ক্ষেত্রে কিছুটা আঠালো কোড সহ), তাই দৃser়ভাবে বলা প্রায়শই ভুল কাজ।

Answer 15

assert খুব কার্যকর এবং এটি সমস্যার প্রথম লক্ষণগুলিতে প্রোগ্রামটি থামিয়ে অপ্রত্যাশিত ত্রুটি দেখা দিলে আপনাকে প্রচুর ব্যাকট্র্যাকিং করতে বাঁচাতে পারে।

অন্যদিকে, এটি অপব্যবহার করা খুব সহজ assert।

int quotient(int a, int b){
    assert(b != 0);
    return a / b;
}

সঠিক, সঠিক সংস্করণটি এমন কিছু হবে:

bool quotient(int a, int b, int &result){
    if(b == 0)
        return false;

    result = a / b;
    return true;
}

তাই ... দীর্ঘমেয়াদে ... বড় ছবিতে ... আমাকে অবশ্যই সম্মতি assertজানাতে হবে যে অপব্যবহার করা যেতে পারে। আমি সব সময় এটা।

Answer 16

assert টাইপিং কম হওয়ায় ত্রুটি পরিচালনার জন্য অপব্যবহার করা হচ্ছে।

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

Comments

খুব খারাপ নয় :-) ব্যতিক্রম বা না, জোর দেওয়া বা না, গো ভক্তরা কোডগুলি কত সংক্ষিপ্ত তা নিয়ে এখনও কথা বলছেন।

— মোশে রেভাঃ

Answer 17

লেখককে মাথায় লাথি মারার মতো অনুভব করলাম যখন দেখলাম।

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

ব্যতিক্রমগুলি উত্পাদন কোডের সাথে আরও সহজে মিশ্রিত হয় যা আমি পছন্দ করি না। একটি দৃsert়তা তুলনায় লক্ষ্য করা সহজthrow new Exception("Some generic msg or 'pretend i am an assert'");

Answer 18

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

Comments

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

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

— ইভান ক্যারল

আমি সিদ্ধান্ত নিয়েছি উদাহরণের পরিস্থিতি সবচেয়ে ভাল। Heres একটি সহজ। int func (int i) {if (i> = 0) so কনসোল.উইট ("সংখ্যাটি ধনাত্মক {0}", i); } অন্য {দৃsert় (মিথ্যা); // negativeণাত্মক এটিএম করতে অলস করতে} আমি আই * 2 ফেরান; <- আমি কীভাবে দৃser়তা ছাড়াই এটি করব এবং ব্যতিক্রমটি কী আরও ভাল? এবং মনে রাখবেন, এই কোডটি প্রকাশের আগে কার্যকর করা হবে।

অবশ্যই ব্যতিক্রমগুলি আরও ভাল, এর জন্য আমি বলি যে আমি ব্যবহারকারীর ইনপুট নিই এবং func()নেতিবাচক নম্বর দিয়ে কল করি । এখন, হঠাৎ আপনার এই দৃ with়তার সাথে আপনি আমার নীচে থেকে কার্পেটটি টানলেন এবং আমাকে পুনরুদ্ধার করার সুযোগ দেবেন না, বরং আমি যা অনুরোধ করছি তা বিনয়ের সাথে জানাতে পারি না। প্রোগ্রামটিকে দুর্ব্যবহার করা হয়েছে এবং এটি একটি উদ্ধৃতি প্রদানের জন্য দোষের কিছু নেই: সমস্যা হ'ল আপনি কোনও আইন প্রয়োগের কাজটি ঝাপসা করছেন, এবং দোষীদের সাজা দিয়েছেন।

— ইভান ক্যারল

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

Answer 19

হ্যাঁ, জোর দেওয়া খারাপ।

প্রায়শই এগুলিতে এমন স্থানে ব্যবহৃত হয় যেখানে সঠিক ত্রুটি পরিচালনার ব্যবহার করা উচিত। শুরু থেকে সঠিক উত্পাদন মানের ত্রুটি হ্যান্ডলিং লিখতে অভ্যস্ত হয়ে উঠুন!

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

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

কখনও কখনও তারা অন্যথায় ভাঙা নকশার ক্র্যাচ হয়; অর্থাত্ কোডটির নকশাটি কোনও ব্যবহারকারীকে এমনভাবে কল করার অনুমতি দেয় যাতে এটি কল করা উচিত নয় এবং দৃ the়তা এটিকে "আটকায়"। নকশা ঠিক করুন!

আমি আমার ব্লগে 2005 এ ফিরে এ সম্পর্কে আরও লিখেছিলাম: http://www.lenholgate.com/blog/2005/09/assert-is-evil.html

Answer 20

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

Comments

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

— পিটার কর্ডেস

Answer 21

আমি কখনও দৃsert়তা () ব্যবহার করি না, উদাহরণগুলি সাধারণত এ জাতীয় কিছু দেখায়:

int* ptr = new int[10];
assert(ptr);

এটি খারাপ, আমি কখনই এটি করি না, যদি আমার গেমটি একগুচ্ছ দানব বরাদ্দ করে তবে কী হবে? আমি কেন গেমটি ক্র্যাশ করব, পরিবর্তে আপনার ত্রুটিগুলি নিখুঁতভাবে পরিচালনা করা উচিত, সুতরাং এর মতো কিছু করুন:

CMonster* ptrMonsters = new CMonster[10];
if(ptrMonsters == NULL) // or u could just write if(!ptrMonsters)
{
    // we failed allocating monsters. log the error e.g. "Failed spawning 10 monsters".
}
else
{
    // initialize monsters.
}

Comments

newকখনই ফিরে আসে না nullptr, ছুড়ে দেয়

— ডেভিড স্টোন 15

নোট করুন যে আপনি এর জন্য std :: nothrow ব্যবহার করতে পারেন ।

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