পুনরুদ্ধার পদ্ধতিটি কি 'নাল' ফিরবে বা কোনও ব্যতিক্রম ছুঁড়ে ফেলা উচিত যখন এটি ফেরতের মান উত্পাদন করতে পারে না? [বন্ধ]

503

বন্ধ । এই প্রশ্নটি মতামত ভিত্তিক । এটি বর্তমানে উত্তর গ্রহণ করছে না।

এই প্রশ্নটি উন্নত করতে চান? প্রশ্নটি আপডেট করুন যাতে পোস্টটি সম্পাদনা করে সত্য এবং উদ্ধৃতি দিয়ে উত্তর দেওয়া যায় ।

4 বছর আগে বন্ধ ছিল ।

আমার কাছে এমন একটি পদ্ধতি রয়েছে যা যদি কোনও বস্তু খুঁজে পাওয়া যায় তবে তা ফেরত দেওয়ার কথা।

যদি এটি না পাওয়া যায় তবে আমি কি:

নাল ফিরে
একটি ব্যতিক্রম নিক্ষেপ
অন্যান্য

exception error-handling null

— রবার্ট
সূত্র

57

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

— রিক

6

এটি প্রোগ্রামিং ভাষার প্রচলিত আইডিয়ামগুলির উপর নির্ভর করে। এই প্রশ্নটি একটি প্রোগ্রামিং ভাষার ট্যাগ দিয়ে ট্যাগ করুন।

— টেডি

3

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

— কে-

1

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

— পিষ্ট করুন

484

আপনি যদি সর্বদা একটি মান সন্ধানের প্রত্যাশা করে থাকেন তবে যদি এটি অনুপস্থিত থাকে তবে ব্যতিক্রমটি নিক্ষেপ করুন। ব্যতিক্রমটির অর্থ একটি সমস্যা ছিল।

যদি মানটি অনুপস্থিত বা উপস্থিত হতে পারে এবং উভয়ই অ্যাপ্লিকেশন যুক্তির জন্য বৈধ হয় তবে একটি শূন্য ফেরান।

আরও গুরুত্বপূর্ণ: কোডে আপনি অন্য জায়গাগুলি কী করেন? ধারাবাহিকতা গুরুত্বপূর্ণ।

— কেন
সূত্র

30

@ কেন: +১, উল্লেখ করা ভাল লাগবে যে আপনি যদি কোনও ব্যতিক্রম ছুঁড়ে ফেলেন তবে এটি একটি প্রাইরি সনাক্ত করতে পারে (যেমন হাসিটেম (...)), তবে ব্যবহারকারীর হ্যাড * বা এতে থাকা পদ্ধতিটি সরবরাহ করা উচিত।

— user7116

4

মানটি অনুপস্থিত থাকাকালীন কোনও মান বা নাল ফেরার পরিবর্তে, সম্ভবত <T> ফেরত বিবেচনা করুন। মাইকেহাদলো.ব্লগস্পট.এনএল / ২০১০ / ২০১1 / মোনাদস-ইন- সি -৫-মায়াব.এইচটিএমএল দেখুন ।

— এরউইন রুইজাক্কারস

2

@ ইরউইনরুইজাকার্স ডিজাইনের পছন্দমতো উপায় হিসাবে, জাভা 8-তে আপনি একটি

— returnচ্ছিক

2

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

— পিষ্ট করুন

4

@ ক্রাশ আমি মনে করি একটি কার্যনির্বাহী অধ্যক্ষ হ'ল ফাংশনটিতে কী কী পরামিতিগুলি দেওয়া হয় । আপনি যদি একটি প্রাথমিক কীটি উল্লেখ করার মতো কোনও পরিচয় পাস করেন তবে সেই আইটেমটি পাওয়া না গেলে এটি ব্যতিক্রমী হিসাবে বিবেচনা করা উচিত, কারণ এটি সিস্টেমে কোনও অসঙ্গত অবস্থা নির্দেশ করে। উদাহরণ: GetPersonById(25)যদি সেই ব্যক্তিটিকে মুছে ফেলা হয় তবে ফেলে দেওয়া GetPeopleByHairColor("red")হবে , তবে খালি ফলাফলটি ফিরিয়ে দেবে। সুতরাং, আমি মনে করি প্যারামিটারগুলি প্রত্যাশা সম্পর্কে কিছু বলে।

