কখন ব্যতিক্রম ছুঁড়বেন?

435

আমার অ্যাপ্লিকেশনটি আশা করে না এমন প্রতিটি শর্তের জন্য আমার ব্যতিক্রম রয়েছে। UserNameNotValidException, PasswordNotCorrectExceptionইত্যাদি

তবে আমাকে বলা হয়েছিল যে এই শর্তগুলির জন্য আমার ব্যতিক্রম তৈরি করা উচিত নয়। আমার ইউএমএলে এগুলি মূল প্রবাহে ব্যতিক্রম, তবে কেন এটি ব্যতিক্রম হবে না?

ব্যতিক্রম তৈরি করার জন্য কোনও গাইডেন্স বা সেরা অনুশীলন?

exception language-agnostic

— কোয়ান চেং
সূত্র

58

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

— টিম লং

19

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

— আরন

12

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

— অজয় শর্মা

6

মাইক্রোসফ্ট বলেছে: "ত্রুটি কোডগুলি ফেরত দেবেন না frame এবং "... কোনও সদস্য যদি এটির জন্য নকশাকৃত নকশা সফলভাবে করতে না পারে, তবে এটি কার্যকর করার ব্যর্থতা হিসাবে বিবেচনা করা উচিত এবং একটি ব্যতিক্রম নিক্ষেপ করা উচিত। msdn.microsoft.com/library/ms229030%28v=vs.100%29.aspx

— Matsen75

4

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

— জ্যাকবিবি

629

আমার ব্যক্তিগত নির্দেশিকাটি হ'ল: বর্তমান কোড ব্লকের একটি মৌলিক অনুমান মিথ্যা বলে প্রমাণিত হলে একটি ব্যতিক্রম ছুঁড়ে দেওয়া হয়।

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

উদাহরণ 2: বলুন আমার একটি আরও ফাংশন রয়েছে যা একটি তালিকা <> পরীক্ষা করে এবং এর দৈর্ঘ্য 50 টির বেশি হলে সত্য হয় এবং দৈর্ঘ্য কম হলে মিথ্যা হয়। এই ফাংশনটি প্রশ্নটি করে, "এই তালিকায় 50 টিরও বেশি আইটেম রয়েছে?" তবে এই প্রশ্নটি অনুমান করে - এটি ধরে নেওয়া হয় যে এটি দেওয়া হয়েছে তা একটি তালিকা। যদি আমি এটিকে একটি শূন্যস্থান হস্তান্তর করি তবে অনুমানটি মিথ্যা। সেক্ষেত্রে যদি ফাংশনটি সত্য বা মিথ্যা প্রত্যাবর্তন করে তবে তা তার নিজস্ব নিয়ম ভঙ্গ করছে। ফাংশনটি কোনও কিছুই ফিরিয়ে দিতে পারে না এবং দাবি করতে পারে না যে এটি প্রশ্নের সঠিক উত্তর দিয়েছে। সুতরাং এটি ফিরে আসে না - এটি একটি ব্যতিক্রম ছোঁড়ে।

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

এই সমীকরণের অন্য দিকটি হ'ল: যদি আপনি আপনার ক্রিয়াকলাপগুলি ঘন ঘন ব্যতিক্রম ছুঁড়ে দেখেন তবে আপনার সম্ভবত তাদের অনুমানগুলি পরিমার্জন করা দরকার।

— রেভস ডিজিটাল গাবেগ
সূত্র

15

একদম ঠিক! যখন কেবলমাত্র ফাংশন পূর্বশর্ত (যুক্তি সম্পর্কে অনুমান) নষ্ট হয়ে যায় তখনই একটি ব্যতিক্রম ছুঁড়ে ফেলা হয় !

— লাইটম্যান

11

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

— মোহন 20

এটিই সম্ভবত সেরা ব্যাখ্যা!

— গৌরব

ধন্যবাদ. So. অনেক। "ইজ দ্য কিং অফ ফ্রান্স টাক"। মেইনংয়ের জঙ্গলে গবেষণা করার আগে আমি এটি শুনেছি .... :) আপনাকে ধন্যবাদ। @ মোহন

— এরলিচবাচম্যান

285

কারণ তারা এমন জিনিস যা সাধারণত ঘটবে। ব্যতিক্রমগুলি প্রবাহ প্রক্রিয়া নিয়ন্ত্রণ নয়। ব্যবহারকারীরা প্রায়শই পাসওয়ার্ড ভুল পান, এটি ব্যতিক্রমী ঘটনা নয়। ব্যতিক্রম একটি সত্যই বিরল জিনিস হওয়া উচিত, UserHasDiedAtKeyboardপরিস্থিতি টাইপ করুন।

