ব্যতিক্রম হ্যান্ডলিং প্রক্রিয়া ব্যতীত একটি আধুনিক ভাষা কেন ডিজাইন করুন?

Question

অনেক আধুনিক ভাষা সমৃদ্ধ ব্যতিক্রম হ্যান্ডলিং বৈশিষ্ট্যগুলি সরবরাহ করে, তবে অ্যাপলের সুইফ্ট প্রোগ্রামিং ল্যাঙ্গুয়েজ ব্যতিক্রম হ্যান্ডলিং প্রক্রিয়া সরবরাহ করে না ।

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

উদাহরণস্বরূপ আমি কীভাবে ভাল কিছু প্রকাশ করতে পারি

try:
    operation_that_can_throw_ioerror()
except IOError:
    handle_the_exception_somehow()
else:
     # we don't want to catch the IOError if it's raised
    another_operation_that_can_throw_ioerror()
finally:
    something_we_always_need_to_do()

কোনও ভাষাতে (উদাহরণস্বরূপ সুইফট) ব্যতিক্রম পরিচালনা পরিচালনা নেই?

Comments

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

— জেনসজি

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

— রবার্ট হার্ভে

আমি আপনাকে বেশ কিছু অনুসরণ করছি না, @ রবার্ট। সি ++ আবর্জনা সংগ্রহ ছাড়াই ব্যতিক্রমগুলি সমর্থন করে।

— কার্ল বিলেফেল্ট

@ কার্লবিলিফেল্ড: আমি যা বুঝি তার থেকে খুব ব্যয় করে। তারপরে আবার, এমন কি এমন কিছু আছে যা কমপক্ষে প্রচেষ্টা এবং প্রয়োজনীয় ডোমেন জ্ঞান ছাড়াই দুর্দান্ত ব্যয় ছাড়াই সি ++ এ গৃহীত হয়েছিল?

— রবার্ট হার্ভে

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

— orome

Answer 1

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

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

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

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

এখানে একটি ব্যবহার করে একটি উদাহরণ Futureথেকে এই Scala টিউটোরিয়াল :

val f: Future[List[String]] = future {
  session.getRecentPosts
}
f onFailure {
  case t => println("An error has occured: " + t.getMessage)
}
f onSuccess {
  case posts => for (post <- posts) println(post)
}

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

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

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

এগুলি হ'ল ধরণের জিনিস যা আপনি "ব্যতিক্রম হারানোর মাধ্যমে অর্জন করেন gain"

Comments

সুতরাং Futureএটির জন্য অপেক্ষা না করে মূলত কোনও ফাংশন থেকে প্রাপ্ত মানটি পরীক্ষা করার একটি উপায়। সুইফ্টের মতো এটিও রিটার্ন-ভ্যালু ভিত্তিক, তবে সুইফ্টের বিপরীতে, ফেরতের মানটির প্রতিক্রিয়া পরবর্তী সময়ে (ব্যতিক্রমের মতো কিছুটা) ঘটতে পারে। রাইট?

— ওরোম

আপনি Futureসঠিকভাবে বুঝতে পেরেছেন তবে আমি মনে করি আপনি সম্ভবত সুইফটকে ভুলভাবে চিহ্নিত করছেন। উদাহরণস্বরূপ, এই স্ট্যাকওভারফ্লো উত্তরের প্রথম অংশটি দেখুন ।

— কার্ল বিলেফেল্ট

হুম, আমি সুইফটে নতুন, সুতরাং উত্তরটি পার্স করা আমার পক্ষে কিছুটা কঠিন। কিন্তু যদি আমার ভুল না হলে যে মূলত একটি হ্যান্ডলার রয়েছে যা পাসের করতে পরবর্তী সময়ে প্রার্থনা হবে; ঠিক আছে?

— ওরোম 21

হ্যাঁ. আপনি যখন ত্রুটি ঘটে তখন আপনি মূলত একটি কলব্যাক তৈরি করছেন।

— কার্ল বিলেফেল্ড 21

Eitherআইএমএইচও

— পাওয়ে প্র্যাক

Answer 2

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

cleanMug();
brewCoffee();
pourCoffee();
drinkCoffee();

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

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

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

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

Comments

বিকল্পগুলি সহ সুইফ্টের যে ধরণের সিস্টেমটি এটি কার্যকর করে এটি কী "শক্তিশালী টাইপ সিস্টেম" বাছাই করে এটি সঠিক?

— orome

হ্যাঁ, বিকল্পগুলি এবং আরও সাধারণভাবে, যোগফলগুলি (সুইফ্ট / জংটিতে "এনাম" হিসাবে পরিচিত) এটি অর্জন করতে পারে। এগুলি ব্যবহারে আনন্দদায়ক করে তুলতে কিছু অতিরিক্ত কাজ লাগে, তবে: সুইফটে, এটি optionচ্ছিক চেইন সিনট্যাক্স দিয়ে অর্জন করা হয়; হাস্কেল-তে, এটি একাত্ত্বিক করণীয় দ্বারা সম্পাদিত।

