আমি কি সি ++ এ ব্যতিক্রম স্পেসিফায়ার ব্যবহার করব?

123

সি ++ এ আপনি উল্লেখ করতে পারেন যে কোনও ফাংশন ব্যতিক্রম সুনির্দিষ্ট ব্যবহার করে কোনও ব্যতিক্রম ছুঁড়ে ফেলতে পারে বা নাও পারে। উদাহরণ স্বরূপ:

void foo() throw(); // guaranteed not to throw an exception
void bar() throw(int); // may throw an exception of type int
void baz() throw(...); // may throw an exception of some unspecified type

নিম্নলিখিতগুলির কারণে এগুলি প্রকৃতপক্ষে ব্যবহার করার বিষয়ে আমি সন্দেহজনক:

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

আপনি কি ব্যতিক্রম স্পেসিফায়ার ব্যবহার করা উচিত বলে মনে করেন?
"হ্যাঁ" বা "না" দিয়ে উত্তর দিন এবং আপনার উত্তরটি ন্যায়সঙ্গত করার জন্য কিছু কারণ দিন।

— 1800 তথ্য
সূত্র

7

"নিক্ষেপ (...)" মান সি ++ নয়। আমি বিশ্বাস করি এটি কয়েকটি সংকলকগুলির একটি এক্সটেনশন এবং সাধারণত কোনও ব্যতিক্রমের বিবরণ হিসাবে একই অর্থ।

— রিচার্ড কর্ডেন

97

না।

এখানে কয়েকটি উদাহরণ কেন:

টেমপ্লেট কোড ব্যতিক্রম স্পেসিফিকেশন সহ লেখা অসম্ভব,
```
template<class T>
void f( T k )
{
     T x( k );
     x.x();
}
```
অনুলিপিগুলি নিক্ষেপ করতে পারে, প্যারামিটারটি পাসিং নিক্ষেপ x()করতে পারে এবং কিছু অজানা ব্যতিক্রম ছুঁড়ে ফেলতে পারে।
ব্যতিক্রম-নির্দিষ্টকরণগুলি এক্সটেনসিবিলিটি বাধা দেয় to
```
virtual void open() throw( FileNotFound );
```
মধ্যে বিকশিত হতে পারে
```
virtual void open() throw( FileNotFound, SocketNotReady, InterprocessObjectNotImplemented, HardwareUnresponsive );
```
আপনি সত্যিই যে লিখতে পারে
```
throw( ... )
```
প্রথমটি এক্সটেনসিবল নয়, দ্বিতীয়টি অতিমাত্রায় এবং তৃতীয়টি আসলে আপনি যা বোঝাতে চেয়েছেন, যখন আপনি ভার্চুয়াল ফাংশন লিখেন।
উত্তরাধিকার কোড

আপনি যখন অন্য লাইব্রেরির উপর নির্ভরশীল কোডটি লেখেন, যখন কোনও কিছু ভয়াবহভাবে ভুল হয়ে যায় তখন আপনি কী করতে পারেন তা সত্যই আপনি জানেন না।
```
int lib_f();

void g() throw( k_too_small_exception )
{ 
   int k = lib_f();
   if( k < 0 ) throw k_too_small_exception();
}
```
gশেষ হবে, যখন lib_f()ছোঁড়ে। এটি (বেশিরভাগ ক্ষেত্রে) আপনি যা চান তা নয়। std::terminate()কখনও বলা হবে না। চুপচাপ / হিংস্রভাবে মারা যাওয়ার চেয়ে আপনি কোনও স্ট্যাক-ট্রেসটি পুনরুদ্ধার করতে পারেন এমন কোনও অপ্রত্যাশিত ব্যতিক্রম নিয়ে অ্যাপ্লিকেশনটি ক্র্যাশ করা সর্বদা ভাল is

এমন কোড লিখুন যা সাধারণ ত্রুটি দেয় এবং ব্যতিক্রমী অনুষ্ঠানে থ্রো করে।

Error e = open( "bla.txt" );
if( e == FileNotFound )
    MessageUser( "File bla.txt not found" );
if( e == AccessDenied )
    MessageUser( "Failed to open bla.txt, because we don't have read rights ..." );
if( e != Success )
    MessageUser( "Failed due to some other error, error code = " + itoa( e ) );

try
{
   std::vector<TObj> k( 1000 );
   // ...
}
catch( const bad_alloc& b )
{ 
   MessageUser( "out of memory, exiting process" );
   throw;
}

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

— ক্রিস্টোফার
সূত্র

1

