এলমের দাবির মতো "কোনও রানটাইম ব্যতিক্রম না" লাভ কী?

16

কিছু ভাষাগুলি তাদের কাছে থাকা অন্যান্য ভাষার চেয়ে সুস্পষ্ট সুবিধা হিসাবে "কোনও রানটাইম ব্যতিক্রম নেই" বলে দাবি করে।

বিষয়টি নিয়ে আমি বিভ্রান্ত।

রানটাইম ব্যতিক্রম কেবলমাত্র একটি সরঞ্জাম, যতদূর আমি জানি এবং যখন ভালভাবে ব্যবহৃত হয়:

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

অন্যদিকে আমি একটি সফ্টওয়্যার ডিবাগ করা সত্যিই কঠিন মনে করি যা ব্যতিক্রম "গিলে ফেলে"। যেমন

try { 
  myFailingCode(); 
} catch {
  // no logs, no crashes, just a dirty state
}

সুতরাং প্রশ্নটি হ'ল: "কোনও রানটাইম ব্যতিক্রম নেই" এর শক্ত, তাত্ত্বিক সুবিধা কী?

উদাহরণ

https://guide.elm-lang.org/

অনুশীলনে কোনও রানটাইম ত্রুটি নেই। নাল না। কোনও অপরিজ্ঞাত কোনও ফাংশন নয়।

— atoth
সূত্র

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

— জিমি জেমস

সর্বশেষ উদাহরণ আমি খুঁজে পেয়েছি সি, সি ++, সি #, জাভা, ECMAscript, ইত্যাদি আমি তুলনায় ইওরোপের একধরনের বৃক্ষ ছিল আমার প্রশ্নের @JimmyJames আপডেট করেছি

— atoth

2

এটি আমি এটির প্রথম শুনেছি। আমার প্রথম প্রতিক্রিয়া হ'ল বিএসকে ফোন করা।

— নেজেল

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

— আন্দ্রেস এফ।

ঠিক আছে, আমি চেয়েছিলাম যে এটি যথেষ্ট সাধারণ হোক, তবে আমি তাতে সম্মত হতে পারি যদি এটি সাহায্য করে তবে @ অ্যান্ড্রেসএফ আপনার অবদানের জন্য ধন্যবাদ!

— atoth

28

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

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

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

নিম্নলিখিত উদাহরণ বিবেচনা করুন। আপনি যদি এটিটি কার্যক্রমে দেখতে চান তবে আপনি এটি http://elm-lang.org/try এ পেস্ট করতে পারেন।

import Html exposing (Html, Attribute, beginnerProgram, text, div, input)
import Html.Attributes exposing (..)
import Html.Events exposing (onInput)
import String

main =
  beginnerProgram { model = "", view = view, update = update }

-- UPDATE

type Msg = NewContent String

update (NewContent content) oldContent =
  content

getDefault = Result.withDefault "Please enter an integer" 

double = Result.map (\x -> x*2)

calculate = String.toInt >> double >> Result.map toString >> getDefault

-- VIEW

view content =
  div []
    [ input [ placeholder "Number to double", onInput NewContent, myStyle ] []
    , div [ myStyle ] [ text (calculate content) ]
    ]

myStyle =
  style
    [ ("width", "100%")
    , ("height", "40px")
    , ("padding", "10px 0")
    , ("font-size", "2em")
    , ("text-align", "center")
    ]

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

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

— কার্ল বিলেফেল্ট
সূত্র

8

That means you get a compiler error if you don't handle the error.- ঠিক আছে, এটি জাভাতে চেকড ব্যতিক্রমগুলির পিছনে যুক্তি ছিল, তবে আমরা সবাই জানি যে এটি কতটা কার্যকর হয়েছিল।

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

4

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

— আন্দ্রেস এফ।

3

