আমি কীভাবে ব্যতিক্রমগুলির জন্য চুক্তিগুলি তৈরি করতে এবং প্রয়োগ করতে পারি?

33

আমি আমার টিমের নেতৃত্বকে isSuccessfulত্রুটি কোড সহ একটি বুল বা এনাম ফেরানোর পরিবর্তে সি ++ এ ব্যতিক্রম ব্যবহার করার অনুমতি দেওয়ার চেষ্টা করছি convince যাইহোক, আমি তার এই সমালোচনা পাল্টাতে পারি না।

এই গ্রন্থাগারটি বিবেচনা করুন:

class OpenFileException() : public std::runtime_error {
}

void B();
void C();

/** Does blah and blah. */
void B() {
    // The developer of B() either forgot to handle C()'s exception or
    // chooses not to handle it and let it go up the stack.
    C();
};

/** Does blah blah.
 *
 * @raise OpenFileException When we failed to open the file. */
void C() {
    throw new OpenFileException();
};

একটি বিকাশকারী B()ফাংশন কল বিবেচনা করুন । তিনি এর ডকুমেন্টেশন চেক করেন এবং দেখেন যে এটি কোনও ব্যতিক্রম প্রত্যাবর্তন করে না, তাই সে কিছু ধরার চেষ্টা করে না। এই কোডটি উত্পাদনে প্রোগ্রামটি ক্র্যাশ করতে পারে।
একটি বিকাশকারী C()ফাংশন কল বিবেচনা করুন । তিনি ডকুমেন্টেশন চেক করেন না তাই কোনও ব্যতিক্রম ধরা পড়ে না। কলটি অনিরাপদ এবং উত্পাদনে প্রোগ্রামটি ক্র্যাশ করতে পারে।

তবে যদি আমরা এইভাবে ত্রুটিগুলি পরীক্ষা করি:

void old_C(myenum &return_code);

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

আমি কীভাবে ব্যতিক্রমগুলি নিরাপদে ব্যবহার করতে পারি, যাতে একরকম চুক্তি হয়?

c++ exceptions

— DBedrenko
সূত্র

4

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

— DBedrenko

4

"তাকে এটিকে পরিচালনা করা উচিত" - এটি হয় কিনা তা খতিয়ে দেখেনি।

— সুজোরড

4

@ সজর্দ এটি প্রয়োজনীয় নয় বিকাশকারীকে সচেতন করার জন্য এটি যথেষ্ট ভাল যে কোনও ত্রুটি ঘটতে পারে এবং তাদের এটি পরীক্ষা করা উচিত। তারা কোনও ত্রুটি পরীক্ষা করেছে কিনা তাও পর্যালোচকদের সরল দৃষ্টিতে।

— DBedrenko

5

টাইপ-সেফ কম্পোজেবল উপায়ে ত্রুটিটি ফিরিয়ে আনার জন্য আপনার একটি Either/ Resultমোনাড ব্যবহার করার আরও ভাল সুযোগ হতে পারে

— দেনিথ

5

@ গার্ডেনহেড যেহেতু অনেকগুলি বিকাশকারী এটি সঠিকভাবে ব্যবহার না করে, কুরুচিপূর্ণ কোডটি দিয়ে শেষ করেন এবং নিজের পরিবর্তে বৈশিষ্ট্যটিকে দোষারোপ করতে এগিয়ে যান। জাভাতে চেক করা ব্যতিক্রম বৈশিষ্ট্যটি একটি সুন্দর জিনিস, তবে এটি একটি খারাপ র‌্যাপ পায় কারণ কিছু লোক কেবল এটি পান না।

— এক্সিওমেটিকনেক্সাস

47

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

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

আপনার দলের নেতৃত্বকে বোঝানোর ক্ষেত্রে, এটি বেছে নেওয়া সঠিক যুদ্ধ নাও হতে পারে। বিশেষত লিগ্যাসি কোড সহ নয়। উপরের দ্বিতীয় লিঙ্কে উল্লিখিত:

ব্যতিক্রম কোনও কোডের মাধ্যমে প্রচার করা যায় না যা ব্যতিক্রম নিরাপদ নয়। ব্যতিক্রমগুলির ব্যবহার এইভাবে বোঝায় যে প্রকল্পের সমস্ত কোড অবশ্যই ব্যতিক্রম নিরাপদ।

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

এটি সম্ভবত কোনও যুক্তি নয় যা আমি চেষ্টা করে ব্যয় করব - কমপক্ষে কোনও নতুন প্রকল্প শুরু না হওয়া পর্যন্ত নয়। এমনকি আপনার যদি একটি নতুন প্রকল্প থাকে তবে এটি কোনও উত্তরাধিকার কোড ব্যবহার করে বা ব্যবহৃত হবে?