3-এ, এটি প্রযুক্তিগতভাবে হবে স্ট্যান্ড :: অপ্রত্যাশিত নয় স্ট্যান্ড :: সমাপ্তি। কিন্তু যখন এই ফাংশনটি ডাকা হয়, তখন ডিফল্ট অনুরোধ () বাতিল করে। এটি একটি কোর ডাম্প উত্পন্ন করে। এটি কীভাবে একটি নিয়ন্ত্রণহীন ব্যতিক্রমের চেয়ে খারাপ? (যা মূলত একই জিনিসটি করে)

— গ্রেগ রজার্স

6

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

— প্যারাসেবল

আপনি রেখে গেছেন: try {...} catch (<specified exceptions>) { <do whatever> } catch (...) { unexpected(); ]আপনি সেখানে চেষ্টা করার চেষ্টা করতে চান বা না চান এটি কার্যকরভাবে কনস্ট্রাক্টে সমস্ত কিছু মোড়ানো হয়।

— ডেভিড থর্নলি

4

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

try { <<...code...>> } catch(...) /* stack guaranteed to be unwound here and dtors run */ { throw; /* pass it on to the runtime */ }

— লোগান ক্যাপালডো

" নিখরচায় / সহিংসভাবে মারা যাওয়ার চেয়ে আপনি কোনও স্ট্যাক-ট্রেস পুনরুদ্ধার করতে পারবেন, এমন কোনও অপ্রত্যাশিত ব্যতিক্রম নিয়ে অ্যাপ্লিকেশনটি ক্র্যাশ করা সর্বদা ভাল " " ক্লাশ ডেকে যাওয়ার চেয়ে" ক্র্যাশ "কীভাবে আরও ভাল হতে পারে terminate()? শুধু ডাকবে না কেন abort()?

— কৌতূহলী

42

সি ++ এ ব্যতিক্রমের স্পেসিফিকেশনগুলি এড়িয়ে চলুন। আপনি আপনার প্রশ্নে যে কারণগুলি দিচ্ছেন তা কেন একটি দুর্দান্ত শুরু।

ভেষজ সুটারের "ব্যতিক্রমের বিবরণগুলির মধ্যে একটি ব্যবহারিক চেহারা" দেখুন ।

— মাইকেল বুড়
সূত্র

3

@ অউডল্যান্ড: 'ডায়নামিক-ব্যতিক্রম-স্পেসিফিকেশন' ( throw(optional-type-id-list)) এর ব্যবহার সি ++ 11 এ অবমূল্যায়িত হয়েছে। তারা এখনও স্ট্যান্ডার্ডে রয়েছে তবে আমার ধারণা, একটি সতর্কতা শট প্রেরণ করা হয়েছে যে তাদের ব্যবহারটি সাবধানতার সাথে বিবেচনা করা উচিত। সি ++ 11 noexceptস্পেসিফিকেশন এবং অপারেটর যুক্ত করে। আমি এ সম্পর্কে noexceptমন্তব্য করতে যথেষ্ট বিবরণ জানি না । এই নিবন্ধটি বরং বিশদ হিসাবে উপস্থিত বলে মনে হচ্ছে: akrzemi1.wordpress.com/2011/06/10/ using-noexcept এবং ডায়েটমার কাহলের জুন ২০১১ ওভারলোড জার্নালে একটি নিবন্ধ রয়েছে: accu.org/var/uploads/journals/overload103.pdf

— মাইকেল বুড়

@ মিশেলবার কেবলমাত্র throw(something)অকেজো এবং একটি খারাপ ধারণা হিসাবে বিবেচিত হয়। throw()দরকারী.

— কৌতূহলী

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

— কৌতূহলী

14

আমি মনে করি প্রচলিত কনভেনশন বাদে (সি ++ এর জন্য)
ব্যতিক্রম স্পেসিফায়াররা সি ++ স্ট্যান্ডার্ডের একটি পরীক্ষা ছিল যা বেশিরভাগ ক্ষেত্রে ব্যর্থ হয়েছিল।
নো থ্রো স্পেসিফায়ার কার্যকর তবে ব্যতিক্রমটি কোডটি নির্দিষ্টকারীর সাথে মেলে কিনা তা নিশ্চিত করার জন্য আপনার অভ্যন্তরীণভাবে যথাযথ চেষ্টা ক্যাচ ব্লক যুক্ত করা উচিত। ভেষজ সুতার বিষয়টির একটি পৃষ্ঠা রয়েছে। 82 পেয়েছেন

অতিরিক্ত হিসাবে আমি মনে করি এটি ব্যতিক্রম গ্যারান্টিগুলি বর্ণনা করার মতো worth

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

ব্যতিক্রম গ্যারান্টি

কোনও গ্যারান্টি নেই:

