বৈজ্ঞানিক গ্রন্থাগারে ত্রুটিগুলি কীভাবে রিপোর্ট করা উচিত?


11

গ্রন্থাগারগুলিতে কীভাবে ত্রুটি বা অন্যান্য ব্যতিক্রমী অবস্থার সাথে লড়াই করা উচিত সে সম্পর্কে বিভিন্ন সফটওয়্যার ইঞ্জিনিয়ারিং শাখায় অনেকগুলি দর্শন রয়েছে। আমি যেগুলি দেখেছি তাদের মধ্যে কয়েকটি:

  1. পয়েন্টার যুক্তি দিয়ে ফলাফলের সাথে একটি ত্রুটি কোডটি ফিরিয়ে দিন। পিইটিএসসি এটিই করে।
  2. একটি সেন্ডিনেল মান দ্বারা ত্রুটিগুলি ফিরিয়ে দিন। উদাহরণস্বরূপ, ম্যালোক NULL প্রদান করে যদি এটি মেমরি বরাদ্দ করতে না পারে, sqrtআপনি নেতিবাচক সংখ্যায় পাস করলে NaN ফিরিয়ে দেয় etc. ইত্যাদি approach
  3. ব্যতিক্রম নিক্ষেপ। আই.আই, ত্রিলিনোস ইত্যাদিতে ব্যবহৃত হয়
  4. বৈকল্পিক প্রকারটি ফেরত দিন; উদাহরণস্বরূপ একটি সি ++ ফাংশন যা টাইপের কোনও অবজেক্টকে Resultসঠিকভাবে চালিত করে এবং Errorএটি কীভাবে ব্যর্থ হয়েছিল তা কীভাবে ফিরে আসবে তা বর্ণনা করতে কোনও প্রকার ব্যবহার করে std::variant<Error, Result>
  5. দৃsert়তা এবং ক্রাশ ব্যবহার করুন। P4est এবং ইগ্রাফের কিছু অংশে ব্যবহৃত হয়।

প্রতিটি পদ্ধতির সাথে সমস্যা:

  1. প্রতিটি ত্রুটির জন্য অনুসন্ধান করা অতিরিক্ত প্রচুর কোডের পরিচয় দেয়। যে মানগুলিতে ফলাফল সংরক্ষণ করা হবে সেগুলি সর্বদা প্রথমে ঘোষণা করতে হবে, প্রচুর অস্থায়ী ভেরিয়েবলগুলি প্রবর্তন করা হবে যা কেবল একবার ব্যবহার করা যেতে পারে। এই পদ্ধতির ব্যাখ্যায় কী ত্রুটি ঘটেছে তা ব্যাখ্যা করা হয়েছে তবে কেন বা একটি গভীর কল স্ট্যাকের জন্য, কোথায় তা নির্ধারণ করা কঠিন hard
  2. ত্রুটি কেস উপেক্ষা করা সহজ। সর্বোপরি, আউটপুট প্রকারের পুরো পরিসীমা যদি একটি ফলস্বরূপ ফলাফল হয় তবে অনেকগুলি ক্রিয়াকলাপের কাছে একটি অর্থবহ প্রেরণিকা মানও থাকতে পারে না। # 1 হিসাবে একই সমস্যা অনেক।
  3. কেবল সি ++, পাইথন ইত্যাদিতেই সম্ভব, সি বা ফোর্টরানে নয়। সিটজ্যাম্প / লংজ্যাম্প জাদু বা লাইবুনউইন্ড ব্যবহার করে সিতে নকল করা যায় ।
  4. কেবল সি ++, মরিচা, ওক্যামেল ইত্যাদিতেই সম্ভব, সি বা ফোর্টরানে নয়। ম্যাক্রো যাদুবিদ্যার সাহায্যে সি তে নকল করা যায়।
  5. তর্কযুক্তভাবে সবচেয়ে তথ্যবহুল। তবে আপনি যদি সি সি লাইব্রেরির জন্য এই পদ্ধতিটি অবলম্বন করেন তবে আপনি পাইথন মোড়কের জন্য লিখেছেন, অ্যারির বাইরে সীমানা সূচকটি পাস করার মতো মূর্খ ভুলটি পাইথন ইন্টারপ্রেটারকে ক্র্যাশ করবে।

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

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

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