— জন নুপ

98

যদি সত্যই এটি ত্রুটি হয় তবে কেবল একটি ব্যতিক্রম ছুঁড়ে ফেলুন। যদি অবজেক্টটির অস্তিত্ব না থাকায় আচরণের প্রত্যাশা থাকে তবে নালটি ফিরুন।

অন্যথায় এটি পছন্দসই বিষয়।

— কার্লটন জেনকে
সূত্র

4

আমি রাজি নই। আপনি স্থিতি কোড হিসাবে ব্যতিক্রম ছুঁড়ে ফেলতে পারেন: "নটফাউন্ডএক্সেপশন"

— এসিভি

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

— ক্রাশ করুন

4

আমি মনে করি নাল কেস পরিচালনা করা "নটফাউন্ডএক্সেপশন" এর চেয়ে অনেক সহজ। প্রতিটি একক পুনরুদ্ধার অনুরোধ যে আপনার "নটফাউন্ডএক্সেপশন" ছুঁড়েছে তার চারপাশে আপনাকে কত লাইনের ট্রাই-ক্যাচ লিখতে হবে তা ভেবে দেখুন ... আমার চোখে সমস্ত কোড প্রস্তুত করা বেদনাদায়ক।

— ভিসি

আমি টনি হোয়ের উদ্ধৃতি দিতে চাই: "আমি এটাকে আমার বিলিয়ন ডলারের ভুল বলি"। আমি নাল ফিরব না, আমি হয় একটি ব্যতিক্রম ছুঁড়ে সঠিকভাবে এটি পরিচালনা করি, বা একটি খালি বস্তু ফিরিয়ে দেব।

— সাত

70

একটি সাধারণ নিয়ম হিসাবে, পদ্ধতিটি যদি সর্বদা কোনও বস্তুকে ফেরত দেয় তবে ব্যতিক্রমটি নিয়ে যান। আপনি যদি মাঝে মাঝে নালটি অনুমান করেন এবং এটি একটি নির্দিষ্ট উপায়ে পরিচালনা করতে চান তবে নাল দিয়ে যান।

আপনি যাই করুন না কেন, আমি তৃতীয় বিকল্পের বিরুদ্ধে উচ্চ পরামর্শ দিচ্ছি: "ডাব্লুটিএফ" বলার মতো একটি স্ট্রিং ফিরে আসা।

— মাতিয়াস নিনো
সূত্র

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

— rciafardone

14

ডাব্লুটিএফের বিকল্পগুলি আমার কাছে দুর্দান্ত বলে মনে হয়েছিল বলে আমি ভোটে নামতে যাচ্ছিলাম ... তবে স্পষ্টতই আমার হৃদয় আছে

— সুইসনার

5

নতুন WtfExcepti😲n নিক্ষেপ করুন

— কামাফেদার

আমি মনে করি যে এই উত্তরটি কেন একটি পদ্ধতি সর্বদা কোনও বস্তু বনাম "মাঝে মাঝে নাল" ফেরত দেবে তার কারণগুলির বিষয়ে কথা বললে সহায়ক হবে। এই ধরণের পরিস্থিতি কী ওয়্যারেন্ট করে? এইরকম পরিস্থিতি কখন থাকতে পারে তার একটি উদাহরণ দিন।

— ক্রাশ করুন

51

যদি নাল কখনই কোনও ত্রুটি নির্দেশ করে না তবে কেবল নালটি ফিরুন।

যদি নাল সর্বদা ত্রুটি হয় তবে একটি ব্যতিক্রম ছুঁড়ে দিন।

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

