ব্যতিক্রম, ত্রুটি কোড এবং বৈষম্যমূলক ইউনিয়নগুলি


80

আমি সম্প্রতি একটি সি # প্রোগ্রামিং কাজ শুরু করেছি, তবে হাসকেলে আমি বেশ কিছুটা পটভূমি পেয়েছি।

তবে আমি বুঝতে পারছি সি # হ'ল একটি অবজেক্ট-ভিত্তিক ভাষা, আমি কোনও বৃত্তাকার গর্তে কোনও বৃত্তাকার খোঁচাকে জোর করতে চাই না।

আমি মাইক্রোসফ্ট থেকে এক্সেপশন নিক্ষেপ নিবন্ধটি পড়েছি যেখানে বলা হয়েছে:

ত্রুটি কোডগুলি ফেরত দেবেন না

তবে হাসকেলে অভ্যস্ত হয়ে আমি সি # ডেটা টাইপ ব্যবহার করে ফলাফলটিকে OneOf"ডান" মান বা ত্রুটি হিসাবে (বেশিরভাগ ক্ষেত্রে একটি গণনা) "বাম" মান হিসাবে ফিরিয়ে দিচ্ছি ।

এটি অনেকটা Eitherহাস্কেলের সম্মেলনের মতো ।

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

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

তবে এটি মাইক্রোসফ্টের মতামত বলে মনে হচ্ছে না।

OneOf"সাধারণ" ব্যতিক্রমগুলি (যেমন ফাইল পাওয়া যায় না ইত্যাদি) পরিচালনা করার ক্ষেত্রে ব্যতিক্রমগুলির পরিবর্তে কি যুক্তিসঙ্গত পদ্ধতির ব্যবহার করা বা এটি ভয়ানক অনুশীলন?


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

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


পরবর্তী চিন্তা:

এই আলোচনা থেকে আমি বর্তমানে যা নিচ্ছি তা নিম্নরূপ:

  1. আপনি যদি আশ্বস্ত কলার আশা করেন catchএবং ব্যতিক্রমটি বেশিরভাগ সময় পরিচালনা করেন এবং সম্ভবত এটি অন্য কোনও পথ ধরে চালিয়ে যান তবে এটি সম্ভবত রিটার্নের ধরণের অংশ হওয়া উচিত। Optionalবা OneOfএখানে দরকারী হতে পারে।
  2. আপনি যদি আশা করেন যে তাত্ক্ষণিক কলার বেশিরভাগ সময় ব্যতিক্রমটি না ধরেন তবে একটি ব্যতিক্রম নিক্ষেপ করুন, স্ট্যাকটি ম্যানুয়ালি পাস করার বোকামি বাঁচাতে।
  3. আপনি যদি নিশ্চিত হন না যে তাত্ক্ষণিক কলার কী করতে চলেছে তবে সম্ভবত Parseএবং পছন্দ মতো উভয়ই সরবরাহ করুন TryParse

13
এফ # Result;-) ব্যবহার করুন
অস্ট্রিনাস

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

9
সম্পর্কিত নিবন্ধ: ব্যতিক্রম চারটি "বালতি" নিয়ে এরিক লিপার্ট । তিনি বহিরাগত ধারণা সম্পর্কে যে উদাহরণ দেন তা দেখায় যে সেখানে এমন পরিস্থিতিতে আছে যেখানে আপনাকে কেবল ব্যতিক্রমগুলি মোকাবেলা করতে হবে, অর্থাত্‍ FileNotFoundException
সেরেন ডি Ptæus

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

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

উত্তর:


131

তবে আপনার ক্লায়েন্টের সফ্টওয়্যার ক্রাশ করা এখনও ভাল জিনিস নয়

এটি অবশ্যই একটি ভাল জিনিস।

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

শুনেছি কন্ট্রোল ফ্লো হিসাবে ব্যতিক্রমগুলি একটি গুরুতর অ্যান্টিপ্যাটার্ন হিসাবে বিবেচিত হয়

এটি একেবারে সত্য তবে এটি প্রায়শই ভুল বোঝে। তারা যখন ব্যতিক্রম সিস্টেমটি আবিষ্কার করেছিল তারা ভয় পেয়েছিল যে তারা কাঠামোগত প্রোগ্রামিংটি ভেঙে ফেলছে। স্ট্রাকচার্ড প্রোগ্রামিং কেন আমরা আছে for, while, until, break, এবং continueযখন সমস্ত আমরা প্রয়োজন, যে সব কাজ করতে হয় goto

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

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

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