একদিকে যেমন, আমি মনে করি যে সি 5 লাইব্রেরির জন্য # 5 পদ্ধতির উন্নতি করা যেতে পারে যদি এটি জনসাধারণের API এর অংশ হিসাবে বিশ্বব্যাপী দৃser় হ্যান্ডলার ফাংশন পয়েন্টারটিকে সংজ্ঞায়িত করে। দৃ hand় হ্যান্ডলারটি ফাইল / লাইন নম্বর এবং ক্র্যাশিংয়ের প্রতিবেদন করতে ডিফল্ট হবে। এই লাইব্রেরির জন্য সি ++ বাইন্ডিংগুলি একটি নতুন দৃ hand় হ্যান্ডলার সংজ্ঞায়িত করবে যা পরিবর্তে একটি সি ++ ব্যতিক্রম ছোঁড়ে। তেমনি পাইথন বাইন্ডিংগুলি এমন একটি দৃ as় হ্যান্ডলারের সংজ্ঞা দেয় যা পাইথন ব্যতিক্রম ছুঁড়ে সিপিথন এপিআই ব্যবহার করে। তবে এই পদ্ধতির গ্রহণযোগ্য কোনও উদাহরণ আমি জানি না।


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

নোট করুন যে সর্বোত্তম উত্তরটি ভাষা দ্বারা পৃথক হবে।
ক্রাইলিস

উত্তর:


10

আমি আপনাকে আমার দৃষ্টিভঙ্গি দেব, যা চুক্তিতে এনকোডযুক্ত .I প্রকল্পটি যা আপনি উল্লেখ করেন।

প্রথমত, দুটি ধরণের ত্রুটি শর্ত রয়েছে: যে ত্রুটিগুলি থেকে পুনরুদ্ধার করা যায় এবং ত্রুটিগুলি যা পুনরুদ্ধার করা যায় না।

  • পূর্ববর্তীটি উদাহরণস্বরূপ, যদি কোনও ইনপুট ফাইলটি পড়তে না পারে - উদাহরণস্বরূপ যদি আপনি কোনও ফাইল থেকে তথ্য পড়তে থাকেন যেমন $HOME/.dealiiউপস্থিত থাকতে পারে বা নাও থাকতে পারে। পড়ার ফাংশনটি কেবল কী করবে তা নির্ধারণের জন্য কেবল কলিং ফাংশনে ফিরে আসা উচিত। এটি এমনও হতে পারে যে এই মুহুর্তে কোনও সংস্থান উপলব্ধ নেই তবে এটি আবার এক মিনিটে (দূরবর্তীভাবে মাউন্ট করা ফাইল সিস্টেম) হতে পারে।

  • দ্বিতীয়টি উদাহরণস্বরূপ, যদি আপনি 20 মাপের ভেক্টরের সাথে 10 মাপের একটি ভেক্টর যুক্ত করার চেষ্টা করছেন: আপনি যতটা চেষ্টা করুন চেষ্টা করুন, এটি সম্পর্কে কিছুই করা যায় না - কোডটিতে একটি বাগ রয়েছে যা আমরা সংযোজনটি করার চেষ্টা করেছি এমন বিন্দুটি।

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

  • দ্বিতীয় ক্ষেত্রে, যেহেতু কোনও আশ্রয় নেই, প্রোগ্রামটি শেষ করুন। আপনি এটি করতে পারেন কোনও ব্যতিক্রম ছুঁড়ে ফেলে বা একটি ত্রুটি কোড ফিরিয়ে দিয়ে যা কলারকে নির্দেশ করে যে কিছুই করা যায় না, তবে আপনি ঠিক সেই মুহুর্তে প্রোগ্রামটি বাতিল করতে পারেন যেহেতু প্রোগ্রামারটির পক্ষে সমস্যাটি ডিবাগ করা এত সহজ হয়ে যায়।

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

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

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


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