@ জিমি জেমস না, তারা আপনাকে জোর করে না। আপনি যখন মানটি ব্যবহার করতে চান তখন আপনাকে কেবল ত্রুটিটি "পরিচালনা করতে হবে"। তাহলে আমি কি x = some_func(), আমি না আছে কিছু করতে যদি না আমি এর মান পরীক্ষা করার জন্য চান x, যে ক্ষেত্রে আমি পরীক্ষা করতে পারবেন কিনা আমি একটি ত্রুটি বা "বৈধ" মান আছে; তদ্ব্যতীত, এটি অন্যটির জায়গায় ব্যবহারের চেষ্টা করার ক্ষেত্রে স্থির ধরনের ত্রুটি, তাই আমি এটি করতে পারি না। যদি এলমের ধরণগুলি অন্যান্য কার্যকরী ভাষার মতো কিছু কাজ করে তবে আমি ত্রুটি আছে কিনা তা জানার আগেও আমি আসলে বিভিন্ন ফাংশন থেকে রচনা মানগুলির মতো স্টাফ করতে পারি ! এটি সাধারণত এফপি ভাষার সাধারণ typ

— আন্দ্রেস এফ।

6

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

— Andres F.

6

@atoth আপনি যদি এই সমস্ত কিছু থেকে একটি জিনিস নিতে চান তবে এটি নিন: সর্বদা নিশ্চিত হন যে আপনি ব্লব প্যারাডক্সের শিকার না হন । নতুন সিনট্যাক্সে বিরক্ত হবেন না। সম্ভবত সেখানে শক্তিশালী বৈশিষ্ট্যগুলির কারণে আপনি অপরিচিত হন :)

— Andres F.

10

এই বিবৃতিটি বুঝতে, আমাদের প্রথমে বুঝতে হবে একটি স্ট্যাটিক টাইপ সিস্টেম আমাদের কী কিনে। সংক্ষেপে, একটি স্ট্যাটিক টাইপ সিস্টেম আমাদের যা দেয় তা একটি গ্যারান্টি: যদি প্রোগ্রামের ধরণটি পরীক্ষা করে নেওয়া হয় তবে রানটাইম আচরণের একটি নির্দিষ্ট শ্রেণি ঘটতে পারে না।

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

সুতরাং, প্রোগ্রামগুলিতে অসীমভাবে অনেকগুলি বিভিন্ন রানটাইম আচরণ থাকতে পারে। এর মধ্যে অসীম অনেকগুলি দরকারী, তবে অসীমভাবে অনেকগুলি "ভুল" ("সঠিকতা" এর বিভিন্ন সংজ্ঞার জন্য)। একটি স্ট্যাটিক টাইপ সিস্টেম আমাদের প্রমাণ করতে দেয় যে একটি নির্দিষ্ট সীমাবদ্ধ, নির্দিষ্ট সীমিত সেট those অসীম অনেকগুলি ভুল রানটাইম আচরণের ঘটতে পারে না।

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

আগদার মতো আরও শক্তিশালী প্রকারের সিস্টেমগুলি "দুটি যুক্তির যোগফল প্রদান করবে" বা "একটি আর্গুমেন্ট হিসাবে তালিকার সাজানো সংস্করণটি ফিরিয়ে দেয়" এর মতো জিনিসগুলিও প্রমাণ করতে পারে।

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

সুতরাং, তারা না বলার অপেক্ষা রাখে না "আমরা ব্যতিক্রম বাস্তবায়ন না"। তারা বলছেন "যে বিষয়গুলি সাধারণত ভাষাগুলিতে রানটাইম ব্যতিক্রম হবে যেগুলি এলমের কাছে আসা সাধারণত প্রোগ্রামারদের অভিজ্ঞতা থাকতে পারে, তারা টাইপ সিস্টেমে ধরা পড়ে"। অবশ্যই, ইদ্রিস, আগদা, গুরু, এপিগ্রাম, ইসাবেল / এইচএল, কক বা অনুরূপ ভাষা থেকে আসা কেউ এলমের তুলনায় তুলনামূলকভাবে দুর্বল হিসাবে দেখবেন see বিবৃতিটি সাধারণত জাভা, সি♯, সি ++, অবজেক্টিভ-সি, পিএইচপি, ইসমাস্ক্রিপ্ট, পাইথন, রুবি, পার্ল,… প্রোগ্রামারগুলিকে লক্ষ্য করে।

— জার্গ ডব্লু মিত্তাগ
সূত্র

5

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

— Jgrg ডব্লু মিট্টাগ

2

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

— বাগান মাথা

4

এলম একই কারণে কোনও রানটাইম ব্যতিক্রমের গ্যারান্টি দিতে পারে সি কোনও রানটাইম ব্যতিক্রমের গ্যারান্টি দিতে পারে: ভাষা ব্যতিক্রমগুলির ধারণাকে সমর্থন করে না।

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