চেষ্টা করার রুটিনটির অপব্যবহার করা শক্ত। নাল পরীক্ষা করা ভুলে যাওয়া আসল সহজ।

সুতরাং নাল একটি ত্রুটি যখন আপনি শুধু লিখুন

object o = FindObject();

নাল কোনও ত্রুটি না হলে আপনি এর মতো কিছু কোড করতে পারেন

if (TryFindObject(out object o)
  // Do something with o
else
  // o was not found

— কেভিন গাল
সূত্র

1

এটি # আরও কার্যকর পরামর্শ হবে যদি সি # যদি প্রকৃত টিপল সরবরাহ করে তবে আমরা একটি [আউট] প্যারামিটার ব্যবহার এড়াতে পারি। তবুও এটি পছন্দসই প্যাটার্ন, সুতরাং +1।

— এরিক ফোর্বস

2

আমার মতে, চেষ্টা করার পদ্ধতিটি সর্বোত্তম। আপনাকে সন্ধান করতে হবে না তবে যদি বস্তুটি ফিরে না পাওয়া যায় তবে কী হয়। একটি চেষ্টা পদ্ধতি সহ, আপনি তাত্ক্ষণিকভাবে জানেন কী করতে হবে।

— অরেগনঘস্ট

আমাকে findএবং findOrFail

— লারাভেল এলোভেন্টের

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

— ক্রাশ করুন

@ ক্রাশ - নামী টুপল লিটারালগুলি একটি বিকল্প, আইএমও। এটি টিপলসের সাথে প্যাটার্ন পান চেষ্টা করুন অ্যাসিঙ্কের একটি লিঙ্ক। stackoverflow.com/questions/1626597/...

— ttugates

26

আমি কেবল আগে উল্লিখিত বিকল্পগুলি পুনরায় কাটাতে চেয়েছিলাম, কিছু নতুন এনে ফেলেছি:

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

অথবা আপনি এই বিকল্পগুলি একত্রিত করতে পারেন:

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

Object findObjectOrNull(String key);
Object findObjectOrThrow(String key) throws SomeException;
Object findObjectOrCreate(String key, SomeClass dataNeededToCreateNewObject);
Object findObjectOrDefault(String key, Object defaultReturnValue);

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

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

— লেনা শিম্মেল
সূত্র

আমি স্পষ্ট ফাংশন নামগুলি বিশেষত orCreate এবং orDefault পছন্দ করি।

— marcovtwout

5

এই অধিকাংশই আরো পরিচ্ছন্নভাবে সঙ্গে লেখা যেতে পারে Expected<T> findObject(String)যেখানে Expected<T>ফাংশন আছে orNull(), orThrow(), orSupplied(Supplier<T> supplier), orDefault(T default)। এটি ত্রুটি পরিচালনা থেকে ডেটা প্রাপ্তিকে

— বিমূ .় করে

আমি এখন পর্যন্ত প্রত্যাশিত <টি> সম্পর্কে জানতাম না। আমি আসল উত্তরটি লেখার সময় মনে হয়েছিল আমি বেশ নতুন এবং সম্ভবত উপস্থিত ছিলাম না। আপনার মন্তব্যটি একটি সঠিক উত্তর করা উচিত।

— লেনা শিমেল 11

এছাড়াও, প্রত্যাশিত <টি> একটি সি ++ টেম্পলেট। অন্যান্য অবজেক্ট ওরিয়েন্টেড ভাষায়ও এর প্রয়োগ রয়েছে?

— লেনা শিমেল

জাভা 8-তে, অপশনাল <T> (অন্য ভাষায় বলা যেতে পারে <T> ইত্যাদি) ফিরে আসাও একটি বিকল্প। এটি কলারের কাছে স্পষ্টভাবে ইঙ্গিত করে যে কিছুই ফিরিয়ে দেওয়া কোনও সম্ভাবনা নয় এবং যদি কলার সেই সম্ভাবনাটি পরিচালনা না করে তবে তা সঙ্কলন করে না, যেমন নਾਲের বিপরীতে, যা (যাইহোক জাভাতে) কলার চেক না করলেও সংকলন করবে ।

— কিছু লোক

18

নাল অবজেক্ট প্যাটার্নটি ব্যবহার করুন বা একটি ব্যতিক্রম নিক্ষেপ করুন।

— pmlarocque
সূত্র

এটিই আসল উত্তর। নাল ফিরিয়ে দেওয়া অলস প্রোগ্রামারগুলির একটি ভয়ানক অভ্যাস।

— jeremyjjbrown

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

— বেন

Sourcemaking.com/design_patterns/null_object

— বেন

3

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

— সুপারক্যাট

3

সত্তা অনুসন্ধানের জন্য নাল বস্তুটি কীভাবে আচরণ করবে? যেমন, Person somePerson = personRepository.find("does-not-exist");আসুন এই পদ্ধতি আয় ID- র জন্য একটি নাল বস্তুর অনুমান does-not-exist। তাহলে কি সঠিক আচরণ হবে somePerson.getAge()? এই মুহুর্তে, আমি এখনও নিশ্চিত নই যে নাল অবজেক্ট প্যাটার্ন হ'ল সত্তা অনুসন্ধানের জন্য সঠিক সমাধান।

— আব্দুল

13

আপনি যে API (গুলি) ব্যবহার করছেন তার সাথে সামঞ্জস্য থাকুন।

— ডেমকি
সূত্র

13

একটি ব্যতিক্রম নিক্ষেপ করার সুবিধা:

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

উদাহরণ সহ আরও ব্যাখ্যার জন্য, দেখুন: http://metatations.com/2011/11/17/returning-null-vs-throwing-an-exception/

— ক্লিফোর্ড ওরাভেক
সূত্র

2

+1 কারণ পয়েন্ট 2 দুর্দান্ত - নাল এর একই অর্থ খুঁজে পাওয়া যায় নি। ডায়নামিক ভাষাগুলির সাথে ডিল করার সময় এটি আরও গুরুত্বপূর্ণ হয়ে ওঠে যেখানে ফাংশন দ্বারা নুল আসলে সংরক্ষণ করা / পুনরুদ্ধার করা বস্তু হতে পারে - এবং সেই ক্ষেত্রে

— অ্যাডাম টেরি

1

# 2 পয়েন্টের জন্য +1। নাল কি ত্রুটি? প্রদত্ত কীটির জন্য কী সংরক্ষণ করা হচ্ছে তা নাল? কী কী নাল ইঙ্গিত দেয় যে কীটির অস্তিত্ব নেই? এগুলিই এমন প্রশ্নের আসল পংক্তি যা এটি পরিষ্কার করে দেয় যে প্রত্যাবর্তন বাতিল হয় প্রায় কখনই সঠিক নয়। এটি সম্ভবত এখানে সেরা উত্তর হওয়ায় অন্য সবাই সবেমাত্র অস্পষ্টতাকে "যদি এটি ব্যতিক্রমী হয় তবে নিক্ষেপ করুন" ছুঁড়ে ফেলছে

— পিষ্ট করুন

12

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

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

যদিও আমি উপরের সাথে একমত .. ব্যতিক্রমী / ত্রুটি শর্তের জন্য ব্যতিক্রম ব্যবহার করা উচিত, এবং চেকগুলি ব্যবহার করার সময় শূন্যতা ফেরানো সেরা।

পাইথনে ইএএফপি বনাম এলবিওয়াইএল:
http://mail.python.org/pipermail/python-list/2003- মে/205182.html ( ওয়েব সংরক্ষণাগার )

— কোরি গোল্ডবার্গ
সূত্র

3

কিছু ক্ষেত্রে, ইএএফপি হ'ল একমাত্র অর্থবহ উপায়। উদাহরণস্বরূপ, একসাথে মানচিত্র / অভিধানে ম্যাপিংয়ের অনুরোধ করা হবে কি না তা জিজ্ঞাসা করার উপায় নেই।

— সুপারক্যাট

11

শুধু নিজেকে জিজ্ঞাসা করুন: "এটি কী ব্যতিক্রমী ঘটনা যা বস্তুটি পাওয়া যায় না"? যদি এটি আপনার প্রোগ্রামের সাধারণ কোর্সে ঘটে থাকে বলে আশা করা হয় তবে আপনার সম্ভবত একটি ব্যতিক্রম বাড়াতে হবে না (যেহেতু এটি ব্যতিক্রমী আচরণ নয়)।

সংক্ষিপ্ত সংস্করণ: ব্যতিক্রমী আচরণ পরিচালনা করতে ব্যতিক্রমগুলি ব্যবহার করুন, আপনার প্রোগ্রামের নিয়ন্ত্রণের স্বাভাবিক প্রবাহকে পরিচালনা করতে নয়।

-Alan।

— AlanR
সূত্র

5

ব্যতিক্রমগুলি ডিজাইন দ্বারা চুক্তি সম্পর্কিত।

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

1) সমস্ত ইনপুট পদ্ধতিটি বৈধ, কোনও ক্ষেত্রে যখন অবজেক্টটি পাওয়া যায় না তখন আপনাকে অবশ্যই নালায় ফিরে আসতে হবে।