— ব্লোডার্ট
সূত্র

3

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

— Seun Osewa

9

+1 দুর্দান্ত উত্তর। আমি বিকাশকারীরা এপিআই এর উপর কাজ করে এতটাই হতাশ হয়ে পড়েছি যে আমাকে গ্রাস করতে হবে এবং প্রতিটি ছোট জিনিস ব্যতিক্রম ছুঁড়ে ফেলতে হবে। খুব কয়েকটি ক্ষেত্রে সত্যই ব্যতিক্রম প্রয়োজন। যদি আপনার 25 টি ভিন্ন ধরণের ব্যতিক্রম সংজ্ঞায়িত হয় তবে আপনার নকশাকে আবার একবার দেখুন, আপনি সম্ভবত এটি ভুল করছেন।

— 7wp

1

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

— রজত গুপ্ত

30

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

— জেসি

2

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

— দৃust় করে তোলে

67

আমার ছোট্ট গাইডলাইনগুলি দুর্দান্ত কোড "কোড সম্পূর্ণ" দ্বারা প্রভাবিত:

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

— কমান্ডার আগ্রহী
সূত্র

35

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

সম্পাদনা: আমি ব্যতিক্রমগুলি পছন্দ করি না কারণ কোনও কল কেবল কল দেখে কোনও পদ্ধতি ব্যতিক্রম ছুঁড়েছে তা আপনি বলতে পারবেন না। আপনি যদি পরিস্থিতিটি শালীন উপায়ে পরিচালনা করতে না পারেন তবেই কেবল ব্যতিক্রমগুলি কেন ব্যবহার করা উচিত তা মনে করুন (মনে করুন "মেমরির বাইরে" বা "কম্পিউটারে আগুন লাগছে")।

— রিভস এরিকশাফার
সূত্র

"আমি ব্যতিক্রমগুলি ব্যবহার করতে পছন্দ করি না কারণ কোনও কল কেবল কল দেখে কোনও পদ্ধতি ব্যতিক্রম ছুঁড়েছে তা আপনি বলতে পারবেন না languages" এই কারণেই ভাষাগুলি তাদের সমর্থন করে যাচাই করে ব্যতিক্রম চেক করা আছে।

— নিউটোপিয়ান

1

চেক করা ব্যতিক্রমগুলির নিজস্ব সমস্যাগুলির সেট রয়েছে। আমি তবুও "ব্যতিক্রমী পরিস্থিতিতে" ব্যতিক্রমগুলি ব্যবহার করব, সাধারণ কাজের প্রবাহের অংশগুলির মতো নয়।

— এরিকশাফার

2

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

— ম্যাথু ভাইনস

1

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

— রজত গুপ্ত

1

মনে হচ্ছে আপনি হ্যান্ডলিং ত্রুটি সম্পর্কে কথা বলছেন (আমাদের স্মৃতি, ফায়ার কম্পিউটার) বনাম হ্যান্ডলিং কোড ব্যতিক্রম (নিখোঁজ রেকর্ড, অবৈধ ইনপুট প্রকার ইত্যাদি)। আমি মনে করি উভয়ের মধ্যে একটি স্বতন্ত্র পার্থক্য রয়েছে।

— চক বার্গেস

28

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

— japollock
সূত্র

6

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

— আপত্তি ছোঁড়াতে

2

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

— জানাতে পারি

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

— user1451111

23

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

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

— বজর্ন রেপেন
সূত্র

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

— blowdart

7

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

— বজর্ন রিপেন

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

— পেপারহর্স

7

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

— বেলুচিন

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

— দি মায়ার

17

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

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

— মিচেল বিক্রেতারা
সূত্র

14

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

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

পূর্বশর্ত পূরণ করা হয় নি (যা সাধারণত নিম্নলিখিতগুলির মধ্যে একটিকে অসম্ভব করে তোলে) বা
বিকল্প একটি পোস্ট শর্ত পূরণ করতে ব্যর্থ হবে বা
বিকল্প একটি আক্রমণকারী বজায় রাখতে ব্যর্থ হবে।

কেন এই ভাল? এটি পূর্ব শর্ত, পোস্টকন্ডিশন এবং আক্রমণকারী সম্পর্কে বেশ কয়েকটি প্রশ্নের সাথে প্রশ্নটিকে প্রতিস্থাপন করে না ? এটি বেশ কয়েকটি সংযুক্ত কারণে ভাল।

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