কোনও ব্যতিক্রম পদ্ধতি থেকে অব্যাহতি পাওয়ার পরে অবজেক্টের অবস্থা সম্পর্কে কোনও গ্যারান্টি নেই
এই পরিস্থিতিতে অবজেক্টটি আর ব্যবহার করা উচিত নয়।

প্রাথমিক গ্যারান্টি:

প্রায় সমস্ত পরিস্থিতিতে এটি কোনও পদ্ধতি সরবরাহের ন্যূনতম গ্যারান্টি হওয়া উচিত।
এটি গ্যারান্টি দেয় যে অবজেক্টের অবস্থা ভালভাবে সংজ্ঞায়িত হয়েছে এবং এখনও ধারাবাহিকভাবে ব্যবহার করা যেতে পারে।

শক্ত গ্যারান্টি: (ওরফে লেনদেনের গ্যারান্টি)

এটি গ্যারান্টি দেয় যে পদ্ধতিটি সফলভাবে শেষ হবে
বা একটি ব্যতিক্রম ছুঁড়ে দেওয়া হবে এবং অবজেক্টের স্থিতি পরিবর্তন হবে না।

কোনও ছোঁড়ার গ্যারান্টি নেই:

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

— মার্টিন ইয়র্ক
সূত্র

গ্যারান্টিগুলি হ'ল প্রতিটি সি ++ প্রোগ্রামার অবশ্যই জানা উচিত তবে সেগুলি আমার কাছে ব্যতিক্রমের নির্দিষ্টকরণের সাথে সম্পর্কিত বলে মনে হয় না।

— ডেভিড থর্নলে

1

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

— মার্টিন ইয়র্ক

" ব্যাক্তিগত মতামতগুলি যা করে তা এখানে রয়েছে: - গ্যারান্টি যে ফাংশনগুলি কেবল তালিকাভুক্ত ব্যতিক্রমগুলি (সম্ভবত কোনওটিই নয়) ফেলে দেবে - - কেবলমাত্র তালিকাভুক্ত ব্যতিক্রমগুলি (সম্ভবত কোনওটিই নয়) নিক্ষিপ্ত হবে এমন জ্ঞানের উপর ভিত্তি করে সংকলক অপ্টিমাইজেশন সক্ষম করুন above উপরের প্রত্যাশাগুলি হ'ল, আবার, ছদ্মবেশে সঠিক হওয়ার কাছাকাছি। "আসলে, উভয়ই ঠিক ঠিক।

— কৌতূহলী

@curiousguy। জাভা এটি কীভাবে এটি করে কারণ এটি পরীক্ষা করে সংকলন সময়ে কার্যকর করা হয়। সি ++ রানটাইম চেক হয়। তাই: Guarantee that functions will only throw listed exceptions (possibly none)। সত্য না. এটি কেবলমাত্র গ্যারান্টি দেয় যে যদি ফাংশনটি এই ব্যতিক্রমগুলি ফেলে দেয় তবে অ্যাপ্লিকেশনটি সমাপ্ত হবে। Enable compiler optimizations based on the knowledge that only listed exceptions (possibly none) will be thrownতা করতে পারছি না। কারণ আমি কেবল উল্লেখ করেছি যে আপনি গ্যারান্টি দিতে পারবেন না যে ব্যতিক্রমটি ছুঁড়ে দেওয়া হবে না।

— মার্টিন ইয়র্ক

1

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

— কৌতূহলী

8

আপনি ব্যতিক্রমের বিশদটি লঙ্ঘন করলে gcc সতর্কতা প্রেরণ করবে। আমি যা করি তা হ'ল ব্যতিক্রমগুলি আমার ডকুমেন্টেশনের সাথে একমত হয়েছে কিনা তা নিশ্চিত করার জন্য কেবল "লিন্ট" মোডে ব্যতিক্রম স্পেসিফিকেশনগুলি ব্যবহার করার জন্য স্পষ্টভাবে সংকলন করুন।

— জেরেমি
সূত্র

7

একমাত্র দরকারী ব্যতিক্রম নির্দিষ্টকরণকারী হ'ল "নিক্ষেপ" (যেমন "নিক্ষেপ করা হয় না")।

— হ্যারল্ড একস্ট্রোম
সূত্র

2

আপনি দয়া করে এটি কার্যকর হওয়ার কারণ যুক্ত করতে পারেন?

— বুটি-অক্সা

2

কেন এটি দরকারী নয়? কিছু ফাংশন জেনে যাওয়া ব্যতীত ডান এবং বামে ব্যতিক্রম নিক্ষেপ করা শুরু করার চেয়ে বেশি কার্যকর কিছু নেই।

— ম্যাট জয়েনার

1

বিস্তারিত ব্যাখ্যার জন্য দয়া করে মাইকেল বুড়ের উত্তরে হার্ব সাটার আলোচনাটি দেখুন।