2) কেবলমাত্র কিছু ইনপুট বৈধ, অর্থাত্ এটি একটি প্রাপ্ত বস্তুর ফলাফল। কোন ক্ষেত্রে আপনি অবশ্যই একটি দ্বিতীয় পদ্ধতি অফার করবেন যা কলকারীকে তার ইনপুটটি সঠিক হবে কিনা তা নির্ধারণ করতে দেয়। উদাহরণ স্বরূপ

is_present(key)
find(key) throws Exception

IF এবং কেবলমাত্র আপনি যদি দ্বিতীয় চুক্তির উভয় পদ্ধতি সরবরাহ করেন তবে আপনাকে ব্যতিক্রম ছুঁড়ে দেওয়ার অনুমতি দেওয়া হয় কিছুই পাওয়া যায় না!

— akuhn
সূত্র

4

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

— swilliams
সূত্র

4

এর অর্থ কী তার উপর নির্ভর করে যে বস্তুটি পাওয়া যায় নি।

এটি যদি স্বাভাবিক অবস্থায় থাকে তবে শূন্য হয়ে ফিরে আসুন। এটি কেবল এমন কিছু যা একবারে ঘটতে পারে এবং কলকারীদের এটি পরীক্ষা করা উচিত।

যদি এটি ত্রুটি হয়, তবে একটি ব্যতিক্রম ছুঁড়ে ফেলুন, কলকারীদের সিদ্ধান্ত নেওয়া উচিত যে নিখোঁজ হওয়া অবজেক্টের ত্রুটি শর্তটি নিয়ে কী করবেন।