— রায়েডওয়াল্ড
সূত্র

10

আমি বলব কখন ব্যতিক্রম ব্যবহার করবেন সে সম্পর্কে কোনও কঠোর এবং দ্রুত নিয়ম নেই। তবে এগুলি ব্যবহার বা ব্যবহার না করার পিছনে ভাল কারণ রয়েছে:

ব্যতিক্রমগুলি ব্যবহার করার কারণগুলি:

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

ব্যতিক্রমগুলি ব্যবহার না করার কারণগুলি:

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

সাধারণভাবে, আমি সি ++ বা সি # এর চেয়ে জাভাতে ব্যতিক্রমগুলি ব্যবহার করতে বেশি ঝোঁক হব, কারণ আমি এই মতামত নিয়েছি যে আপনার ব্যতিক্রম গ্যারান্টি পরিবর্তন করার কারণে একটি ব্যতিক্রম ঘোষণা করা বা না হওয়া মূলত কোনও ফাংশনের আনুষ্ঠানিক ইন্টারফেসের অংশ since ব্রেক কলিং কোড এগুলি জাভা আইএমওতে ব্যবহার করার সর্বাধিক সুবিধা হ'ল আপনি জানেন যে আপনার কলার অবশ্যই এই ব্যতিক্রমটি পরিচালনা করতে পারে এবং এটি সঠিক আচরণের সুযোগকে উন্নত করে।

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

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

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

5

ব্যতিক্রম ক্লাসগুলি "সাধারণ" ক্লাসগুলির মতো। আপনি যখন নতুন ক্ষেত্র তৈরি করেন যখন এটি বিভিন্ন ক্ষেত্র এবং বিভিন্ন ক্রিয়াকলাপের সাথে বিভিন্ন ধরণের অবজেক্টটি "হয়" হয়।

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

— Shachar
সূত্র

5

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

সুতরাং, সংক্ষিপ্ত উত্তরটি হ'ল যদি এটি কোনও উল্লেখযোগ্য পারফরম্যান্স পেনাল্টির কারণ না ঘটায় (যা আপনি প্রচুর ব্যতিক্রম না ছোঁড়েন না এমন হওয়া উচিত), তবে এগিয়ে যান।

— চার্লস গ্রাহাম
সূত্র

আমি একটি লুপের ভিতরে ব্যতিক্রমগুলি সম্পর্কে আপনার মন্তব্যটি সত্যিই পছন্দ করেছি এবং এটি নিজে চেষ্টা করে দেখব। আমি একটি লুপ int.MaxValueবার চালিত একটি নমুনা প্রোগ্রাম লিখেছিলাম এবং এতে 'শূন্য দ্বারা বিভাজন' ব্যতিক্রম উত্পন্ন করি। আইএফ / ইএলএসই সংস্করণ, যেখানে আমি ডিভিশন অপারেশনের আগে লভ্যাংশটি শূন্য নয় কিনা তা যাচাই করেছিলাম , 82০৮২ এমএস এবং ১৫৪০7777২২ টিকিটে সম্পন্ন হয়েছে যেখানে TRY / CATCH সংস্করণ, যেখানে আমি ব্যতিক্রম উত্পন্ন করছিলাম এবং ব্যতিক্রম ধরছিলাম, ২৮১74৩৩৮৮ এ সম্পূর্ণ হয়েছিল এমএস এবং 71371326155 টিক্স: if / অন্য সংস্করণের চেয়ে 4632 গুণ বেশি বেশি।

— user1451111

3

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

আমি যুক্ত করতে চাই, নির্দ্বিধায় একটি আদর্শ ব্যতিক্রম ছুঁড়ে ফেলি। যদি আপনি কিছু "আলাদা" না করেন (অবহেলা করুন, ইমেল করুন, লগ করুন, সেই টুইটার তিমির ছবি জিনিসপত্র ইত্যাদি দেখান) তবে কাস্টম ব্যতিক্রমগুলি নিয়ে বিরক্ত করবেন না।

— dclaysmith
সূত্র

3

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

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

— Goran
সূত্র

2

আপনার অ্যাপ্লিকেশনটিতে "ব্যতিক্রমী" যেটি ঘটতে পারে তার জন্য সাধারণভাবে আপনি একটি ব্যতিক্রম ছুঁড়ে ফেলতে চান

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

তারা আপনার ইউএমএলের মূল প্রবাহে "ব্যতিক্রম" তবে প্রক্রিয়াজাতকরণে আরও "শাখা" রয়েছে।

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

