কেন বিকল্প / সম্ভবত একটি ভাল ধারণা বিবেচনা করা হয় এবং চেক ব্যতিক্রম নয়?

Question

কিছু প্রোগ্রামিং ল্যাঙ্গুয়েজ ভাষা যেমন স্কালায় ধারণার ধারণাগুলি রয়েছে Option(এটিও বলা হয় Maybe), যার মধ্যে একটি মান থাকতে পারে বা নাও থাকতে পারে।

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

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

চেক করা ব্যতিক্রমগুলির সাথে কিছু অতিরিক্ত সমস্যা রয়েছে যা Optionধরণের নয়? বা এই ধারণাগুলি আমার মতামত হিসাবে সমান নয় এবং বিকল্পগুলির জন্য সুস্পষ্ট হ্যান্ডলিংকে বাধ্য করার জন্য এবং ব্যতিক্রমগুলির জন্য না করার পক্ষে ভাল কারণ রয়েছে?

Comments

আরো দেখুন Either e aডাটাটাইপ।

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

— hyde

Answer 1

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

পরিবর্তে, চেক করা ব্যতিক্রমগুলি কিছুটা সুরক্ষা যোগ করার সময়, তাদের ধরার চেয়ে আপনি তাদের সাথে তেমন কিছু করতে পারবেন না বা তাদের স্ট্যাকটি বুদবুদ করতে দিন (প্রকারের ঘোষণায় যুক্ত বয়লারপ্লেট সহ)।

Comments

চেক করা ব্যতিক্রমগুলি কম-বেশি একই পদ্ধতিতে রচনা করে ... এর মধ্যে পার্থক্য হয় try {/* bunch of complex code involving calls to 50 different methods that may throw SomeCheckedException */} catch(SomeCheckedException e) {/* operation failed, do something */}এবং fromMaybe someDefaultValue (something >>= otherThing >>= ...50 other functions that may return Nothing...)আসলে কী? প্রাক্তনটি আপনাকে কী ভুল হয়েছে তার আরও বিশদ সরবরাহ করে Other

— ব্যবহারকারী 253751

Answer 2

সম্পর্কিত থাকাকালীন, ব্যতিক্রম এবং হতে পারে বস্তুগুলি একই ধরণের সমস্যার সাথে মোকাবিলা করে না।

ব্যতিক্রমসমূহ

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

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

হতে পারে বস্তু

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

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

অপ্রয়োজনীয় ধরণের সমস্যা হ'ল একেবারে নিরাপদ থাকার জন্য আপনাকে সর্বদা নাল পরীক্ষা করতে হবে। "কিছু ভুল হতে পারে" রাষ্ট্রটি হ'ল ডিফল্ট।

রিটার্ন কোডগুলি + রেফ এপিস দিয়ে পাস করার সমস্যাটি হ'ল এগুলি বেশিরভাগ মানুষের কাছে কম পাঠযোগ্য।

Comments

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

— সাইমন বার্গোট

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

— হাইড

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

— মাইকেল শ

@ হাইড: তবে ব্যথা সরা হয়নি। অর্থহীন বয়লারপ্লেটটি এখনও আছে, কোনও কারণ ছাড়াই কোডটিকে বিশৃঙ্খলা করছে। বয়লারপ্লেটের কোনও কারণ থাকলে তা কী?

— মাইকেল শ

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

— জলদি

Answer 3

কারণ আপনার সাথে Maybeত্রুটিটি সাময়িকভাবে বিলম্ব করতে পারে যতক্ষণ না আপনার আসলে মূল্য প্রয়োজন হয় (যা কয়েক পদ্ধতি কল হতে পারে)

চেক ইন ব্যতিক্রম যেহেতু দরকার কল অবস্থানে নিয়ে নাড়াচাড়া করা

ব্যতিক্রমগুলির একমাত্র MaybeErrorবিপরীতটি হ'ল এটি কেন ব্যর্থ হয়েছিল সে সম্পর্কে আরও তথ্য দেওয়া যেতে পারে (যদি না এটির কোনও ত্রুটি হয় তখন কেউ নিক্ষেপযোগ্য ক্ষেত্রের সাথে বিকাশ না করে )

Comments

তবে আমার পদ্ধতিটি এই ব্যতিক্রমটি ছুঁড়েছে তা ঘোষণা করে আমি চেক করা ব্যতিক্রমটির পরিচালনাটি পিছিয়ে দিতে পারি।

— ম্যাড সায়েন্টিস্ট

@ ম্যাড সায়েন্টিস্ট যা কেবল কল স্ট্যাকের উপরে চলে যায়, যখন সম্ভবত সমস্ত দিকে যেতে পারে

— রাচেট ফ্রিক

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

— জর্জিও

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

— সুপারক্যাট