শেষ পর্যন্ত হয় কাজ করবে, যদিও বেশিরভাগ লোকেরা সাধারণত ব্যতিক্রমগুলি ব্যবহার করা ভাল অভ্যাস হিসাবে বিবেচনা করে যখন কিছু, ভাল, ব্যতিক্রম ঘটেছে happened

— স্টিভ বি।
সূত্র

2

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

— user1451111

4

এখানে আরও কয়েকটি পরামর্শ দেওয়া হল।

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

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

আপনি কিছু পরিস্থিতিতে নাল অবজেক্ট প্যাটার্নটিও বিবেচনা করতে পারেন যা হয় কোনও ডিফল্ট বা কোনও আচরণ না করে সংস্করণ হতে পারে। কীটি হ'ল কোড বেজ জুড়ে নাল চেক এড়ানো। আরও তথ্যের জন্য এখানে দেখুন http://geekswithblogs.net/dsellers/archive/2006/09/08/90656.aspx

— ডানকান
সূত্র

3

কিছু ফাংশনে আমি একটি পরামিতি যুক্ত করি:

..., bool verify = true)

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

— লেভ
সূত্র

3

একটি ব্যতিক্রম ছুঁড়ে ফেলার পরিবর্তে একটি নাল ফেরান এবং স্পষ্টভাবে ডকুমেন্ট এ নাল রিটার্ন মান সম্ভাবনা নথি। যদি কলিং কোডটি এপিআইকে সম্মান না করে এবং নাল কেসটি পরীক্ষা করে না, তবে এটি সম্ভবত কোনওভাবেই "নাল পয়েন্টার ব্যতিক্রম" এর ফলে ঘটতে পারে :)