— Gord
সূত্র

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

— user1451111

2

প্রথমত, যদি আপনার এপিআই এর ব্যবহারকারীরা নির্দিষ্ট, সূক্ষ্ম দানযুক্ত ব্যর্থতায় আগ্রহী না হন, তবে তাদের জন্য নির্দিষ্ট ব্যতিক্রমগুলি রাখার কোনও মূল্য নেই।

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

— জেসন ইথেরিজ
সূত্র

2

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

— জো স্কোরা
সূত্র

2

ব্যতিক্রম ব্যবহারে আমার দার্শনিক সমস্যা আছে। মূলত, আপনি একটি নির্দিষ্ট দৃশ্যের উপস্থিতি প্রত্যাশা করছেন, তবে এটি স্পষ্টভাবে পরিচালনা করার পরিবর্তে আপনি সমস্যাটিকে "অন্য কোথাও" পরিচালনা করতে চাপ দিচ্ছেন। এবং সেই "অন্য কোথাও" যে কারও অনুমান হতে পারে।

— দেনিযেল
সূত্র

2

আমি বলতে পারি যে সাধারণত প্রতিটি মৌলবাদ নরকে নিয়ে যায়।

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

আমি সাধারণত যা পছন্দ করি তা হ'ল দুটি প্রাথমিক ধরণের ব্যতিক্রম তৈরি করা যা পুরো সিস্টেম জুড়ে ব্যবহৃত হয়: লজিকাল এক্সেপশন এবং টেকনিক্যাল এক্সেপশন । এগুলি প্রয়োজন হলে সাব টাইপগুলির দ্বারা আরও আলাদা করা যেতে পারে তবে এটি সাধারণত প্রয়োজন হয় না।

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

অন্যদিকে যৌক্তিক ব্যতিক্রমগুলি উপরের স্তরগুলিতে কম গুরুতর ভ্রান্ত পরিস্থিতি প্রচার করতে ব্যবহৃত হয় (সাধারণত কিছু বৈধতার ফলাফল)।

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

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

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

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

— পেটর ম্যাসেক
সূত্র

2

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

— Genjuro
সূত্র

1

একটি ব্যতিক্রম নিক্ষেপ এড়ানোর মূল কারণ হ'ল ব্যতিক্রম ছোঁড়ার সাথে প্রচুর ওভারহেড জড়িত।

নীচের নিবন্ধটি একটি জিনিস বলেছে যে ব্যতিক্রমী শর্ত এবং ত্রুটির জন্য একটি ব্যতিক্রম an

একটি ভুল ব্যবহারকারীর নাম অবশ্যই প্রোগ্রাম ত্রুটি নয় তবে ব্যবহারকারীর ত্রুটি ...

এখানে মধ্যে .NET ব্যতিক্রম জন্য একটি শালীন শুরু হয় http://msdn.microsoft.com/en-us/library/ms229030(VS.80).aspx

— স্যাম
সূত্র

1

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

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

— আরনো
সূত্র

1

আমার কাছে তিন ধরণের শর্ত রয়েছে যা আমি ধরি।

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

আশাকরি এটা সাহায্য করবে

— মাইকেল
সূত্র

1

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

— বেনামা
সূত্র

1

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

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

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

{ // class
    ...

    public LoginResult Login(string user, string password)
    {
        if (IsInvalidUser(user))
        {
            return new UserInvalidLoginResult(user);
        }
        else if (IsInvalidPassword(user, password))
        {
            return new PasswordInvalidLoginResult(user, password);
        }
        else
        {
            return new SuccessfulLoginResult();
        }
    }

    ...
}

public abstract class LoginResult
{
    public readonly string Message;

    protected LoginResult(string message)
    {
        this.Message = message;
    }
}

public class SuccessfulLoginResult : LoginResult
{
    public SucccessfulLogin(string user)
        : base(string.Format("Login for user '{0}' was successful.", user))
    { }
}

public class UserInvalidLoginResult : LoginResult
{
    public UserInvalidLoginResult(string user)
        : base(string.Format("The username '{0}' is invalid.", user))
    { }
}

public class PasswordInvalidLoginResult : LoginResult
{
    public PasswordInvalidLoginResult(string password, string user)
        : base(string.Format("The password '{0}' for username '{0}' is invalid.", password, user))
    { }
}

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