1

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

— DBedrenko

3

@ ব্যতিক্রমের পক্ষে কিছু যুক্তি দেখানোর জন্য উপরের লিঙ্কগুলি দেখুন (আমি আরও বিশেষজ্ঞের মতামত সহ একটি অতিরিক্ত লিঙ্ক যুক্ত করেছি)।

6

এই উত্তর স্পট হয়!

— ডক ব্রাউন

1

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

— মাইকেল কোহেন

26

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

ব্যতিক্রমগুলি পুরো জায়গা জুড়ে ধরা না দেওয়ার উদ্দেশ্যে।

মূল লুপটিতে একটি সাধারণ ব্যতিক্রম হ্যান্ডলার যতক্ষণ না রয়েছে - যতক্ষণ না অ্যাপ্লিকেশন (ওয়েব সার্ভার, স্থানীয় পরিষেবা, কমান্ড লাইন ইউটিলিটি ...) এর ধরণের উপর নির্ভর করে - আপনার সাধারণত সমস্ত ব্যতিক্রম হ্যান্ডলার থাকে।

আমার কোডে, মূল লুপের বাইরে কয়েকটি রয়েছে - কেবল কোনও হ'ল স্টেটমেন্ট। এবং এটি আধুনিক সি ++ এর সাধারণ পদ্ধতির বলে মনে হচ্ছে।

ব্যতিক্রম এবং রিটার্ন কোডগুলি পারস্পরিক একচেটিয়া নয়।

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

সাধারণ ব্যর্থতা, যেমন ব্যবহারকারী কর্তৃক প্রদত্ত কোনও ফাইলের নাম বৈধ কিনা তা পরীক্ষা করা ব্যতিক্রমগুলির জন্য ব্যবহারের ক্ষেত্রে নয়; পরিবর্তে এই ক্ষেত্রে একটি রিটার্ন মান ব্যবহার করুন।

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

সুতরাং কোনও নিখুঁত নিয়ম নেই। মোটামুটি গাইডলাইনটি হ'ল: যদি এটি স্থানীয়ভাবে পরিচালনা করা যায় তবে এটিকে একটি ফেরতের মান করুন; আপনি যদি স্থানীয়ভাবে এটি পরিচালনা করতে না পারেন তবে একটি ব্যতিক্রম ছুঁড়ে দিন।

ব্যতিক্রম স্থির চেকিং দরকারী নয়।

যেহেতু ব্যতিক্রম স্থানীয়ভাবে পরিচালনা করা হয় না, সাধারণত কোনটি ব্যতিক্রম ছুঁড়ে দেওয়া যায় তা গুরুত্বপূর্ণ নয় isn't কোনও ব্যতিক্রম নিক্ষেপ করা যায় কিনা তা কেবলমাত্র দরকারী তথ্য।

জাভাতে স্থির চেক রয়েছে, তবে এটি সাধারণত একটি ব্যর্থ পরীক্ষা হিসাবে বিবেচিত হয় এবং যেহেতু বেশিরভাগ ভাষাগুলি - বিশেষত সি # - এই ধরণের স্থির চেক নেই। সি # কেন না থাকার কারণগুলি সম্পর্কে এটি ভাল পড়া ।

এই কারণে, সি ++ এর throw(exceptionA, exceptionB)পক্ষে হ্রাস করেছে noexcept(true)। ডিফল্টটি হ'ল কোনও ফাংশন নিক্ষেপ করতে পারে, সুতরাং ডকুমেন্টেশন স্পষ্টভাবে অন্যথায় প্রতিশ্রুতি না দিলে প্রোগ্রামারদের আশা করা উচিত।

ব্যতিক্রম নিরাপদ কোড লেখার ব্যতিক্রম হ্যান্ডলারগুলি লেখার সাথে কোনও সম্পর্ক নেই।

আমি বরং বলব যে ব্যতিক্রমী নিরাপদ কোড লেখার ব্যতিক্রম হ্যান্ডলারগুলি কীভাবে এড়ানো যায় সে সম্পর্কে সবই!

বেশিরভাগ সেরা অনুশীলন ব্যতিক্রম হ্যান্ডলারের সংখ্যা হ্রাস করার উদ্দেশ্যে। কোড লিখন একবার এবং স্বয়ংক্রিয়ভাবে এটিকে অনুরোধ করে - যেমন RAII- এর মাধ্যমে পুরো স্থানটিতে একই কোডের অনুলিপি-পেস্ট করার চেয়ে কম বাগের ফলস্বরূপ।