— হ্যারল্ড একস্ট্রোম

4

ব্যতিক্রমের বিবরণগুলি সি ++ এ আশ্চর্যজনকভাবে কার্যকর সরঞ্জাম নয়। যাইহোক, তাদের / এসডিডি :: অপ্রত্যাশিত সঙ্গে একত্রিত হলে / তাদের জন্য একটি ভাল ব্যবহার রয়েছে।

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

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

— coppro
সূত্র

3

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

অন্যথায় আমি এটি ব্যবহার করতে বিশেষভাবে দরকারী বলে মনে করি না তবে এটি throw()কোনও ব্যতিক্রম ছুঁড়ে না তা বোঝাতে।

— Branan
সূত্র

3

না, যদি আপনি সেগুলি ব্যবহার করেন এবং কোনও ব্যতিক্রম ছুঁড়ে ফেলা হয় যা আপনি নির্দিষ্ট করেন নি, আপনার কোড বা কোড দ্বারা কোড কোড দ্বারা, তবে পূর্বনির্ধারিত আচরণটি তাত্ক্ষণিকভাবে আপনার প্রোগ্রামটি সমাপ্ত করা।

এছাড়াও, আমি বিশ্বাস করি যে তাদের ব্যবহারগুলি সি ++ 0 এক্স স্ট্যান্ডার্ডের বর্তমান খসড়াগুলিতে অবচয় করা হয়েছে।

— Ferruccio
সূত্র

3

একটি "থ্রো ()" স্পেসিফিকেশন কোড প্রবাহ বিশ্লেষণ করার সময় সংকলকটিকে কিছু অপটিমাইজেশন করার অনুমতি দেয় যদি এটি জানতে পারে যে ফাংশনটি কখনই একটি ব্যতিক্রম ছুঁড়ে না ফেলে (বা কমপক্ষে কখনও ব্যতিক্রম ছুঁড়ে ফেলার প্রতিশ্রুতি দেয় না)। ল্যারি অস্টারম্যান এখানে এই সম্পর্কে সংক্ষেপে কথা বলেছেন:

http://blogs.msdn.com/larryosterman/archive/2006/03/22/558390.aspx

— জুসটি
সূত্র

2

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

হ্যাঁ, ব্যতিক্রম সুনির্দিষ্ট বিশিষ্ট ফাংশন থেকে নন-নির্দিষ্ট ব্যতিক্রমের প্রত্যাশিত আচরণটি কলটিমেট () বলা হয় call

আমি আরও নোট করব যে স্কট মায়ার্স এই বিষয়টিকে আরও কার্যকর সি ++ তে সম্বোধন করে। তাঁর কার্যকর সি ++ এবং আরও কার্যকর সি ++ অত্যন্ত প্রস্তাবিত বই।

— ক্রিস কুমার
সূত্র

2

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

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

— user10392
সূত্র

2

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

— অস্বাভাবিক
সূত্র

0

নিবন্ধ থেকে:

http://www.boost.org/community/exception_safety.html

"এটি ব্যতিক্রম-নিরাপদ জেনেরিক ধারক লিখতে অসম্ভব হিসাবে পরিচিত।" এই দাবিটি প্রায়শই টম কারগিল [৪] এর একটি নিবন্ধের প্রসঙ্গে শোনা যায় যাতে তিনি জেনেরিক স্ট্যাক টেম্পলেটটির জন্য ব্যতিক্রম-সুরক্ষার সমস্যাটি আবিষ্কার করেন। তার নিবন্ধে, কারগিল অনেক দরকারী প্রশ্ন উত্থাপন করেছেন, তবে দুর্ভাগ্যক্রমে তাঁর সমস্যার সমাধান উপস্থাপন করতে ব্যর্থ হন। তিনি পরামর্শ দিয়ে সমাধান শেষ করতে পারেন না যে উপসংহারে পৌঁছেছেন। দুর্ভাগ্যক্রমে, তাঁর অনুচ্ছেদটি অনেকেই অনুমানের "প্রমাণ" হিসাবে পড়েছিলেন। যেহেতু এটি প্রকাশিত হয়েছিল সেখানে ব্যতিক্রম-নিরাপদ জেনেরিক উপাদানগুলির অনেক উদাহরণ রয়েছে, এর মধ্যে সি ++ স্ট্যান্ডার্ড লাইব্রেরি পাত্রে রয়েছে।

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

— Marius
সূত্র

-2

ব্যতিক্রমের বিশদ বিবরণ = আবর্জনা, 30 বছরের বেশি বয়সী যেকোনো জাভা বিকাশকারীকে জিজ্ঞাসা করুন

— গ্রেগ ডিন
সূত্র

8

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

— ম্যাট জয়েনার