চেক করা বনাম আনচেকড বনাম কোনও ব্যতিক্রম নয় ... বিপরীত বিশ্বাসের সেরা অনুশীলন

10

ব্যতিক্রমগুলি সঠিকভাবে জানাতে এবং পরিচালনা করতে একটি সিস্টেমের জন্য প্রয়োজনীয় অনেকগুলি প্রয়োজনীয়তা রয়েছে। ধারণাটি বাস্তবায়নের জন্য কোনও ভাষা বেছে নেওয়ার জন্য অনেকগুলি বিকল্প রয়েছে।

ব্যতিক্রমগুলির জন্য প্রয়োজনীয়তা (কোনও নির্দিষ্ট ক্রমে নয়):

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

কোডের ২.১ টি বাগগুলি যার ফলে কিছু ডেটা অবৈধ হয়ে যায়।

২.২ কনফিগারেশন বা অন্যান্য বাহ্যিক সংস্থার সমস্যা।

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

এইগুলি কভার করার জন্য নিম্নলিখিত ভাষাগুলি বিভিন্ন ভাষায় প্রয়োগ করা হয়েছিল:

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

সুতরাং প্রশ্নটি হ'ল:

এই বিষয়ে আপনার অভিজ্ঞতা কী এবং আপনার মতে কোনও ভাষা থাকার জন্য ভাল ব্যতিক্রম হ্যান্ডলিং সিস্টেম করার পক্ষে সেরা প্রার্থী কী?

সম্পাদনা: এই প্রশ্নটি লেখার কয়েক মিনিটের পরে আমি এই পোস্টটি জুড়ে এসেছি , ভুতুড়ে!

exceptions error-handling

— Newtopian
সূত্র

2

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

— জর্জিও

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

— মার্টিন বা

10

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

মাল্টিসেট রিটার্নের ধরণগুলি দুর্দান্ত তবে ব্যতিক্রমগুলির জন্য কোনও প্রতিস্থাপন নেই। ব্যতিক্রম ছাড়াই কোডটি ত্রুটি-চেক করার শব্দে পূর্ণ।

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

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

2

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

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

3

ক্যাসকেডিং ইস্যুটির জন্য +1। যে কোনও সিস্টেম / আর্কিটেকচার যা পরিবর্তনকে কঠিন করে তোলে কেবল সেগুলি বানর-প্যাচিং এবং অগোছালো সিস্টেমগুলিতে নিয়ে যায়, লেখকরা যেভাবে সেগুলি ভেবেছিল যে তারা কতটা সু-নকশাকৃত হয়েছে designed

— ম্যাথিউ এম।

2

@ নিউটোপিয়ান: টেমপ্লেটগুলি এমন কাজ করে যা কঠোর অবজেক্ট ওরিয়েন্টেশনে করা যায় না, যেমন জেনেরিক ধারকগুলির জন্য স্ট্যাটিক ধরণের সুরক্ষা সরবরাহ করে।

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

2

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

— সুপারক্যাট

7

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

— জর্জিও

9

দীর্ঘকাল ধরে OO ভাষাগুলি, ব্যতিক্রমগুলির ব্যবহার যোগাযোগের ত্রুটির জন্য ডি-ফ্যাক্টো স্ট্যান্ডার্ড standard তবে কার্যকরী প্রোগ্রামিং ল্যাঙ্গুয়েজগুলি ভিন্ন পদ্ধতির সম্ভাবনা সরবরাহ করে, উদাহরণস্বরূপ মনড ব্যবহার করে (যা আমি ব্যবহার করি নি), বা স্কট ওলাছিনের বর্ণনা অনুসারে আরও হালকা "রেলওয়ে ওরিয়েন্টেড প্রোগ্রামিং" using

এটি সত্যিই মাল্টিস্টেট ফলাফলের ধরণের একটি বৈকল্পিক।

