আমি কীভাবে আমার ত্রুটি পরীক্ষা করা এবং পরিচালনা করা উন্নত করতে পারি?


13

ইদানীং আমি চেক করার সঠিক পরিমাণটি কী এবং সঠিক পদ্ধতিগুলি কী তা বোঝার জন্য সংগ্রাম করে চলেছি।

এ সম্পর্কে আমার কয়েকটি প্রশ্ন রয়েছে:

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

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

Malloc returning null, check explictly
API user inserting odd input for functions, use asserts

ত্রুটি পরীক্ষায় এটি কি আমাকে আরও ভাল করে তুলবে? আমি আর কী করতে পারেন? আমি সত্যিই আরও উন্নত করতে চাই, 'পেশাদার' কোডটি লিখতে চাই।


3
ভাল প্রশ্ন, তবে আমি মনে করি এটি কোনও বোন সাইটের (প্রোগ্রামার?) এর জন্য ভাল উপযুক্ত।

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

3
সহজ উত্তরটি হ'ল "এ কারণেই ব্যতিক্রমগুলি আবিষ্কার করা হয়েছিল a আরও ভাল ভাষা পান।"
ডেডএমজি

1
@ ডেডএমজি: setjmp/ longjmpসি তে উপলব্ধ, সুতরাং আপনার কোনও নতুন ভাষার প্রয়োজন নেই।
ব্যবহারকারী 786653

3
@ ডিএডএমজি: যে কেউ সি ত্রুটি সঠিকভাবে পরীক্ষা করতে পারে না তার জন্য সি ++ ব্যতিক্রম হ্যান্ডলিংয়ের অধিকার পেতে নরকে একটি তুষারপাতের সুযোগ রয়েছে ...
কোডার

উত্তর:


4

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


2

যে কোনও সময় যেকোন সময় যাচাই করুন (এটি আপনার শেষ চেকের পরে পরিবর্তিত হতে পারে) যা আপনার আদেশের অধীনে 100% নয় । এবং এছাড়াও: বিকাশের সময় এমনকি নিজেকে বিশ্বাস করবেন না! ;-)

Okokok ... "কিছু" এই ধরনের জিনিস যা কারণ হবে চেক হিসেবে পড়ার বোঝানো হয় অস্বাভাবিক পরিত্যাগ কিছু যা আপনার আবেদন / সিস্টেম বানাতে পারে না জিনিস এটা উচিত না না।

গুরুতর হওয়ার জন্য, শেষ বাক্যটির শেষ অংশটি অপরিহার্য কারণ এটি মূল সমস্যার দিকে ইঙ্গিত করে:

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


1
'সবকিছু চেক করুন' এর জন্য +1। আমি কোড গণ্ডগোলের যুক্তিটি কিনছি না: যে কোনও প্রোগ্রামার ত্রুটি পরীক্ষা করা এবং প্রকৃত যুক্তির মধ্যে পার্থক্য করতে সক্ষম হওয়া উচিত।
stijn

2

ত্রুটিটি পরিচালনা করার ক্রুস আপনি কীভাবে এবং কীভাবে সমস্যাটি ধরেন তা নয়। এটি সম্পর্কে জানার পরে আপনি যা করেন তা এটি আরও বেশি ।

প্রথমে - আমি বলব, অধীনস্ত পদ্ধতিতে ফিরে আসা কোনও একক ত্রুটিটি কেন পরিচালনা করা উচিত নয় তার কোনও কারণ নেই। এবং ত্রুটি এবং ব্যতিক্রমগুলি রিটার্ন মানগুলি বা সমস্ত চেষ্টা / ধরার চেয়ে বেশি।

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

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

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

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

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

    এগুলি সমস্ত বিষয়ভিত্তিক - এবং সম্ভবত আমরা তুচ্ছ জিনিসটির চেয়ে সমস্যাগুলি পরিচালনা করার আরও অনেক উপায় রয়েছে। উপরের সমস্তটির জন্য ব্যতিক্রমটির গভীরতা তৈরি করা এবং বোঝার প্রয়োজন এবং বিভিন্ন পরিস্থিতিতে তৈরি করাও সম্ভব হওয়া উচিত।

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

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

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