@ সিডালিটজ: এটি সি ++ এর ডিজাইনের ত্রুটি যা আপনি যে কোনও ধরণের জিনিস ফেলে দিতে পারেন। তবে যে কোনও যুক্তিসঙ্গত সফ্টওয়্যার (ট্রিলিনোস বাদে) কেবলমাত্র ব্যতিক্রমগুলি ছুঁড়ে ফেলেছে যা থেকে উত্পন্ন হয়েছে std::exceptionএবং এগুলি উত্পন্ন প্রকারটি না জেনে রেফারেন্স দ্বারা ধরা যেতে পারে।
ওল্ফগ্যাং ব্যাঙ্গারথ

1
তবে মূল প্রশ্নে বর্ণিত কারণগুলির জন্য আমি ত্রুটি কোডটি ফিরিয়ে দেওয়ার সাথে দৃ strongly়ভাবে একমত নই: (i) ত্রুটি কোডগুলি প্রায়শই উপেক্ষা করা হয় এবং ফলস্বরূপ ত্রুটিগুলি একেবারেই পরিচালিত হয় না; (ii) অনেক ক্ষেত্রে, ফাংশনের রিটার্নের ধরণটি নির্দিষ্ট হয়ে গেলে যুক্তিসঙ্গতভাবে ফিরিয়ে নেওয়া যায় এমন ব্যতিক্রমী কোনও মূল্য নেই; (iii) ফাংশনগুলির বিভিন্ন রিটার্নের ধরণ থাকে এবং প্রতিটি ক্ষেত্রে আপনাকে আলাদাভাবে "ব্যতিক্রমী" মানটি কী ত্রুটি উপস্থাপন করে তা নির্ধারণ করতে হবে।
ওল্ফগ্যাং ব্যাঙ্গারথ

ডাব্লুবি লিখেছিল (দুঃখিত, '@' কৌশলটি কোনও কারণে কাজ করে না এবং কোনও কারণে স্ট্যাকএক্সচেজ ব্যবহারকারীর নামটি মুছে ফেলা হয়েছে): "ত্রুটি কোডগুলি প্রায়শই উপেক্ষা করা হয়"। এটি ব্যতিক্রম ক্যাপচারের জন্য আরও বেশি ধারণ করে: অনেক সফ্টওয়্যার বিকাশকারী চেষ্টা / ক্যাচ ব্লকে প্রতিটি ফাংশন কল ব্র্যাক করে তোলার সমস্যা নেয় না। তবে এটি বেশিরভাগ স্বাদের বিষয়: যতক্ষণ ডকুমেন্টেশনে পরিষ্কারভাবে বলা হয় যে কোনও ফাংশন নিক্ষেপ করে এবং কোনটি ব্যতিক্রম করে, আমি এটি পরিচালনা করতে পারি। তবে আবার এটি বলা যেতে পারে: ডকুমেন্টেশন লেখার দায়িত্বটি প্রায়শই উপেক্ষা করা হয় ;-)
সিডালিটজ

তবে মুল বক্তব্যটি হ'ল যদি আপনি কোনও ব্যতিক্রম ধরা ভুলে যান তবে কোনও প্রবাহের সমস্যা নেই: প্রোগ্রামটি কেবলমাত্র বন্ধ রয়েছে ab সমস্যাটি কোথায় ঘটেছে তা খুঁজে পাওয়া সহজ হবে। আপনি যদি ত্রুটি কোডটি যাচাই করতে ভুলে যান তবে কোনও পূর্বনির্ধারিত অভ্যন্তরীণ অবস্থার কারণে আপনার প্রোগ্রামটি পরবর্তী সময়ে ক্র্যাশ হতে পারে - তবে যেখানে মূল সমস্যাটি ছিল পুরোপুরি অস্পষ্ট। এই ধরণের বাগগুলি খুঁজে পাওয়া অত্যন্ত কঠিন।
ওল্ফগ্যাং ব্যাঙ্গার্থ
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.