এখানে চিত্র বর্ণনা লিখুন

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

এর চেয়ে গুরুত্বপূর্ণ এটি আমাদের বিভ্রান্ত করছে না। উপরের কোডটিতে অসীম লুপটি দেখতে আপনাকে কতক্ষণ সময় লাগল?

ত্রুটি কোডগুলি ফেরত দেবেন না

... আপনি যখন এমন কোনও বেস বেসে থাকুন যা সাধারণত ত্রুটি কোডগুলি ব্যবহার করে না তখন ... ভাল পরামর্শ। কেন? কারন কেউ রিটার্নের মানটি সংরক্ষণ করতে এবং আপনার ত্রুটি কোডগুলি পরীক্ষা করতে মনে রাখে না। আপনি সিতে থাকাকালীন এটি এখনও একটি দুর্দান্ত সম্মেলন

OneOf

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

আমি নিজেই কনভেনশন পছন্দ করি। আমি এর সর্বাধিক ভাল ব্যাখ্যা এখানে পেয়েছি * :

এখানে চিত্র বর্ণনা লিখুন

তবে আমার যতটুকু পছন্দ আমি এখনও অন্য কনভেনশনগুলির সাথে এটি মিশ্রিত করতে যাচ্ছি না। একটি বাছুন এবং এটি দিয়ে লাঠি। 1

1: যার অর্থ আমি একই সময়ে আমাকে একাধিক সম্মেলনের বিষয়ে ভাবতে বাধ্য করি না।


পরবর্তী চিন্তা:

এই আলোচনা থেকে আমি বর্তমানে যা নিচ্ছি তা নিম্নরূপ:

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

এটি সত্যই সহজ নয়। আপনার যে মৌলিক বিষয়গুলি বুঝতে হবে তা হ'ল শূন্যটি কী।