— রাফলউইন্ড

কোনও "যথেষ্ট শক্তিশালী টাইপ সিস্টেম" কি স্ট্যাক ট্রেস দিতে পারে, যদি এটি

— একেবারেই

এটি উল্লেখ করার জন্য +1 ব্যতিক্রমগুলি নিয়ন্ত্রণের প্রবাহকে অস্পষ্ট করে। শুধু একটি auxilary নোট হিসাবে: এটা কারণ দাঁড়িয়েছে কিনা ব্যতিক্রম চেয়ে আসলে আরো খারাপ হয় না goto: gotoএকটি একক ফাংশন, খুবই ছোট পরিসর প্রদান ফাংশন সত্যিই যা ছোট অবধি সীমিত থাকবে, ব্যতিক্রম আরো কিছু ক্রস মত কাজ করে gotoএবং come from(দেখুন en.wikedia.org/wiki/INTERCAL ;-))। এটি বেশ কয়েকটি কোডের দুটি টুকরো সংযোগ করতে পারে, সম্ভবত কিছু তৃতীয় ফাংশনগুলি এড়িয়ে যায়। কেবলমাত্র এটি যা gotoকরতে পারে না, যা করতে পারে, ফিরে যাচ্ছে।

— 15-10 এ

@ PawełPrażak অনেকগুলি উচ্চ-অর্ডার ফাংশন নিয়ে কাজ করার সময়, স্ট্যাকের চিহ্নগুলি প্রায় মূল্যবান নয়। ইনপুট এবং আউটপুট সম্পর্কে দৃ guaran় গ্যারান্টি এবং পার্শ্ব প্রতিক্রিয়া এড়ানো এগুলি হ'ল এই দিকনির্দেশকে বিভ্রান্তিকর বাগগুলি সৃষ্টিতে বাধা দেয়।

— জ্যাক 18 ই

Answer 3

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

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

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

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

Comments

ধরা পড়ার উদ্দেশ্য হ'ল কোনও ত্রুটি হওয়ার পরে কোনও বস্তুকে সামঞ্জস্য করা (বা কোনও কিছু সম্ভব না হলে শেষ করে দেওয়া)।

— জুলিনরউজ

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

— চার্লি ফুল

Answer 4

আমি প্রথমে মরিচা ভাষা সম্পর্কে অবাক হয়েছি তা হ'ল এটি ব্যাতিক্রমগুলি সমর্থন করে না। আপনি ব্যতিক্রম ছুঁড়ে ফেলতে পারেন , তবে কোনও কাজ (থ্রেড থ্যাড, তবে সর্বদা পৃথক ওএস থ্রেড নয়) মারা গেলে কেবল রানটাইম তাদের ধরতে পারে; যদি আপনি নিজেই কোনও কাজ শুরু করেন, তবে আপনি জিজ্ঞাসা করতে পারেন যে এটি স্বাভাবিকভাবে উপস্থিত রয়েছে বা এটি fail!()সম্পাদিত কিনা ।

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

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

use std::io::IoResult;
use std::io::File;

fn load_file(name: &Path) -> IoResult<String>
{
    let mut file = try!(File::open(name));
    let s = try!(file.read_to_string());
    return Ok(s);
}

fn main()
{
    print!("{}", load_file(&Path::new("/tmp/hello")).unwrap());
}

Comments

সুতরাং এটাকে কী বলা উচিত (গো এর পদ্ধতির মত) সুইফটের সাথে মিল assert, তবে আছে catch?

— orome

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

— gnasher729

Answer 5

আমার মতে, ব্যর্থতা চালানোর সময় কোড ত্রুটি সনাক্ত করার জন্য একটি প্রয়োজনীয় সরঞ্জাম। উভয় পরীক্ষা এবং উত্পাদন। তাদের বার্তাগুলিকে যথেষ্ট পরিমাণে ভার্বোজ করুন যাতে স্ট্যাক ট্রেসের সাথে একত্রে আপনি লগ থেকে কী ঘটেছিল তা বুঝতে পারেন।

ব্যতিক্রমগুলি বেশিরভাগই একটি উন্নয়ন সরঞ্জাম এবং অপ্রত্যাশিত ক্ষেত্রে উত্পাদন থেকে যুক্তিসঙ্গত ত্রুটি প্রতিবেদন পাওয়ার উপায়।

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

এটি আসলে "অপ্রত্যাশিত" অর্থ।

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

সাধারণ উদাহরণ: একটি হ্যাশ মানচিত্রের এপিআইতে দুটি পদ্ধতি থাকতে পারে:

Value get(Key)

এবং

Option<Value> getOption(key)

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

কোড ব্যর্থ মৌলিক অনুমানের সাথে মোকাবিলা করার চেষ্টা করা উচিত নয়।

অবশ্যই এগুলি পরীক্ষা করে এবং ভালভাবে পঠনযোগ্য ব্যতিক্রম ছোঁড়া ছাড়া অবশ্যই।

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