সেরা উল্লেখ: কোড ক্রাফট অধ্যায় 6 - ডাউনলোডের জন্য উপলব্ধ


1

ডিবাগ বিল্ডগুলির সময় ত্রুটিগুলি পরীক্ষা করা কেবল একটি BAD IDEA (টিএম) হয়, মুক্তির অধীনে সংকলন স্ট্যাকের পুনরায় ব্যবহারযোগ্য ভেরিয়েবলগুলি রক্ষা করে, প্রহরী পৃষ্ঠাগুলি সরিয়ে দেয়, গণনার সাহায্যে iffy কৌশলগুলি করে, ভারি আর্থ্রিটিক্সকে প্রম্পম্পিউটেড শিফ্টের সাথে প্রতিস্থাপন করে।

মুক্তির ক্ষেত্রে ত্রুটি পরীক্ষা করেও ব্যবহার করুন, আপনি এত সহজ কিছু অবলম্বন করতে পারেন:

if(somethinghitthefan)
     abort();

এটির খুব ভাল পার্শ্ব প্রতিক্রিয়া রয়েছে যা একবার বেটা টেস্টার্স পিসিতে অ্যাপ্লিকেশন ক্রাশ হওয়া শুরু করলে আপনি অবশ্যই বাগটি উপেক্ষা করবেন না।

ইভেন্টের ভিউয়ার এবং লগগুলি তুলনায় সম্পূর্ণ অকেজো abort(), কে তবে সেগুলি পরীক্ষা করে?


প্রস্থান / পরিত্যাগ == খারাপ ব্যবহারকারীর অভিজ্ঞতা কি কখনো: আবেদন শুধু কেন .. কহন ছাড়া disappears
stijn

@ স্টিজন: abortডিবাগারে ব্রেক / ডাম্প তৈরি করে। exitখারাপ, হ্যাঁ যদিও, আমি __asm int 3সবচেয়ে বেশি পছন্দ করি ।
কোডার

এটি সত্য, এবং সি / সি ++ তে আমি __asm ​​ইন্ট 3 ব্যবহার করেও দৃser় লেখার প্রবণতা রাখি, তবে কেন কমপক্ষে কোনও বিবরণ না দেখানো এবং কখনই পছন্দ করে না লাইন এবং ফাইল। তারপরে কমপক্ষে গ্রাহক ঠিক কী ঘটেছে সে সম্পর্কে তথ্য দিতে পারেন।
6:30

0

আপনি যে বিভিন্ন জিনিস করতে পারেন তা হ'ল
অনলাইনে কোডটি প্রচুর কোডটি পড়ুন এবং সমবেত করুন এবং দেখুন এটি কীভাবে হয়
2. কিছু ডিবাগিং সরঞ্জাম ব্যবহার করুন যাতে আপনাকে ত্রুটিগুলির অঞ্চলগুলি সনাক্ত করতে সহায়তা করতে পারে
3. অযৌক্তিক কার্যভারের কারণে তুচ্ছ ত্রুটি সম্পর্কে সচেতন হন এবং বাক্য গঠন ত্রুটি।
4. কিছু খারাপ ত্রুটি যা কঠিন এই .For আরো জটিল বেশী মানুষ বা মত ব্যবহার রিসোর্সের ভাষী চেষ্টা করার জন্য আপনাকে যা করতে পারেন কলম এটা জানতে পারেন এবং এটি বা হয় প্রোগ্রামে যৌক্তিক ত্রুটির কারণে arrise Stackoverflow , উইকিপিডিয়া , google থেকে সাহায্য পেতে মানুষ।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.