সি ++ তে আমি কোনও পদ্ধতি নির্ধারণের জন্য 3 টি পৃথক স্বাদের কথা ভাবতে পারি যা কোনও বস্তু খুঁজে পায়।

বিকল্প ক

Object *findObject(Key &key);

কোনও বস্তু সন্ধান না করা হলে নাল ফেরান। সুন্দর এবং সহজ। আমি এই এক সাথে যেতে হবে। নীচের বিকল্প পদ্ধতিগুলি এমন লোকদের জন্য যারা আউট-প্যারামকে ঘৃণা করে না।

বিকল্প বি

void findObject(Key &key, Object &found);

পরিবর্তনশীল একটি রেফারেন্সে পাস করুন যা বস্তুটি গ্রহণ করবে receiving কোনও বস্তুর সন্ধান পাওয়া না গেলে পদ্ধতিটি একটি ব্যতিক্রম ছুঁড়ে দেয়। এই কনভেনশন সম্ভবত আরও উপযুক্ত যদি এটি সত্যই প্রত্যাশিত না হয় যে কোনও বস্তুর সন্ধান পাওয়া যায় না - তাই আপনি এটি একটি অপ্রত্যাশিত ঘটনা তা বোঝাতে একটি ব্যতিক্রম ছুঁড়ে মারেন।

বিকল্প সি

bool findObject(Key &key, Object &found);

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