এখানে ভূমিকা থেকে একটি উদাহরণ দেওয়া হয়েছে (কিছুটা সরলীকৃত):

view : String -> String 
view userInputAge =
  case String.toInt userInputAge of
    Err msg ->
        text "Not a valid number!"

    Ok age ->
        text "OK!"

toIntইনপুট পার্সেবল না হলে ফাংশনটি ব্যর্থ হতে পারে, সুতরাং এর রিটার্ন টাইপ Result String int। প্রকৃত পূর্ণসংখ্যার মান পেতে, আপনাকে প্যাটার্ন মিলের মাধ্যমে "আনপ্যাক" করতে হবে, যা আপনাকে উভয় ক্ষেত্রে পরিচালনা করতে বাধ্য করে।

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

— JacquesB
সূত্র

2

@atoth এখানে একটি উদাহরণ। কল্পনা করুন ভাষা এ ব্যতিক্রমগুলির অনুমতি দেয়। তারপরে আপনাকে ফাংশন দেওয়া হবে doSomeStuff(x: Int): Int। সাধারণত আপনি এটি কোনও ফেরতের প্রত্যাশা করেন Intতবে এটি কি ব্যতিক্রমও ছুঁড়ে দিতে পারে? এর উত্স কোডটি না দেখে আপনি জানতে পারবেন না। বিপরীতে, কোন ভাষা বি যা টাইপের মাধ্যমে ত্রুটিগুলি এনকোড করে তার একই ফাংশনটি ঘোষিত হতে পারে: doSomeStuff(x: Int): ErrorOrResultOfType<Int>(এলমে এই ধরণের আসলে নাম দেওয়া হয়েছে Result)। প্রথম ক্ষেত্রে থেকে পৃথক, ফাংশনটি ব্যর্থ হতে পারে কিনা তা এখনই তাত্ক্ষণিকভাবে স্পষ্ট এবং আপনার অবশ্যই এটি স্পষ্টভাবে পরিচালনা করতে হবে।

— আন্দ্রেস এফ।

1

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

— জিমি জেমস

2

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

— আন্দ্রেস এফ।

2

@AndresF। this is how you program in languages such as ML or Haskellহাস্কেলে, হ্যাঁ; এমএল, না। স্ট্যান্ডার্ড এমএল এবং প্রোগ্রামিং ভাষার গবেষক, রবার্ট হার্পার একটি বড় অবদানকারী ব্যতিক্রমকে দরকারী বলে বিবেচনা করে । ত্রুটি প্রকারের ক্ষেত্রে ফাংশন রচনার পথে আসতে পারে যেখানে আপনি নিশ্চয়তা দিতে পারেন যে কোনও ত্রুটি ঘটবে না। ব্যতিক্রমগুলির বিভিন্ন পারফরম্যান্সও রয়েছে। নিক্ষিপ্ত নয় এমন ব্যতিক্রমগুলির জন্য আপনি অর্থ প্রদান করেন না, তবে আপনি প্রতিবার ত্রুটির মান পরীক্ষা করার জন্য অর্থ প্রদান করেন এবং ব্যতিক্রমগুলি কিছু অ্যালগরিদমে ব্যাকট্র্যাকিং প্রকাশ করার একটি প্রাকৃতিক উপায়

— Dobal

2

@ জিমি জেমস আশা করি আপনি এখন দেখতে পাবেন যে চেক করা ব্যতিক্রম এবং প্রকৃত ত্রুটির ধরণগুলি কেবলমাত্র অতিমাত্রায় অনুরূপ। চেক করা ব্যতিক্রমগুলি কৌতূহলীভাবে একত্রিত হয় না, ব্যবহার করা জটিল এবং অভিব্যক্তিমূলক নয় (এবং তাই আপনি কেবল এগুলিকে "গ্রাস" করতে পারেন, যেমন এটি জাভার সাথে ঘটে)। যাচাই করা ব্যাতিক্রমগুলি কম জটিল which বুঝতে.

— আন্দ্রেস এফ।

2

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

এই প্রশ্নটি যে কোনও উপায়ে ব্যাখ্যা করা যেতে পারে, তবে আপনি যেহেতু মন্তব্যগুলিতে এলমের উল্লেখ করেছেন তাই প্রসঙ্গটি আরও পরিষ্কার।

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