একটি ফাংশন হয় সাফল্য, বা একটি ত্রুটি দেয়। এটি উভয়ই ফিরতে পারে না (যেমন টিউপলের ক্ষেত্রে রয়েছে)।
সমস্ত সম্ভাব্য ত্রুটিগুলি সংক্ষিপ্তভাবে নথিভুক্ত করা হয়েছে (বৈষম্যমূলক ইউনিয়ন হিসাবে ফলাফলের সাথে কমপক্ষে F # তে)।
ফলাফলটি যদি সাফল্য বা ব্যর্থতা হয় তবে কলকারী বিবেচনায় না নিয়ে ফলাফল ব্যবহার করতে পারবেন না।

ফলাফলের ধরণ এভাবে প্রকাশ করা যেতে পারে

type Result<'TSuccess,'TFail> =
| Success of 'TSuccess
| Fail of 'TFail

সুতরাং কোনও ফাংশনের ফলাফল যা এই ধরণের ফেরত দেয় তা হয় এক Successবা এক Failধরণের। এটি উভয় হতে পারে না।

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

// Create an updateUser function that takes an id, and new state
// as input, and updates an existing user.
let updateUser id input =
    validateInput input
    >>= loadUser id
    >>= updateUser input
    >>= saveUser id
    >>= notifyAboutUserUpdated

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

উপরের উদাহরণে ত্রুটি প্রকারের হতে পারে

type UserValidationErrorType =
| InvalidEmail of string
| MissingFirstName of string
... etc

type DbErrorType =
| RecordNotFound of int
| ConcurrencyError of int

type UpdateUserErrorType =
| InvalidInput of UserValidationErrorType
| DbError of DbErrorType

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

হাস্কেল-তে একটি doস্বরলিপি রয়েছে যা কোডটিকে আরও পরিষ্কার করে তুলতে পারে।

— পিট
সূত্র

2

খুব ভাল উত্তর এবং তথ্যসূত্র (রেলওয়ে ভিত্তিক প্রোগ্রামিং), +1। আপনি হাস্কেলের স্বীকৃতি উল্লেখ করতে চাইতে পারেন do, যা ফলাফলকে কোড আরও পরিষ্কার করে তোলে।

— জর্জিও

1

@ জর্জিও - আমি এখনই করেছি, তবে আমি হাস্কেলের সাথে কাজ করিনি, কেবলমাত্র এফ #, সুতরাং আমি এটি সম্পর্কে সত্যিই খুব বেশি লিখতে পারি না। আপনি চাইলে উত্তরটি যোগ করতে পারেন।

— পিট

ধন্যবাদ, আমি একটি ছোট উদাহরণ লিখেছি তবে যেহেতু এটি আপনার উত্তরের সাথে যুক্ত করা যথেষ্ট ছোট ছিল না আমি একটি সম্পূর্ণ উত্তর লিখেছিলাম (কিছু অতিরিক্ত ব্যাকগ্রাউন্ডের তথ্য সহ)।

— জর্জিও

2

Railway Oriented Programmingঠিক পরমাণুসদৃশ্য আচরণ।

— দেনিথ

5

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

সমস্যাটি হ'ল fকিছু ধরণের মান ফিরিয়ে আংশিক ফাংশন প্রয়োগ করা t। একটি সমাধান ফাংশন টাইপ আছে

f : ... -> t

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

f : ... -> t option

এবং SOME vসাফল্য এবং NONEব্যর্থতা ফিরে ।

বইটি পাঠ্যটি হ'ল, পাঠ্যটি আরও সাধারণ করার জন্য নিজের দ্বারা তৈরি ছোট ছোট অভিযোজন (বইটি একটি নির্দিষ্ট উদাহরণকে বোঝায়)। পরিবর্তিত পাঠ্যটি ইটালিকসে লেখা রয়েছে ।

দুটি সমাধানের মধ্যে ট্রেড-অফগুলি কী কী?

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

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

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

এটি ব্যতিক্রম এবং বিকল্প ফেরতের প্রকারের মধ্যে পছন্দ সম্পর্কিত concerned

রিটার্নের ধরণের ক্ষেত্রে ত্রুটি উপস্থাপন করা সমস্ত কোডে ত্রুটি চেকগুলিকে ছড়িয়ে দেয়: এই ধারণাটি হওয়া উচিত নয় Regarding হাস্কেলের একটি ছোট উদাহরণ এখানে এটি চিত্রিত করে।

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

import Text.Read

parseInt :: String -> Maybe Int
parseInt s = readMaybe s :: Maybe Int

safeDiv :: Int -> Int -> Maybe Int
safeDiv n d = if d /= 0 then Just (n `div` d) else Nothing

toString :: Maybe Int -> String
toString (Just i) = show i
toString Nothing  = "error"

main = do
         -- Get two lines from the terminal.
         nStr <- getLine
         dStr <- getLine

         -- Parse each string and divide.
         let r = do n <- parseInt nStr
                    d <- parseInt dStr
                    safeDiv n d

         -- Print the result.
         putStrLn $ toString r

পার্সিং এবং বিভাগটি let ...ব্লকটিতে সঞ্চালিত হয় । নোট করুন যে Maybeমোনাড এবং doস্বরলিপিটি ব্যবহার করে কেবলমাত্র সাফল্যের পথ নির্দিষ্ট করা হয়: Maybeমনডের শব্দার্থক শব্দগুলি স্পষ্টতই ত্রুটির মান প্রচার করে ( Nothing)। প্রোগ্রামারটির জন্য কোনও ওভারহেড নেই।

— জর্জিও
সূত্র

2

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

— সারা

1

আমি চেক করা ব্যতিক্রমগুলির একটি বড় অনুরাগী হয়েছি এবং সেগুলি কখন ব্যবহার করতে হয় সে সম্পর্কে আমি আমার সাধারণ নিয়মটি ভাগ করতে চাই।

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

//... bad code below.  the runnable variable
// tries to call the run() method before the variable
// is instantiated.  Running the code below will cause
// a NullPointerException.
Runnable runnable = null;
runnable.run();

একটি সাধারণ পরীক্ষা যেমন ত্রুটি এড়াতে পারত যেমন ...

Runnable runnable = null;
...
if (runnable != null)
{   runnable.run(); }

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

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

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

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

— জেমস মোলিয়ের
সূত্র

1

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

— ইইউএলএর

ব্যতিক্রম ব্যবহার করা এবং রিটার্ন কোড ব্যবহার করে বনাম তাদের পরীক্ষা না করা এবং শেষ পর্যন্ত তাদের পরীক্ষা না করা এগুলি সমস্ত একই কার্ডিয়াক অ্যারেস্টের ফল দেয়।

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

-1

আমি বর্তমানে একটি বৃহত ওওপি ভিত্তিক প্রকল্প / এপিআইয়ের মাঝখানে আছি এবং আমি ব্যতিক্রমগুলির এই বিন্যাসটি ব্যবহার করেছি। তবে এটি ব্যতিক্রম হ্যান্ডলিং এবং এর মতো আপনি কতটা গভীরভাবে যেতে চান তার উপর নির্ভর করে।

ExpectedException
- AuthorisedException
- EmptySetException
- NoRemainingException
- NoRowsException
- NotFoundException
- ValidationException

UnexpectedException
- ConnectivityException
- EnvironmentException
- ProgrammerException
- SQLException

EXAMPLE টি

   $valid_types = array('mysql', 'oracle', 'sqlite');
       if (!in_array($type, $valid_types)) {
           throw new ecProgrammerException(
        'The database type specified, %1$s, is invalid. Must be one of: %2$s.',
    $type,
    join(', ', $valid_types)
    );
}

— MattyD
সূত্র

11

যদি ব্যতিক্রম প্রত্যাশিত হয় তবে এটি সত্যই ব্যতিক্রম নয়। "NoRowsException"? আমার কাছে নিয়ন্ত্রণ প্রবাহের মতো শোনাচ্ছে এবং তাই এর ব্যতিক্রমহীন ব্যবহার।

— কোয়ান্টিন-স্টারিন

1

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

— কেভিন cline

1

প্রত্যাশিত = নিয়ন্ত্রণ প্রবাহ = ব্যতিক্রমবিরোধী pattern ব্যতিক্রম নিয়ন্ত্রণ প্রবাহের জন্য ব্যবহার করা উচিত নয়। যদি এটি নির্দিষ্ট ইনপুটটির জন্য ত্রুটি তৈরির প্রত্যাশা করে, তবে এটি কেবল রিটার্ন মূল্যের একটি অংশে পাস হবে। সুতরাং আমাদের আছে NANবা NULL।

— Eonil

1

@ ইউনিল ... বা বিকল্প <টি>

— মার্টেন বোদেউইস