— Sjoerd
সূত্র

3

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

12

@ ড্যান 1111 "ব্যতিক্রমী নিরাপদ কোড রাইটিং" ব্যতিক্রম হ্যান্ডলারগুলি লেখার সাথে খুব একটা সম্পর্ক রাখে না। ব্যতিক্রমী নিরাপদ কোড রাইটিং হ'ল "স্থানীয়ভাবে প্রথমে সমস্ত কাজ করুন তারপরে অদলবদল / সরানো ব্যবহার করুন" এবং অন্যান্য সেরা অনুশীলনগুলি ব্যবহার করে রিসোর্সগুলি এনক্যাপসুলেট করতে রাইআইআই ব্যবহার করা। এগুলি চ্যালেঞ্জিং যখন আপনি তাদের ব্যবহার করেন না। তবে "ব্যতিক্রম হ্যান্ডলারগুলি লেখা" এই সেরা অনুশীলনের অংশ নয়।

— Sjoerd

4

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

— jpmc26

4

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

— jpmc26

3

@ অক্সিমেটিকনেক্সাস হ্যাঁ, কারণ সেরা বিকাশকারীরা এতটাই নিখুঁত যে তাদের কোড সর্বদা প্রতিটি সম্ভাব্য ব্যবহারকারী ইনপুটকে নিখুঁতভাবে পরিচালনা করবে এবং আপনি কখনও কখনও কখনও এই ব্যতিক্রমগুলি দেখতে পাবেন না । এবং যদি আপনি এটি করেন তবে এর অর্থ আপনি জীবনে একটি ব্যর্থতা। সিরিয়াসলি, আমাকে এই আবর্জনা দেবেন না। কেউ যে নিখুঁত, এমনকি সেরা না। এবং "অ্যাপ্লিকেশনটি" "থামিয়ে অর্ধ শালীন ত্রুটি পৃষ্ঠা / বার্তা" ফিরিয়ে দেওয়া হলেও আপনার অ্যাপ্লিকেশনটিকে সেই ত্রুটিগুলির মধ্যেও বুদ্ধিমান আচরণ করা উচিত। : এবং কি অনুমান যে একই জিনিস আপনি 99% সঙ্গে করি IOExceptionগুলি, অত্যধিক । চেক করা বিভাগটি নির্বিচারে এবং অকেজো।

— jpmc26

8

সি ++ প্রোগ্রামাররা ব্যতিক্রমের নির্দিষ্টকরণের সন্ধান করে না। তারা ব্যতিক্রম গ্যারান্টি জন্য সন্ধান করুন।

ধরুন কোনও অংশের কোড ব্যতিক্রম করেছে throw প্রোগ্রামার কী অনুমানগুলি এখনও বৈধ হতে পারে? কোডটি যেভাবে লেখা হচ্ছে, তার ব্যতিক্রমের পরে কোড কী গ্যারান্টি দেয়?

অথবা এটি কি সম্ভব যে কোনও নির্দিষ্ট কোডের গ্যারান্টি দিতে পারে না যে তারা কখনই ছোঁড়াবে না (যেমন ওএস প্রক্রিয়াটি সমাপ্ত হচ্ছে না)?

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

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

এই স্ট্যাকওভারফ্লো প্রশ্নের উত্তরগুলি সি -++ প্রোগ্রামারদের তাদের কোডের সাথে সংঘটিত সমস্ত সম্ভাব্য ব্যর্থতা মোডগুলি বুঝতে এবং ব্যর্থতা সত্ত্বেও প্রোগ্রামের রাষ্ট্রের বৈধতা রক্ষা করার চেষ্টা করে to সি ++ কোডের লাইন বাই লাইন বিশ্লেষণ একটি অভ্যাসে পরিণত হয়।

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

তথ্যসূত্র: http://en.cppreferences.com/w/cpp/language/exception#Exception_safety - ব্যতিক্রম সুরক্ষার অধীনে দেখুন।

ব্যতিক্রমীকরণের উল্লেখগুলি কার্যকর করতে সি ++ এর একটি ব্যর্থ প্রচেষ্টা ছিল। পরে অন্যান্য ভাষায় বিশ্লেষণ বলে যে ব্যতিক্রম সংক্রান্ত নির্দিষ্টকরণগুলি কেবল ব্যবহারিক নয়।

কেন এটি একটি ব্যর্থ প্রচেষ্টা: কঠোরভাবে এটি প্রয়োগ করতে, এটি টাইপ সিস্টেমের অংশ হতে হবে। তবে তা নয়। সংকলক ব্যতিক্রম নির্দিষ্টকরণের জন্য পরীক্ষা করে না।

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