সমস্ত জায়গায় ক্যাচ ব্লকগুলি খুব খারাপ ধারণা।

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

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

এটি, এবং তারা আসলে কী ভাল তা নিয়ে কিছু ভুল বোঝাবুঝি।

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

প্রত্যাশিত ত্রুটি মামলার ক্ষেত্রে কার্যকরী শৈলীর ত্রুটি পরিচালনা পরিচালনা দুর্দান্ত।

ব্যতিক্রম হ্যান্ডলিং সমস্ত স্বয়ংক্রিয়ভাবে সমস্ত যত্ন নিতে দেওয়া যাক, এটি এর জন্য :)

Answer 6

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

সুইফটের একটি বৈশিষ্ট্য রয়েছে যা ব্যতিক্রম হ্যান্ডলিংয়ের মতো লাগে তবে এটি কেবল ত্রুটি হ্যান্ডলিংয়ের সাথে প্রয়োগ করা হয়। Orতিহাসিকভাবে, অবজেক্টিভ-সি-তে যথেষ্ট বিস্তৃত ত্রুটি পরিচালনার প্যাটার্ন ছিল: একটি পদ্ধতি হয় হয় একটি BOOL (সাফল্যের জন্য হ্যাঁ) বা একটি অবজেক্ট রেফারেন্স (ব্যর্থতার জন্য শূন্য, সাফল্যের জন্য শূন্য নয়), এবং একটি প্যারামিটার "এনএসইরর * তে নির্দেশক *" থাকে যা এনএসইরর রেফারেন্স সঞ্চয় করতে ব্যবহৃত হবে। সুইফট স্বয়ংক্রিয়ভাবে কলগুলি যেমন কোনও পদ্ধতির কাছে ব্যতিক্রম হ্যান্ডলিংয়ের মতো দেখতে রূপান্তর করে।

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

Comments

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

— uliwitness

Answer 7

 int result;
 if((result = operation_that_can_throw_ioerror()) == IOError)
 {
  handle_the_exception_somehow();
 }
 else
 {
   # we don't want to catch the IOError if it's raised
   result = another_operation_that_can_throw_ioerror();
 }
 result |= something_we_always_need_to_do();
 return result;

সিতে আপনি উপরের মতো কিছু দিয়ে শেষ করবেন।

ব্যতিক্রমগুলি সহ আমি কী করতে পারি এমন সুইফটে আমি কিছু করতে পারি না?

না, কিছুই নেই। আপনি কেবল ব্যতিক্রমের পরিবর্তে ফলাফল কোডগুলি পরিচালনা করছেন।
ব্যতিক্রমগুলি আপনাকে আপনার কোডটি পুনর্গঠিত করার অনুমতি দেয় যাতে ত্রুটি পরিচালনা করা আপনার সুখী পথের কোড থেকে পৃথক হয়, তবে এটি এটির বিষয়ে।

Comments

এবং, একইভাবে, those কলগুলি ...throw_ioerror()ব্যতিক্রম ছুঁড়ে ফেলার পরিবর্তে ত্রুটিগুলি ফিরিয়ে আনবে?

— orome

@raxacoricofallapatorius যদি আমরা দাবি করি যে ব্যতিক্রমগুলি বিদ্যমান নেই তবে আমি ধরে নিই যে প্রোগ্রামটি ব্যর্থতার পরে এবং সাফল্যের সাথে 0 তে ত্রুটি কোডগুলি ফিরে আসার স্বাভাবিক প্যাটার্ন অনুসরণ করে।

— স্টোনমেটাল

@ স্টোনমেটাল কিছু ভাষা, যেমন মরচে এবং হাস্কেল, টাইপ সিস্টেমটি ত্রুটি কোডের চেয়ে কিছু বেশি অর্থবহ কিছু ফেরত দিতে ব্যবহার করে, ব্যতিক্রমগুলি যেভাবে লুকায়িত বহির্গমন পয়েন্টগুলি যোগ না করে। একটি মরচে ফাংশন, উদাহরণস্বরূপ, একটি ফেরত দিতে পারেন Result<T, E>enum, হয় একটি করা যেতে পারে Ok<T>, অথবা একটি Err<E>সঙ্গে Tধরনের কোনো চেয়েছিলেন হচ্ছে, এবং Eএকটি টাইপ করার সময় একটি ত্রুটি প্রতিনিধিত্বমূলক হচ্ছে। প্যাটার্ন মিল এবং কিছু নির্দিষ্ট পদ্ধতি সাফল্য এবং ব্যর্থতা উভয়েরই পরিচালনা সহজ করে তোলে। সংক্ষেপে, ব্যতিক্রমগুলির অভাবের অর্থ স্বয়ংক্রিয়ভাবে ত্রুটি কোডগুলি বোঝাবেন না।

— বিট্রি

Answer 8

চার্লির উত্তর ছাড়াও:

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

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

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

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

Comments

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

— Zan Lynx