if (!findObject(myKey, myObj)) { ...

— অ্যাটস গোলাল
সূত্র

3

কেবল সেই ক্ষেত্রে যেখানে নালকে ব্যতিক্রমী আচরণ হিসাবে বিবেচনা করা হয় না আমি চেষ্টা পদ্ধতির জন্য অবশ্যই নিশ্চিত, এটি স্পষ্ট, এখানে "যেমন বলা হয়েছিল" বইটি পড়ার "বা" আপনি লাফানোর আগে "তাকানোর দরকার নেই here

তাই মূলত:

bool TryFindObject(RequestParam request, out ResponseParam response)

এবং এর অর্থ হল যে ব্যবহারকারীর কোডটিও পরিষ্কার হবে

...
if(TryFindObject(request, out response)
{
  handleSuccess(response)
}
else
{
  handleFailure()
}
...

— DorD
সূত্র

2

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

— থামাল
সূত্র

2

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

— ইরান গাল্পেরিন
সূত্র

2

অথবা একটি বিকল্প ফেরত দিন

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

তারপরে আপনার এই অবজেক্টে টি getOrElse (টি ভ্যালুআইফনল) এর মতো পদ্ধতি রয়েছে এটি হয় প্রাপ্ত বস্তুটি ফেরত দেয়, বা ক্লায়েন্টের একটি বিকল্প বিকল্প হিসাবে দেয়।

— জন নিলসন
সূত্র

2

নাল ফিরতে পছন্দ করুন -

যদি কলকারী চেক না করে এটি ব্যবহার করে তবে ব্যতিক্রম ঠিক সেখানেই ঘটে happens

যদি কলকারী সত্যই এটি ব্যবহার না করে তবে তাকে একটি try/ catchব্লক কর দেবেন না

— kizzx2
সূত্র

2

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

— দিমিত্রি আর
সূত্র

1

যতক্ষণ না অবজেক্টের কোনও রেফারেন্স ফিরিয়ে দেওয়ার কথা , ততক্ষণ NULL ফেরানো ভাল হওয়া উচিত।

তবে, যদি এটি পুরো রক্তাক্ত জিনিসটি ফিরিয়ে দেয় (যেমনটি আপনি সি ++ তে করেন তবে: 'রিটার্ন & ব্লাহ;' (বা 'ব্লাহ' একটি পয়েন্টার) না হয়ে আপনি ফিরে আসতে পারবেন না, কারণ এটি 'অবজেক্ট' টাইপের নয় that সেক্ষেত্রে একটি ব্যতিক্রম ছুঁড়ে দেওয়া বা কোনও সাফল্যের পতাকা সেট না থাকা একটি ফাঁকা বস্তু ফিরিয়ে দেওয়া আমি কীভাবে সমস্যার সাথে যোগাযোগ করব।

— ঘনবসতিপূর্ণ বস্তি
সূত্র

1

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

— ScottCher
সূত্র

1

আমি এখানে যে sensক্যমত্য বলে মনে হয় তার সাথে আমি একমত হয়েছি ("পাওয়া না গেলে নালার প্রত্যাবর্তন করা" একটি সাধারণ সম্ভাব্য ফলাফল, বা যদি পরিস্থিতিটির শব্দার্থবিজ্ঞানের প্রয়োজন হয় যে বস্তুটি সর্বদা খুঁজে পাওয়া যায়)।

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

— GBegen
সূত্র

1

একটি নাল ফেরান, ব্যতিক্রমগুলি হ'ল: আপনার কোডটি এমন কিছু করে যা প্রত্যাশিত নয়।

— অ্যান্ডার্স
সূত্র

1

ব্যতিক্রমসমূহ হওয়া উচিত ব্যতিক্রমী । নাল ফিরিয়ে দেওয়া বৈধ হলে নাল ফেরান ।

— অ্যান্ড্রু লুইস
সূত্র

1

কমবেশি সত্য। Boost.org/commune/error_handling.html

— মার্টিন কোট

1

পদ্ধতিটি যদি কোনও সংগ্রহ ফেরত দেয়, তবে একটি খালি সংগ্রহ (যেমন উপরে বলেছে) ফিরিয়ে দিন। তবে দয়া করে সংগ্রহগুলি নয় EM EMPTY_LIST বা এ জাতীয়! (জাভা ক্ষেত্রে)

যদি পদ্ধতিটি কোনও একক বস্তুটি পুনরুদ্ধার করে তবে আপনার কিছু বিকল্প রয়েছে।

যদি পদ্ধতিটিতে সর্বদা ফলাফল পাওয়া উচিত এবং অবজেক্টটি না খুঁজে পাওয়া এটি একটি সত্য ব্যতিক্রম ঘটনা, তবে আপনাকে অবশ্যই একটি ব্যতিক্রম ছুঁড়ে ফেলা উচিত (জাভাতে: দয়া করে একটি চেক না করা ব্যতিক্রম)
(কেবল জাভা) যদি আপনি সহ্য করতে পারেন যে পদ্ধতিটি একটি পরীক্ষিত ব্যতিক্রম ছুঁড়ে ফেলেছে তবে কোনও প্রকল্প নির্দিষ্ট অবজেক্টনটফাউন্ডএক্সসেপশন বা এর মতো নিক্ষেপ করুন। এই ক্ষেত্রে সংকলক আপনাকে বলে যদি আপনি ব্যতিক্রমটি পরিচালনা করতে ভুলে যান। (জাভাতে জিনিস খুঁজে পাওয়া যায় নি এটি আমার পছন্দসই হ্যান্ডলিং))
যদি আপনি বলেন যে এটি সত্যই ঠিক আছে, যদি অবজেক্টটি খুঁজে পাওয়া যায় না এবং আপনার পদ্ধতির নাম ফাইন্ডবুকফোর্ডারঅর্ডার রিটারননুল (..) এর মতো হয়, তবে আপনি শূন্য হয়ে যেতে পারেন। এই ক্ষেত্রে এটি হয় দৃ strongly ়ভাবে কিছু ধরণের স্থিতিশীল চেক বা সংকলক চেক ব্যবহার করার জন্য পুনরায় স্মরণ করা হয়, যা কোনও শূন্য চেক ছাড়াই ফলাফলটিকে dereferences বাধা দেয়। জাভা ক্ষেত্রে এটি উদাঃ হতে পারে। FindBugs ( http://findbugs.sourceforge.net/manual/annotations.html এ ডিফল্ট অ্যানোটেশন দেখুন ) বা ইন্টেলিজ -চেকিং।

সতর্কতা অবলম্বন করুন, যদি আপনি কোনও শূন্য ফেরত দেওয়ার সিদ্ধান্ত নেন। আপনি যদি প্রকল্পের একমাত্র প্রোগ্রামার না হন তবে রান সময় আপনি নালপয়েন্টারএক্সপ্লেশনগুলি (জাভাতে বা অন্য ভাষাগুলিতে যা কিছু পাবেন) পাবেন! সুতরাং সঙ্কলন সময় পরীক্ষা করা হয় না যা নাল ফিরে না।

— রেভস আইউযুজ
সূত্র

কোডটি প্রত্যাশার জন্য সঠিকভাবে লেখা হয়েছিল কিনা null। আরও তথ্যের জন্য শীর্ষ ভোটের উত্তর দেখুন।

— অ্যান্ড্রু বারবার

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

— iuzuz

"সরল", হতে পারে । তবে প্রায়শই সরল ভুল

— অ্যান্ড্রু বারবার

1

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

— অ্যান্ড্রু বার্বার

1

আপনি এখানে অনেক ভুল বোঝাবুঝি করছেন। আপনি সর্বজনীনভাবে শর্তাধীন পরামর্শ প্রয়োগ করছেন, যা প্রায়শই করা খারাপ কাজ। বাকী আপ করা বাকী উত্তরগুলিও পড়ুন। আপনার উত্তরটি কেবল একটি নিখুঁত অবস্থা বর্ণনা করে এবং এর জন্য অত্যন্ত ত্রুটিযুক্ত যুক্তি উপস্থাপন করে।

— অ্যান্ড্রু বারবার

1

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

Main.java

public class Main {
public static void main(String[] args) {
    Example example = new Example();

    try {
        Example2 obj = example.doExample();

        if(obj == null){
            System.out.println("Hey object is null!");
        }
    } catch (Exception e) {
        System.out.println("Congratulations, you caught the exception!");
        System.out.println("Here is stack trace:");
        e.printStackTrace();
    }
}
}

Example.java

/**
 * Example.java
 * @author Seval
 * @date 10/22/2014
 */
public class Example {
    /**
     * Returns Example2 object
     * If there is no Example2 object, throws exception
     * 
     * @return obj Example2
     * @throws Exception
     */
    public Example2 doExample() throws Exception {
        try {
            // Get the object
            Example2 obj = new Example2();

            return obj;

        } catch (Exception e) {
            // Log the exception and rethrow
            // Log.logException(e);
            throw e;
        }

    }
}

Example2.java

 /**
 * Example2.java
 * @author Seval
 *
 */
public class Example2 {
    /**
     * Constructor of Example2
     * @throws Exception
     */
    public Example2() throws Exception{
        throw new Exception("Please set the \"obj\"");
    }

}

— svlzx
সূত্র

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

— কিছু লোক

0

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

বস্তু পাওয়া গেছে; প্রত্যাবর্তন বস্তু
অবজেক্টটি পাওয়া যায় নি; ব্যতিক্রম নিক্ষেপ

অন্যথায়, নাল ফিরে।

— হরণ করা
সূত্র