সি-তে প্রতিটি ছোট্ট ত্রুটির জন্য একজনকে পরীক্ষা করা উচিত?

Question

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

এটি কখনও কখনও স্পষ্ট হয় যে ত্রুটি যাচাই করা দরকার, উদাহরণস্বরূপ আপনি যখন কোনও ফাইল খোলার চেষ্টা করেন। তবে আমি প্রায়শই যেমন ক্রিয়াকলাপে ত্রুটি পরীক্ষা করা printfবা এমনকি mallocপ্রয়োজন বোধ করি না কেন তা উপেক্ষা করি।

if(fprintf(stderr, "%s", errMsg) < 0){
    perror("An error occurred while displaying the previous error.");
    exit(1);
}

কেবলমাত্র কিছু ত্রুটি উপেক্ষা করা কি ভাল অনুশীলন, বা সমস্ত ত্রুটিগুলি পরিচালনা করার আরও ভাল উপায় আছে?

Comments

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

— rwong

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

— এরিক tদ

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

— coredump

আমি বিশ্বাস করি না কারও কথা বলা হয়েছে errno! যদি আপনি পরিচিত না হন তবে এটি সত্য যে "সি লাইব্রেরির প্রায় সমস্ত ফাংশন 0 বা −1 ফিরে আসবে বা NULLযখন কোনও ত্রুটি ঘটবে " তারা বৈশ্বিক errnoচলকও সেট করে যা আপনি ব্যবহার করে #include <errno.h>এবং কেবল সহজভাবে পড়ার মাধ্যমে অ্যাক্সেস করতে পারবেন এর মান errno। সুতরাং, উদাহরণস্বরূপ, যদি open(2) ফিরে আসে -1, আপনি যাচাই করতে চাইতে পারেন errno == EACCES, যা কোনও অনুমতি ত্রুটি নির্দেশ করে, বা ENOENTযা নির্দেশ করে যে ফাইলটি বিদ্যমান নেই।

— wchargin

@ এরিকইড্ট সি সমর্থন করে না try/ catch, যদিও আপনি এটিকে জাম্প দিয়ে সিমুলেট করতে পারেন।

— মাস্তে

Answer 1

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

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

সি তে, আপনার কাছে সেই বিলাসিতা নেই। ত্রুটিগুলি পরিচালনা করার কয়েকটি উপায় রয়েছে যার মধ্যে কয়েকটি ভাষা / গ্রন্থাগার বৈশিষ্ট্য, যার কয়েকটি কোডিং অনুশীলন।

কেবলমাত্র কিছু ত্রুটি উপেক্ষা করা কি ভাল অনুশীলন, বা সমস্ত ত্রুটিগুলি পরিচালনা করার আরও ভাল উপায় আছে?

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

সমস্ত, বা কমপক্ষে বেশিরভাগ ক্ষেত্রে ত্রুটিগুলি পরিচালনা করার উপায় রয়েছে:

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

2. ক্যাসকেডিং if:

   if (!<something>) {
     printf("oh no 1!");
     return;
   }
   if (!<something else>) {
     printf("oh no 2!");
     return;
   }
   

3. প্রথম শর্তটি পরীক্ষা করুন, যেমন কোনও ফাইল খোলার বা তৈরি করা, তারপরে অনুমান করুন পরবর্তী ক্রিয়াকলাপগুলি সফল succeed

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

Comments

দুঃখিত, ছোট বাছাই করতে এখানে - "স্ট্যান্ডার্ড আউটপুট লিখতে ব্যর্থ হবে না। যদি এটি ব্যর্থ হয়, আপনি কিভাবে ব্যবহারকারীকে বলবেন?" - স্ট্যান্ডার্ড ত্রুটি লিখে? কোনওটির কাছে লেখার ব্যর্থতা বোঝায় যে অন্যকে লেখা অসম্ভব।

— ড্যামিয়েন_ও_বিশ্বাসীরা

@ ডামিয়েন_সে_ অবিশ্বাসী - বিশেষত যেহেতু stdoutকোনও ফাইলের দিকে পুনঃনির্দেশ করা যেতে পারে, বা এমনকি সিস্টেমের উপর নির্ভর করে এটি বিদ্যমান নেই। stdout"কনটোল টু কনসোল" স্ট্রিম নয়, এটি সাধারণত এটি হয় তবে এটি হওয়ার দরকার নেই।

— Žদ্রালো

@ জ্যাব আপনি একটি বার্তা প্রেরণ করুন stdout... সুস্পষ্ট :-)

— ট্রিপহাউন্ড

@ জ্যাব: আপনি যদি উপযুক্ত হন তবে আপনি এক্স_আইওআরআর বা তার সাথে প্রস্থান করতে পারেন।

— জন মার্শাল

আপনি যা করেন না কেন কেবল চালিয়ে যান না যেন কিছুই হয় নি! যদি আদেশটি dump_database > backups/db_dump.txtকোনও নির্দিষ্ট সময়ে স্ট্যান্ডার্ড আউটপুট লিখতে ব্যর্থ হয়, আমি এটি চালিয়ে যেতে চাই এবং সফলভাবে প্রস্থান করতে চাই না। (ডাটাবেসগুলি সেভাবে ব্যাক আপ করা নয়, তবে বিষয়টি এখনও দাঁড়িয়ে আছে)

— বেন এস

Answer 2