মে মাসে আর কত দিন বাকি? 0 (কারণ এটি মে নয় It's জুন এরই মধ্যে)।

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

উদাহরণস্বরূপ 2 :

IList<int> ParseAllTheInts(String s) { ... }

আপনি ইচ্ছাকৃতভাবে যে কোনও কিছু ছুঁড়ে ফেলেছেন এমন কোনও ভাল কারণ সম্পর্কে এটি ভাবতে পারেন? অনুমান করুন যখন কোন ইনট পার্স করা যায় না তখন আপনি কী পান? আমি আপনাকে বলার প্রয়োজন নেই।

এটি একটি ভাল নামের লক্ষণ। দুঃখিত তবে ট্রাইপার্স ভাল নাম সম্পর্কে আমার ধারণা নয়।

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

IList<Point> Intersection(Line a, Line b) { ... }

সমান্তরাল রেখাগুলি এখানে কি সত্যিই একটি ব্যতিক্রম ঘটায়? এই তালিকায় যদি কখনও এক পয়েন্টের বেশি থাকে না তবে এটি কি সত্যই খারাপ?

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

Maybe<Point> Intersection(Line a, Line b) { ... }

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

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


আপনি যদি আমাকে জড়িত হন তবে আমি এই মন্তব্যটি সম্বোধন করতে চাই:

উত্তরের যে কোনওটি কীভাবে স্পষ্ট করে না যে হয় মোনাদ একটি ত্রুটি কোড নয় এবং ওয়ানওফও নয়? এগুলি মূলত পৃথক, এবং ফলস্বরূপ প্রশ্নটি একটি ভুল বোঝাবুঝির ভিত্তিতে দেখা যাচ্ছে। (যদিও পরিবর্তিত আকারে এটি এখনও একটি বৈধ প্রশ্ন)) - কনরাড রুডল্ফ জুন 4 `18 14:08 এ

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


9
যদি লাল ট্র্যাকটি বাক্সগুলির নীচে থাকে তবে এটিগুলি দিয়ে না চললে এটি আরও উপযুক্ত হবে না?
ফ্ল্যাটার

4
যৌক্তিকভাবে, আপনি সঠিক। তবে, এই নির্দিষ্ট চিত্রের প্রতিটি বাক্স একটি monadic বাইন্ড অপারেশন উপস্থাপন করে। বাইন্ডে লাল ট্র্যাক অন্তর্ভুক্ত (সম্ভবত তৈরি করা হয়!)। আমি সম্পূর্ণ উপস্থাপনা দেখার সুপারিশ। এটি আকর্ষণীয় এবং স্কট দুর্দান্ত বক্তা।
গুডডোর

7
আমি ব্যতিক্রমগুলি আরও একটি গোটোর চেয়ে COMEFROM নির্দেশের মতোই মনে করি , যেহেতু throwআমরা আসলে কোথায় যাব জানি না / বলতে পারে না;)
ওয়ারবো

3
মিশ্রণ কনভেনশনগুলির মধ্যে কোনও ভুল নেই যদি আপনি সীমানা প্রতিষ্ঠা করতে পারেন তবে এটিই যা এনক্যাপসুলেশন about
রবার্ট হার্ভে

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

35

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

শুনেছি কন্ট্রোল ফ্লো হিসাবে ব্যতিক্রমগুলি একটি গুরুতর প্রতিরোধী হিসাবে বিবেচিত হয়,

এটি সর্বজনস্বীকৃত সত্য নয়। ব্যতিক্রমগুলিকে সমর্থন করে এমন প্রতিটি ভাষার পছন্দটি হ'ল হয় ব্যতিক্রম (যা কলকারী হ্যান্ডেল করতে মুক্ত নয়) বা কিছু যৌগিক মান (যা কলার হ্যান্ডেল আবশ্যক) ফিরিয়ে দেয়।

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


9
সন্ন্যাস প্রচারের জন্য কিছুই দরকার হয় না।
বেসিলিভস

23
@ বাসিলিভস কোডটি পঠনযোগ্য রাখার সময় মনডের প্রচারের জন্য এটির সমর্থন দরকার, যা সি # নেই। আপনি হয় যদি ফেরত নির্দেশাবলী বা ল্যাম্বডাসের চেইনগুলি পুনরাবৃত্তি করেন।
সেবাস্তিয়ান রেডল

4
@ সেবাস্তিয়ানআরড ল্যাম্বডাস সি # তে ঠিক আছে look
বেসিলিভস

@ বাসিলিভস একটি সিনট্যাক্স ভিউ থেকে হ্যাঁ, তবে আমি পারফরম্যান্সের দৃষ্টিভঙ্গি থেকে সন্দেহ করি তারা কম আবেদন করতে পারে।
ফারাপ

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

26

আপনি একটি আকর্ষণীয় সময়ে সি # এ এসেছেন। অপেক্ষাকৃত সাম্প্রতিক অবধি অবধি ভাষা অপরিহার্য প্রোগ্রামিং স্পেসে দৃly়ভাবে বসেছিল sat ত্রুটিগুলি যোগাযোগ করতে ব্যতিক্রমগুলি ব্যবহার করা অবশ্যই আদর্শ ছিল। রিটার্ন কোডগুলি ভাষার সহায়তার অভাবে (যেমন বৈষম্যমূলক ইউনিয়ন এবং প্যাটার্ন মিলের আশেপাশে) ভুগেছে Using বেশ যুক্তিসঙ্গতভাবে, মাইক্রোসফ্টের সরকারী নির্দেশিকাটি ছিল রিটার্ন কোডগুলি এড়ানো এবং ব্যতিক্রমগুলি ব্যবহার করা।

যদিও সর্বদা এর ব্যতিক্রম হয়েছে TryXXXপদ্ধতিগুলির আকারে , যা একটি booleanসাফল্যের ফলাফল প্রত্যাবর্তন করবে এবং outপ্যারামিটারের মাধ্যমে দ্বিতীয় মান ফলাফল সরবরাহ করবে । এগুলি ফাংশনাল প্রোগ্রামিংয়ের "চেষ্টা" প্যাটার্নগুলির সাথে খুব মিল, সংরক্ষণ করুন যে ফলাফলটি কোনও Maybe<T>ফেরতের মানের পরিবর্তে আউট প্যারামিটারের মাধ্যমে আসে ।

তবে বিষয়গুলি পরিবর্তন হচ্ছে। ক্রিয়ামূলক প্রোগ্রামিং আরও জনপ্রিয় হয়ে উঠছে এবং সি # এর মতো ভাষাও সাড়া দিচ্ছে। সি # 7.0 ভাষার সাথে কিছু বেসিক প্যাটার্ন মেলানো বৈশিষ্ট্য প্রবর্তন করেছে; সি # 8 আরও পরিবর্তন আনবে, যার মধ্যে একটি স্যুইচ এক্সপ্রেশন, রিকার্সিভ প্যাটার্নস ইত্যাদি রয়েছে। এর পাশাপাশি, সি # এর জন্য "ফাংশনাল লাইব্রেরি" এর বিকাশ ঘটেছে , যেমন আমার নিজস্ব সুসচিন্ <T> লাইব্রেরি , যা বৈষম্যমূলক ইউনিয়নগুলির জন্য সমর্থনও সরবরাহ করে ।

এই দুটি জিনিস সমন্বিত মানে নীচের মত কোড ধীরে ধীরে জনপ্রিয়তায় বৃদ্ধি পাচ্ছে।

static Maybe<int> TryParseInt(string source) =>
    int.TryParse(source, out var result) ? new Some<int>(result) : none; 

public int GetNumberFromUser()
{
    Console.WriteLine("Please enter a number");
    while (true)
    {
        var userInput = Console.ReadLine();
        if (TryParseInt(userInput) is int value)
        {
            return value;
        }
        Console.WriteLine("That's not a valid number. Please try again");
    }
}

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

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


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

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

7
@ আলেকসান্দ্রডাবিনস্কি 1960 এর দশকের এখনকার বৈশিষ্ট্যগুলি যুক্ত করার সময় আপনি এটিকে ঘৃণা করবেন না।
ctrl-alt-delor

6
@ আলেকসান্ডারডুবিনস্কি হ্যাঁ। যেহেতু জাভা একবার কোনও জিনিস যুক্ত করার চেষ্টা করেছিল (জেনেরিকস), তারা ব্যর্থ হয়েছে, আমাদের এখন ভয়ঙ্কর জগাখিচুড়ি নিয়ে বেঁচে থাকতে হবে যার ফলশ্রুতিতে তারা পাঠ শিখেছে এবং কিছু যোগ করতে
ছাড়েনি

3
@ এজেন্ট_এল: আপনি কি জানেন জাভা যুক্ত করেছেন java.util.Stream(অর্ধবৃত্তিত আইমুনিউরেবল-অ্যালক) এবং ল্যাম্বডাস এখন, তাই না? :)
সিএইচও

5

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

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

প্রকল্প পৃষ্ঠা থেকে উদাহরণ এখানে।

public OneOf<User, InvalidName, NameTaken> CreateUser(string username)
{
    if (!IsValid(username)) return new InvalidName();
    var user = _repo.FindByUsername(username);
    if(user != null) return new NameTaken();
    var user = new User(username);
    _repo.Save(user);
    return user;
}

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

ওয়ানওফ ডিগ্রি সিটিতে # ডিগ্রিবিহীন, এটি অন্য একটি প্রশ্ন। বাক্য গঠন বৈধ এবং যুক্তিসঙ্গত স্বজ্ঞাত। ডিইউ এবং রেল-ভিত্তিক প্রোগ্রামিং সুপরিচিত ধারণা ts

আমি এমন কিছু ব্যতিক্রমগুলি সংরক্ষণ করব যা ইঙ্গিত দেয় যে যেখানে কিছু সম্ভব সেখানে ভাঙা আছে।


আপনি যা বলছেন তা OneOfহ'ল রিটার্নের মানকে আরও ধনী করে তোলার মতো, কোনও নুলকে ফিরে আসার মতো। এটি এমন পরিস্থিতিতে ব্যতিক্রমগুলি প্রতিস্থাপন করে যা শুরু করার সাথে ব্যতিক্রমী নয়।
আলেকসান্দ্র ডাবিনস্কি

হ্যাঁ - এবং কলারের সাথে নিখরচায় মেলে করার একটি সহজ উপায় সরবরাহ করে, যা উত্তরাধিকার ভিত্তিক ফলাফলের ক্রমবর্ধমান ফলাফল ব্যবহার করা সম্ভব নয়।
mcintyre321

4

OneOfজাভাতে পরীক্ষিত ব্যতিক্রমগুলির সমতুল্য। কিছু পার্থক্য রয়েছে:

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

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

OneOf এবং পরীক্ষিত ব্যতিক্রমগুলির মধ্যে একটি গুরুত্বপূর্ণ "বৈশিষ্ট্য" রয়েছে:

  • তারা উভয়ই কল স্ট্যাকের সর্বত্র এগুলি পরিচালনা করতে আপনাকে বাধ্য করে force

এটি আপনার ভয় রোধ করে

সি # তে, ব্যতিক্রম উপেক্ষা করা একটি সংকলন ত্রুটি তৈরি করে না এবং যদি তারা ধরা না যায় তবে তারা কেবল বুদবুদ হয়ে আপনার প্রোগ্রামটি ক্রাশ করে।

তবে যেমনটি ইতিমধ্যে বলা হয়েছে, এই ভয়টি অযৌক্তিক। মূলত, আপনার প্রোগ্রামে সাধারণত একটি জায়গা থাকে, যেখানে আপনাকে সমস্ত কিছু ধরতে হবে (সম্ভাবনা আপনি ইতিমধ্যে এটি ব্যবহার করে একটি কাঠামো ব্যবহার করবেন)। আপনি এবং আপনার দলটি সাধারণত সপ্তাহে বা বছর ধরে প্রোগ্রামটিতে কাজ করার সময়, আপনি এটি ভুলে যাবেন না, তাই না?

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


+1 তবে ওয়ানঅফ পার্শ্ব প্রতিক্রিয়া নিয়ে কাজ করে না কেন? (আমার ধারণা এটি এর কারণ এটি যদি আপনি ফেরতের মান বরাদ্দ না করেন তবে এটি একটি চেক পাস করবে, তবে আমি
ওয়ানওফকে

1
আপনি উপার্জন ত্রুটি ফেরত বস্তুর দরকারী তথ্য যেমন ধারণ দ্বারা OneOf ত্রুটি তথ্য আসতে পারেন OneOf<SomeSuccess, SomeErrorInfo>যেখানে SomeErrorInfoত্রুটির বিবরণ প্রদান করে।
mcintyre321

@dcorking সম্পাদিত। অবশ্যই, আপনি যদি ফেরতের মানটিকে অগ্রাহ্য করেন, তবে কী সমস্যা হয়েছিল সে সম্পর্কে আপনি কিছুই জানেন না। আপনি যদি খাঁটি ফাংশন দিয়ে এটি করেন তবে এটি ঠিক আছে (আপনি কেবল সময় নষ্ট করেছেন)।
মার্টিনাস

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

4

"সাধারণ" ব্যতিক্রমগুলি (যেমন ফাইল পাওয়া যায় না ইত্যাদি) পরিচালনা করার ক্ষেত্রে ব্যতিক্রমের পরিবর্তে ওয়ানওফ ব্যবহার করা কি যুক্তিসঙ্গত পদ্ধতি বা এটি ভয়াবহ অনুশীলন?

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

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

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

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

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

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

সবশেষে, মনে রাখবেন যে ত্রুটির অবস্থার বিষয়ে সর্বাধিক গুরুত্বপূর্ণ বিষয়টি, যেমন তারা কীভাবে সিগন্যাল করা হয় তার চেয়ে অনেক বেশি বিবেচ্য বিষয়গুলি হ'ল সেগুলি পুরোপুরি নথিভুক্ত করা


2

অন্যান্য উত্তরগুলি ব্যতিক্রম সংক্রান্ত ত্রুটি কোডগুলি পর্যাপ্ত বিবরণে আলোচনা করেছে, সুতরাং আমি প্রশ্নের সাথে নির্দিষ্ট করে অন্য দৃষ্টিকোণটি যুক্ত করতে চাই:

OneOf একটি ত্রুটি কোড নয়, এটি আরও একটি মোনাদের মতো

এটি যেভাবে ব্যবহৃত হয়, OneOf<Value, Error1, Error2>এটি একটি ধারক যা হয় প্রকৃত ফলাফলকে উপস্থাপন করে বা কোনও ত্রুটির স্থিতি করে। এটি একটি এর মতো Optional, যখন কোনও মান উপস্থিত না থাকে, এটি কেন এটি আরও বিশদ সরবরাহ করতে পারে।

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

একমাত্র সমস্যাটি যখন আপনি ফলাফলটির বিষয়ে চিন্তা করেন না। ওয়ানওফের নথি থেকে প্রাপ্ত উদাহরণটি দেয়:

public OneOf<User, InvalidName, NameTaken> CreateUser(string username) { ... }

... এবং তারপরে তারা প্রতিটি ফলাফলের জন্য পৃথক এইচটিটিপি প্রতিক্রিয়া তৈরি করে, যা ব্যতিক্রমগুলি ব্যবহার করার চেয়ে অনেক ভাল। তবে আপনি যদি পদ্ধতিটিকে এভাবে কল করেন।

public void CreateUserButtonClick(String username) {
    UserManager.CreateUser(string username)
}

তারপর আপনি কি একটি সমস্যা আছে এবং ব্যতিক্রমগুলি ভাল পছন্দ হতে হবে। রেল এর তুলনা saveবনাম save!


1

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

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

int.TryParseমাঝখানে কোথাও। এটা খাঁটি। এটি উভয় ফলাফলের মান সর্বকালে কী তা সংজ্ঞায়িত করে - তাই আপনি জানেন যে যদি ফেরতের মান হয় falseতবে আউটপুট প্যারামিটার সেট করা হবে 0। এটি এখনও আপনাকে রিটার্ন মানটি পরীক্ষা না করে আউটপুট প্যারামিটার ব্যবহার করতে বাধা দেয় না, তবে কমপক্ষে আপনি গ্যারান্টিযুক্ত হ'ল এমনকি যদি ফাংশন ব্যর্থ হয় তবে ফলাফল কী what

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


0

সঠিক বিবৃতিটি হবে ব্যতিক্রমগুলির জন্য ত্রুটি কোডগুলি ব্যবহার করবেন না! এবং ব্যাতিক্রম ব্যতিক্রমগুলি ব্যবহার করবেন না।

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

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

(দ্রষ্টব্য যে আমি সি # তে খুব বেশি অভিজ্ঞ নই, তবে আমার উত্তরটি ব্যতিক্রমগুলির ধারণাগত স্তরের ভিত্তিতে সাধারণ ক্ষেত্রে থাকা উচিত))


7
আমি এই উত্তরটির ভিত্তিতে মৌলিকভাবে একমত নই। ভাষা ডিজাইনাররা পুনরুদ্ধারযোগ্য ত্রুটিগুলির জন্য ব্যতিক্রমগুলি ব্যবহার করতে চাইলে catchকীওয়ার্ডটির অস্তিত্ব থাকত না। এবং যেহেতু আমরা একটি সি # প্রসঙ্গে কথা বলছি, এটি লক্ষণীয় যে এখানে দর্শনের রচনাগুলি নেট। ফ্রেমওয়ার্ক অনুসরণ করে না; সম্ভবত "অবৈধ ইনপুট যা আপনি পরিচালনা করতে পারেন" এর সহজতম কল্পনাযোগ্য উদাহরণ হ'ল ব্যবহারকারী এমন একটি ক্ষেত্রে নন-নাম্বারে টাইপ করছেন যেখানে একটি সংখ্যা প্রত্যাশিত ... এবং int.Parseএকটি ব্যতিক্রম ছোঁড়ে।
মার্ক আমেরিকা

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

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

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

-2

এটি একটি 'ভয়ঙ্কর ধারণা'।

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

সুতরাং আপনাকে সমস্ত পদ্ধতি এবং ফাংশন এতে পরিবর্তন করতে হবে OneOf<Exception, ReturnType>, যদি আপনি বিভিন্ন ব্যতিক্রম প্রকারগুলি পরিচালনা করতে চান তবে আপনাকে প্রকার If(exception is FileNotFoundException)ইত্যাদি পরীক্ষা করতে হবে

try catch এর সমতুল্য OneOf<Exception, ReturnType>

সম্পাদনা করুন ----

আমি অবগত যে আপনি ফেরার প্রস্তাব দিচ্ছেন OneOf<ErrorEnum, ReturnType>তবে আমি মনে করি এটি কোনও পার্থক্য ছাড়াই কিছুটা পার্থক্য।

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


2
'সাধারণ' ব্যতিক্রমগুলি একটি ভয়ানক ধারণা are খেই নাম হয়
ইওয়ান

4
আমি ফিরে প্রস্তাব করছি না Exceptionসে।
ক্লিনটন

আপনি কি প্রস্তাব দিচ্ছেন যে কোনওটির বিকল্প হ'ল ব্যতিক্রমগুলির মাধ্যমে নিয়ন্ত্রণ প্রবাহ
ইওয়ান
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.