চেষ্টা () প্যাটার্নটি ব্যবহার করে যেমন বর্ণিত হয়েছে ঠিক তেমন একটি দৃশ্যে ব্যতিক্রমগুলি ব্যবহার এড়ানোর উদাহরণ এখানে:

public class ValidatedLogin
{
    public readonly string User;
    public readonly string Password;

    public ValidatedLogin(string user, string password)
    {
        if (IsInvalidUser(user))
        {
            throw new UserInvalidException(user);
        }
        else if (IsInvalidPassword(user, password))
        {
            throw new PasswordInvalidException(password);
        }

        this.User = user;
        this.Password = password;
    }

    public static bool TryCreate(string user, string password, out ValidatedLogin validatedLogin)
    {
        if (IsInvalidUser(user) || 
            IsInvalidPassword(user, password))
        {
            return false;
        }

        validatedLogin = new ValidatedLogin(user, password);

        return true;
    }
}

— ক্রিস
সূত্র

1

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

  এক্সচেঞ্জ_কম্যান্ড ("ওপেন টেম্পাইল");
  এক্সচেঞ্জ_কম্যান্ড ("টেম্পাইল ফাইল ডেটা লিখুন {যাই হোক না কেন}");
  এক্সচেঞ্জ_কম্যান্ড ("টেম্পাইল ফাইল ডেটা লিখুন {যাই হোক না কেন}");
  এক্সচেঞ্জ_কম্যান্ড ("টেম্পাইল ফাইল ডেটা লিখুন {যাই হোক না কেন}");
  এক্সচেঞ্জ_কম্যান্ড ("টেম্পাইল ফাইল ডেটা লিখুন {যাই হোক না কেন}");
  এক্সচেঞ্জ_কম্যান্ড ("ক্লোজ টেম্পাইল");
  এক্সচেঞ্জ_কম্যান্ড ("রিয়েলফাইলে টেম্পাইল ফাইলটি অনুলিপি করুন");

একজন পুরো ক্রমটি বাতিল করতে কোনও অপারেশনের ব্যর্থতা চান। এটি সফল হওয়ার জন্য প্রতিটি ক্রিয়াকলাপ পরীক্ষা করতে পারে এমন সময়, কমান্ড ব্যর্থ হলে এক্সচেঞ্জ_কম্যান্ড () রুটিন একটি ব্যতিক্রম ছুঁড়ে ফেলা আরও সহায়ক।

প্রকৃতপক্ষে, উপরের দৃশ্যে অনেকগুলি ব্যর্থতা-পরিচালনা পদ্ধতি নির্বাচন করার জন্য প্যারামিটার রাখা সহায়ক হতে পারে: ব্যতিক্রম কখনও ছুঁবেন না, কেবল যোগাযোগের ত্রুটির জন্য ব্যতিক্রম নিক্ষেপ করবেন না বা কোনও ক্ষেত্রেই কমান্ড "সাফল্য ফিরে না পাবে" ব্যতিক্রম নিক্ষেপ করবে না " ইঙ্গিত.

— supercat
সূত্র

1

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

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

অবশ্যই, আপনি খালি ক্যাচ স্টেটমেন্টগুলির সাথে একই সমস্যা তৈরি করতে পারেন তবে কমপক্ষে সেগুলি চিহ্নিত করা সহজ এবং আপনার পক্ষে যুক্তি বোঝার দরকার নেই।

সুতরাং থাম্ব একটি নিয়ম হিসাবে:

আপনি যেখানে না চান সেগুলি ব্যবহার করুন বা কোনও ত্রুটি থেকে পুনরুদ্ধার করতে পারবেন না।

— রিভিউ ড্যানম্যান
সূত্র

0

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

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

— সেরহাট ওজগেল
সূত্র

0

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

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

— এলি
সূত্র

0

ব্যতিক্রম দুটি প্রধান শ্রেণি আছে:

1) সিস্টেম ব্যতিক্রম (যেমন ডাটাবেস সংযোগ হারিয়েছে) বা 2) ব্যবহারকারীর ব্যতিক্রম। (যেমন ব্যবহারকারী ইনপুট বৈধতা, 'পাসওয়ার্ড ভুল')

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

            If TypeName(ex) = "UserException" Then
               Display(ex.message)
            Else
               DisplayError("An unexpected error has occured, contact your help  desk")                   
               LogError(ex)
            End If

— কর্কশ
সূত্র

0

কোনও ব্যতিক্রম উপযুক্ত কিনা তা সিদ্ধান্ত নেওয়ার সময় কিছু দরকারী বিষয় চিন্তা করতে হবে:

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

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