যাইহোক, সি লাইব্রেরি থেকে প্রায় সমস্ত ফাংশন 0 বা -1 বা NUL ফিরে আসবে যখন কোনও ত্রুটি আছে।

হ্যাঁ, তবে আপনি জানেন যে আপনি কোন ফাংশনটি ডেকেছিলেন, তাই না?

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

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

Comments

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

— রাবারডাক

কিভাবে এটি প্রশ্নের উত্তর দেয় না?

— রবার্ট হার্ভে

আমি মনে করি যে সি (এবং অন্যান্য ভাষাগুলি) বুলিয়ান 1 এবং 0 টি মিশ্রিত হয়েছে একই কারণ হ'ল কোনও শালীন ক্রিয়াকলাপ কোনও ত্রুটির জন্য "0" ফিরিয়ে দেয়। তবে আপনি বলতে হবে if (!myfunc()) {/*proceed*/}। 0 কোনও ত্রুটি ছিল না, এবং শূন্যহীন কিছুতে কিছুটা ত্রুটি ছিল এবং প্রতিটি ধরণের ত্রুটির নিজস্ব শূন্য কোড ছিল। আমার একজন বন্ধু যেভাবে বলেছিল "সেখানে কেবল একটি সত্য, তবে অনেক মিথ্যা কথা"। "0" if()পরীক্ষায় "সত্য" হওয়া উচিত এবং শূন্যহীন যে কোনও কিছু "মিথ্যা" হওয়া উচিত।

— রবার্ট ব্রিস্টো-জনসন

না, এটি আপনার উপায়ে করছেন, কেবলমাত্র একটি সম্ভাব্য নেতিবাচক ত্রুটি কোড রয়েছে। এবং অনেকগুলি সম্ভাব্য no_error কোড।

— রবার্ট ব্রিস্টো-জনসন

@ রবার্টব্রিস্টো-জনসন: তারপরে এটি "কোনও ত্রুটি ছিল না" হিসাবে পড়ুন। if(function()) { // do something }"যদি ফাংশন কোনও ত্রুটি ছাড়াই কার্যকর হয় তবে কিছু করুন" হিসাবে পড়ছে। বা, আরও ভাল, "যদি ফাংশনটি সফলভাবে সম্পাদন করে তবে কিছু করুন।" সিরিয়াসলি, যারা সম্মেলনটি বোঝেন তারা এতে বিভ্রান্ত হন না । falseকোনও ত্রুটি দেখা দিলে ফিরে (বা 0) ত্রুটি কোডগুলি ব্যবহার করার অনুমতি দেয় না। জিরো মানে সি তে মিথ্যা কারণ এটি সেইভাবে গণিতের কাজ করে। প্রোগ্রামার্স.সটাকেক্সচেঞ্জ

— রবার্ট হার্ভে

Answer 3

TLDR; আপনার প্রায়শই ত্রুটি উপেক্ষা করা উচিত নয়।

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

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

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

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

এটি করা একই সমস্যা:

try
{
    run();
} catch (Exception) {
    // comments expected here!!!
}

আপনি যদি খালি ক্যাচ ব্লকের ভিতরে কোনও ভাল মন্তব্য না করে দেখে থাকেন তবে এটি অবশ্যই একটি সমস্যা। কল করার malloc()জন্য 100% সময় সাফল্যের সাথে কার্যকর হবে তা ভাবার কোনও কারণ নেই ।

Comments

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

— ডেরেক 朕 會 功夫

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

— হোয়াইটনাম

@ ওয়াটসিসনাম: কেবল ক্রাশ না হওয়ার অর্থ এই নয় যে তারা নিঃশব্দে ডেটা ক্ষতিগ্রস্থ করছে না। malloc()এমন একটি ফাংশন যা আপনি অবশ্যই রিটার্নের মানগুলি পরীক্ষা করতে চান!

— TMN

@ টিএমএন: যদি মলোক ব্যর্থ হয় তবে প্রোগ্রামটি তাত্ক্ষণিকভাবে সেগফল্ট হয়ে শেষ হবে, এটি স্টাফ করে না। এগুলি সবই ঝুঁকি সম্পর্কিত এবং যা উপযুক্ত, "কখনই নয়"।

— কিসনেম

@ অ্যালেক্স সি-তে ভাল ত্রুটি পরিচালনার অভাব নেই। আপনি যদি ব্যতিক্রম চান তবে আপনি সেগুলি ব্যবহার করতে পারেন। ব্যতিক্রমগুলি ব্যবহার না করে স্ট্যান্ডার্ড লাইব্রেরি হ'ল ইচ্ছাকৃত পছন্দ (ব্যতিক্রমগুলি আপনাকে স্বয়ংক্রিয় মেমরি পরিচালনা করতে বাধ্য করে এবং প্রায়শই আপনি এটি নিম্ন স্তরের কোডের জন্য চান না)।

— মার্টিনকুনেভ

Answer 4

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

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

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

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

Answer 5

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

Answer 6

কিছুটা বিমূর্ত প্রশ্নটি গ্রহণ করুন। এবং এটি সি ভাষার জন্য অগত্যা নয়।

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

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

এবং পরে আপনার কংক্রিট বাস্তবায়ন স্তর থাকবে যেখানে আপনি প্রকৃতপক্ষে নিয়মগুলি সেট করেছেন এবং আউটপুট পরিচালনা করবেন।

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

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

Answer 7

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

Comments

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

— ক্রিয়েটিভ ম্যাজিক

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

— চতুর নিওলিজম