মনে রাখবেন যে আপনি যখন ব্যতিক্রমগুলি ব্যবহার করবেন না তখন ত্রুটিগুলি অন্য, কম বিস্ময়কর উপায়ে এনকোড করা হয়। থেকে এলম এর ডকুমেন্টেশন :

এলমের একটি গ্যারান্টি হ'ল আপনি অনুশীলনে রানটাইম ত্রুটি দেখতে পাবেন না। NoRedInk প্রায় এক বছর ধরে প্রযোজনায় এলম ব্যবহার করে আসছে এবং এখনও তাদের একটি নেই! এলমের সমস্ত গ্যারান্টির মতো, এটি মৌলিক ভাষা নকশার পছন্দগুলিতে নেমে আসে। এই ক্ষেত্রে, এলম ত্রুটিগুলিকে ডেটা হিসাবে বিবেচনা করে fact (আপনি কি লক্ষ্য করেছেন যে আমরা এখানে জিনিসগুলিকে প্রচুর ডেটা তৈরি করি?)

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

— আন্দ্রেস এফ।
সূত্র

আমি কি এটি ভুলভাবে লিখছি, বা তারা কেবল একটি শব্দার্থিক গেম খেলছে? তারা "রান টাইম ব্যতিক্রম" নামটিকে নিষিদ্ধ ঘোষণা করে, তবে তারপরে এটিকে কেবল আলাদা ব্যবস্থার সাথে প্রতিস্থাপন করে যা স্ট্যাকটিকে ত্রুটির তথ্য জানায়। এটি কেবল একইরকম ধারণা বা অবজেক্টের ব্যতিক্রমের বাস্তবায়ন পরিবর্তন করার মতো বলে মনে হচ্ছে যা ত্রুটি বার্তাকে ভিন্নভাবে প্রয়োগ করে। এটি খুব কমই পৃথিবী-ছিন্নভিন্ন। এটি কোনও স্ট্যাটিকালি টাইপ করা ভাষার মতো is একটি COM HREULLT থেকে .NET ব্যতিক্রমে স্যুইচিংয়ের তুলনা করুন। বিভিন্ন মেকানিজম, তবে এখনও রান টাইম ব্যতিক্রম, আপনি যাকেই বলুন তা নয়।

— মাইক 17

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

— আন্দ্রেস এফ।

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

— আন্দ্রেস এফ।

1

আপনার মন্তব্য অনুসারে আমি মনে করি এটিতে "স্ট্যাটিক ধরণের চেক" এর চেয়ে বেশি কিছু আছে । আপনি এটি টাইপস্ক্রিপ্ট ব্যবহার করে জেএসে যুক্ত করতে পারেন যা একটি নতুন "মেক-অর-ব্রেক" ইকোসিস্টেমের চেয়ে অনেক কম সীমাবদ্ধ।

— atoth

1

@ অ্যান্ড্রেসএফ .: প্রযুক্তিগতভাবে বলতে গেলে জাভার ধরণের সিস্টেমের নতুন বৈশিষ্ট্যটি হল প্যারামেট্রিক পলিমারফিজম, যা which০ এর দশকের শেষভাগে গঠিত ils সুতরাং, কোনও পদ্ধতিতে বলতে গেলে "আধুনিক" বলতে যখন আপনি "জাভা নন" বোঝায় কিছুটা সঠিক।

— Jörg ডব্লু মিট্টাগ

0

এলমের দাবি:

অনুশীলনে কোনও রানটাইম ত্রুটি নেই । নাল না। কোনও অপরিজ্ঞাত কোনও ফাংশন নয়।

তবে আপনি রানটাইম ব্যতিক্রম সম্পর্কে জিজ্ঞাসা করুন । একটি পার্থক্য আছে।

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

সুতরাং, প্রশ্নটি হওয়া উচিত:

"কোনও রানটাইম ত্রুটি না থাকায়" কী লাভ?

আপনি যদি এমন কোনও কোড লিখতে পারেন যা কখনও রানটাইম ত্রুটি না করে, আপনার প্রোগ্রামগুলি কখনও ক্রাশ হবে না।

— হেক্টর
সূত্র