তথ্যসূত্র: http://www.gotw.ca/publications/mill22.htm

সি ++ 17 দিয়ে শুরু হচ্ছে [[nodiscard]] বৈশিষ্ট্যটি ফাংশন রিটার্ন মানগুলিতে ব্যবহার করা যেতে পারে (দেখুন: https://stackoverflow.com -চেনা-করা-উপেক্ষা )।

সুতরাং যদি আমি একটি কোড পরিবর্তন করি এবং এটি একটি নতুন ধরণের ব্যর্থতার শর্ত (যেমন একটি নতুন ধরণের ব্যতিক্রম) উপস্থাপন করে, তবে এটি কি একটি ব্রেকিং পরিবর্তন? ফোন কলকারীকে কোডটি আপডেট করতে বাধ্য করা উচিত ছিল, বা কমপক্ষে পরিবর্তনের বিষয়ে সতর্ক করা উচিত?

আপনি যদি যুক্তিগুলি গ্রহণ করেন যে সি ++ প্রোগ্রামাররা ব্যতিক্রমের নির্দিষ্টকরণের পরিবর্তে ব্যতিক্রম গ্যারান্টির সন্ধান করে, তবে উত্তরটি হ'ল যদি নতুন ধরণের ব্যর্থতা শর্তটি ব্যতিক্রম না করে তবে পূর্বের প্রতিশ্রুতি কোডের গ্যারান্টি দেয়, এটি কোনও ব্রেকিং পরিবর্তন নয়।

— rwong
সূত্র

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

— এক্সিওমেটিকনেক্সাস

@ অজিওমেটিকনেক্সাস এটির ব্যতিক্রম গ্যারান্টি দ্বারাও উত্তর দেওয়া হবে। আসলে আমি যুক্তি দিয়েছি স্পেসিফিকেশন কখনই সম্পূর্ণ হতে পারে না; গ্যারান্টি হ'ল আমরা যা খুঁজছি। কোন গ্যারান্টিটি এখনও কার্যকর ছিল তা অনুমান করার জন্য প্রায়শই, আমরা ব্যতিক্রম প্রকারটি কী গ্যারান্টিটি ভঙ্গ হয়েছিল তা অনুসন্ধানের প্রয়াসের সাথে তুলনা করি। ব্যতিক্রম স্পেসিফিকেশন আপনার যা যা পরীক্ষা করতে হবে তার কয়েকটি তালিকাবদ্ধ করে তবে মনে রাখবেন যে কোনও ব্যবহারিক পদ্ধতিতে তালিকাটি সম্ভবত সম্পূর্ণ হতে পারে না। বেশিরভাগ সময়, লোকেরা ব্যতিক্রম প্রকারের "খাওয়ার" শর্টকাট নিতে বাধ্য করে, এটি অন্য একটি ব্যতিক্রমের মধ্যে আবৃত করে, যা ব্যতিক্রম প্রকারটি

— কঠোরভাবে

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

— rwong

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

— ডিকোডিংকে

1

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

— সুপারক্যাট

4

সি () ফাংশন কলকারী কোনও বিকাশকারী বিবেচনা করুন। তিনি ডকুমেন্টেশন চেক করেন না তাই কোনও ব্যতিক্রম ধরা পড়ে না। কলটি অনিরাপদ

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

— DeadMG
সূত্র

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

— ই

1

@ মাস্টার হিম তাকে ব্যতিক্রমের প্রত্যাশা নাC() করা একটি বড় ভুল is সি ++ এ ডিফল্টটি হ'ল যে কোনও ফাংশন নিক্ষেপ করতে পারে - noexcept(true)অন্যথায় অন্যথায় সংকলকটি বলতে এটি সুস্পষ্ট প্রয়োজন । এই প্রতিশ্রুতির অভাবে, একজন প্রোগ্রামারকে অবশ্যই ধরে নিতে হবে যে কোনও ফাংশন নিক্ষেপ করতে পারে।

— সোজর্ড

1

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

— ডেড এমএমজি

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

— মাস্টার

@ মাস্টার এটি একটি নতুন প্রকল্প সম্পর্কে - গৃহীত উত্তরের প্রথম মন্তব্য দেখুন। সুতরাং কোন বিদ্যমান ফাংশন নেই যা ভেঙ্গে যাবে, কারণ কোনও বিদ্যমান কার্য নেই।

— সোজর্ড

3

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

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

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

— টমাস ওভেনস
সূত্র