নাল রেফারেন্স কি আসলেই খারাপ জিনিস?

161

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

এবং বিকল্প কি? আমি মনে করি এটি বলার পরিবর্তে:

Customer c = Customer.GetByLastName("Goodman"); // returns null if not found
if (c != null)
{
    Console.WriteLine(c.FirstName + " " + c.LastName + " is awesome!");
}
else { Console.WriteLine("There was no customer named Goodman.  How lame!"); }

আপনি এটি বলতে পারেন:

if (Customer.ExistsWithLastName("Goodman"))
{
    Customer c = Customer.GetByLastName("Goodman") // throws error if not found
    Console.WriteLine(c.FirstName + " " + c.LastName + " is awesome!"); 
}
else { Console.WriteLine("There was no customer named Goodman.  How lame!"); }

তবে কীভাবে ভালো? যে কোনও উপায়ে, আপনি যদি ক্রেতার উপস্থিতি পরীক্ষা করতে ভুলে যান তবে আপনি একটি ব্যতিক্রম পান।

আমি অনুমান করি যে গ্রাহকনোটফাউন্ডএক্সেপশনটি আরও বর্ণনামূলক হওয়ার কারণে নুলারফেরান এক্সেপশন থেকে ডিবাগ করা কিছুটা সহজ। সব আছে এটা যে হয় হয়?

language-design  exceptions  pointers  null 
— টিম গুডম্যান
সূত্র
54
আমি "যদি গ্রাহক উপস্থিত থাকে / তবে গ্রাহক পাবেন" পদ্ধতির বিষয়ে সতর্ক থাকব, আপনি যেমন দুটি লাইনের কোড লেখার সাথে সাথে আপনি জাতি শর্তের জন্য দরজা খুলছেন। পান, এবং তারপরে নালগুলি পরীক্ষা করুন / ব্যাতিক্রমণগুলি নিরাপদ।
— কারসন 63000
26
কেবলমাত্র যদি আমরা সমস্ত রানটাইম ত্রুটির উত্সটি দূর করতে পারি তবে আমাদের কোডটি নিখুঁত হওয়ার নিশ্চয়তা দেওয়া হবে! যদি সি # তে নুল রেফারেন্সগুলি আপনার মস্তিষ্ককে ভেঙে দেয়, তবে অবৈধ চেষ্টা করুন, তবে সি-তে পয়েন্টারগুলি নন-
— এনএলএল করুন
কিছু ভাষায় নাল কোলেসিং এবং নিরাপদ নেভিগেশন অপারেটর রয়েছে যদিও
— জে কে।
35
নাল প্রতি সে খারাপ নয়। একটি টাইপ সিস্টেম যা টাইপ টি এবং টাইপ টি + নাল মধ্যে কোনও পার্থক্য করে না এটি খারাপ is
— ইনগো
27
কয়েক বছর পরে আমার নিজের প্রশ্নে ফিরে আসছি, আমি এখন পুরোপুরি বিকল্প / সম্ভবত পদ্ধতির রূপান্তর।
— টিম গুডম্যান

উত্তর:

91

নাল মন্দ

: এই বিষয়ে InfoQ উপর একটি উপস্থাপনা নাল তথ্যসূত্র: বিলিয়ন ডলারের ভুল দ্বারা টনি হোয়ারে

অপশন টাইপ

ক্রিয়ামূলক প্রোগ্রামিংয়ের বিকল্পটি একটি বিকল্প ধরণ ব্যবহার করে যা এতে থাকতে পারে SOME valueবা থাকতে পারে NONE।

একটি ভাল নিবন্ধ "বিকল্প" প্যাটার্ন যা অপশন প্রকারের বিষয়ে আলোচনা করে এবং জাভা এর জন্য এটির একটি বাস্তবায়ন সরবরাহ করে।

আমি এই সমস্যাটির জন্য জাবার জন্য একটি বাগ-প্রতিবেদনও পেয়েছি: নালপয়েন্টারএক্সেপশনগুলি রোধ করতে জাভাতে নিস অপশন প্রকার যুক্ত করুন । অনুরোধের বৈশিষ্ট্য জাভা 8 চালু করা হয়।

— জোনাস
সূত্র
5
সি # তে অবিচ্ছিন্ন <x> একটি অনুরূপ ধারণা তবে বিকল্প প্যাটার্নটির বাস্তবায়নের ফলে খুব কম। মূল কারণ হ'ল। নেট সিস্টেমের মধ্যে ul নুলাবল মান ধরণের ক্ষেত্রে সীমাবদ্ধ।
— ম্যাটডেভি
27
বিকল্পের জন্য +1। হাস্কেলের হতে পারে তার সাথে পরিচিত হওয়ার পরে , নালগুলি অদ্ভুত দেখতে শুরু করেছে ...
— এন্ড্রেস এফ।
5
বিকাশকারী যে কোনও জায়গায় ত্রুটি করতে পারে, তাই নাল পয়েন্টার ব্যতিক্রমের পরিবর্তে আপনি খালি বিকল্প ব্যতিক্রম পাবেন। পূর্বেরটি কীভাবে আগের চেয়ে ভাল?
— গ্রিনল্ডম্যান
7
@ গ্রীনল্ডম্যান "খালি বিকল্প ব্যতিক্রম" এর মতো কোনও জিনিস নেই। নাল নোট হিসাবে সংজ্ঞায়িত করা ডাটাবেস কলামগুলিতে নাল মান সন্নিবেশ করানোর চেষ্টা করুন।
— জোনাস
36
@ গ্রীনল্ডম্যান নালসের সমস্যাটি হ'ল যে কোনও কিছুই শূন্য হতে পারে এবং বিকাশকারী হিসাবে আপনাকে অতিরিক্ত সতর্ক হতে হবে। একটি Stringটাইপ আসলে একটি স্ট্রিং নয়। এটা এক String or Nullপ্রকার যে ভাষাগুলি বিকল্প ধরণের ধারণার সাথে সম্পূর্ণরূপে মেনে চলে তাদের ধরণের সিস্টেমে নাল মানগুলি নিষ্ক্রিয় করে, গ্যারান্টি দেয় যে আপনি যদি String(বা অন্য কোনও কিছু) প্রয়োজন এমন একটি স্বাক্ষর সংজ্ঞায়িত করেন তবে তার অবশ্যই মান থাকতে হবে। Optionটাইপ যে জিনিস এক ধরনের পর্যায়ের প্রতিনিধিত্ব দিতে হয় বা না পারে একটি মান আছে, তাই আপনি জানেন যেখানে আপনি স্পষ্টভাবে ঐ পরিস্থিতিতে হ্যান্ডেল উচিত নয়।
— কেচালাক্স
127

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

আপনি ঠিক বলেছেন যে গ্রেফুল ত্রুটি পরিচালনা করা নাল-চেকিং ifস্টেটমেন্টগুলির সাথে কার্যত অভিন্ন হতে পারে । কিন্তু আপনি যখন নিজেকে বোঝান এমন কিছু যখন সম্ভবত নাল হতে পারে না, তখন কী ঘটে ? Kerboom। এরপরে যা কিছু ঘটুক না কেন, আমি বাজি রাখতে ইচ্ছুক 1) এটি করুণাময় হবে না এবং 2) আপনি এটি পছন্দ করবেন না।

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

— BlairHippo
সূত্র
27
+1 সাধারণত উৎপাদন কোডের ত্রুটি দরকার (সাধারণত ডেটা ত্রুটি) যতটা সম্ভব দ্রুত হিসাবে চিহ্নিত করতে হবে যাতে তারা সংশোধন করা যেতে পারে। ডিবাগ করা সহজতর, তত ভাল।
4
ওপির উদাহরণগুলির মধ্যে যে কোনও একটিতে প্রয়োগ করা হলে এই উত্তরটি সমান। হয় আপনি ত্রুটির শর্তগুলির জন্য পরীক্ষা করেন বা আপনি তা করেন না এবং আপনি হয় সেগুলি করুণভাবে পরিচালনা করেন বা না করেন don't অন্য কথায়, ভাষা থেকে নাল রেফারেন্সগুলি সরিয়ে ফেললে আপনি যে ত্রুটিগুলি অনুভব করবেন সেগুলির শ্রেণি পরিবর্তন করে না, এটি কেবলমাত্র ত্রুটিগুলির প্রকাশটি পরিবর্তন করবে।
— ড্যাশ-টম-ব্যাং
19
অব্যবহৃত বোমার জন্য +1। নাল রেফারেন্স সহ, বলার public Foo doStuff()অর্থ এই নয় যে "স্টাফ করুন এবং ফু রেজাল্ট ফিরিয়ে দিন" এর অর্থ হ'ল "স্টাফ করুন এবং ফু রেজাল্ট ফিরিয়ে দিন, বা নাল ফিরিয়ে দিন, তবে তা হবে কিনা তা আপনার কোনও ধারণা নেই।" ফলাফলটি হ'ল আপনাকে নিশ্চিত করতে সমস্ত পরীক্ষা করতে হবে। অর্থহীন মান নির্দেশ করতে পাশাপাশি নালগুলি মুছে ফেলতে এবং একটি বিশেষ ধরণ বা প্যাটার্ন (যেমন কোনও মান ধরণের) ব্যবহার করতে পারে।
— ম্যাট ওলেনিক
12
@ গ্রাউনল্ডম্যান, আপনার উদাহরণটি দ্বিগুণ কার্যকরভাবে আমাদের দৃষ্টিভঙ্গি প্রদর্শন করতে সক্ষম যে আধ্যাত্মিক মডেল হিসাবে আদিম প্রকারের (নাল বা পূর্ণসংখ্যার) ব্যবহার দুর্বল অনুশীলন। আপনার যদি এমন কোনও ধরণের থাকে যার জন্য নেতিবাচক সংখ্যাগুলি কোনও বৈধ উত্তর নয় তবে অর্থটির সাথে অর্থপূর্ণ মডেলটি বাস্তবায়নের জন্য আপনার নতুন ধরণের তৈরি করা উচিত। এখন সেই অ-নেতিবাচক টাইপের মডেলিংটি হ্যান্ডেল করার সমস্ত কোড তার শ্রেণিতে স্থানীয়করণ করা হয়েছে, সিস্টেমের বাকী অংশ থেকে পৃথক করে দেওয়া হয়েছে এবং এর জন্য নেতিবাচক মান তৈরি করার যে কোনও প্রচেষ্টা অবিলম্বে ধরা পড়তে পারে।
— হুপার্নিকেটেস
9
@ গ্রীনল্ডম্যান, আপনি সেই বিন্দুটি প্রমাণ করেই চালিয়ে গেছেন যে আদিম প্রকারগুলি মডেলিংয়ের পক্ষে অপর্যাপ্ত। প্রথমে এটি নেতিবাচক সংখ্যার চেয়ে বেশি ছিল। এখন এটি বিভাগ অপারেটরের উপরে যখন শূন্যটি বিভাজক হয়। যদি আপনি জানেন যে আপনি শূন্য দ্বারা ভাগ করতে পারবেন না তবে আপনি ভবিষ্যদ্বাণী করতে পারেন যে ফলাফলটি দুর্দান্ত হবে না, এবং এটির জন্য আপনার পরীক্ষা নিশ্চিত করার জন্য দায়বদ্ধ এবং সেই ক্ষেত্রে উপযুক্ত "বৈধ" মান প্রদান করবেন। সফ্টওয়্যার বিকাশকারীরা তাদের কোডটি যে পরামিতিগুলিতে কাজ করে সেগুলি জানার জন্য এবং যথাযথভাবে কোডিংয়ের জন্য দায়বদ্ধ। এগুলিই ইঞ্জিনিয়ারিংকে টিঙ্কারিংয়ের থেকে পৃথক করে।
— হুপার্নিকেটস
50

কোডে নাল রেফারেন্স ব্যবহার করে বেশ কয়েকটি সমস্যা রয়েছে।

প্রথমত, এটি সাধারণত একটি বিশেষ অবস্থা নির্দেশ করতে ব্যবহৃত হয় । বিশেষত বিশেষত বিশেষায়িতকরণ হিসাবে প্রতিটি রাজ্যের জন্য একটি নতুন শ্রেণি বা ধ্রুবক সংজ্ঞায়িত করার পরিবর্তে একটি নাল রেফারেন্স ব্যবহার করে একটি ক্ষয়ক্ষতিপূর্ণ, ব্যাপক আকারের সাধারণ টাইপ / মান ব্যবহার করা হয় ।

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

তৃতীয়, নাল তথ্যসূত্রগুলি পরীক্ষার জন্য অতিরিক্ত কোড পাথগুলি প্রবর্তন করে ।

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

পঞ্চম, ভাষার কোনও রানটাইম ইতিমধ্যে টাইপ চেকগুলি সম্পাদন করে যখন এটি কোনও বস্তুর পদ্ধতি টেবিলে নির্বাচক অনুসন্ধান করে। সুতরাং আপনি যদি বস্তুর প্রকারটি বৈধ / অবৈধ কিনা তা পরীক্ষা করে চালানোর চেষ্টা করে যাচ্ছেন এবং তারপরে রানটাইমটি বৈধ অবজেক্টের পদ্ধতিটি জিজ্ঞাসা করার জন্য পরীক্ষা করে দেখুন।

কেন ব্যবহার করবেন NullObject প্যাটার্ন থেকে রানটাইম এর চেক সদ্ব্যবহার এটা ডাকা আছে NOP যে রাষ্ট্র (নিয়মিত রাজ্যের ইন্টারফেস সঙ্গে মানানসই) যখন আপনার কোডবেস সর্বত্র নাল রেফারেন্স জন্য সব অতিরিক্ত পরীক্ষণ দূর নির্দিষ্ট পদ্ধতি?

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

— Huperniketes
সূত্র
7
... কারন কে আবিষ্কার করেছেন (বা তার পরিবর্তে, পরিবর্তন বা আরম্ভ করার পক্ষে ভাবেননি) আপনার আবশ্যকভাবে দরকারী বস্তুটি পূরণ করছে এমন আবর্জনা ডেটা কোনও নল রেফারেন্স ট্র্যাক করার চেয়ে এত সহজ? আমি এটি কিনতে পারি না, যদিও আমি বেশিরভাগ স্থিতিযুক্ত টাইপ করা জমিতে আটকে আছি।
— ড্যাশ-টম-ব্যাং
নালাগুলির উল্লেখগুলির তুলনায় আবর্জনার ডেটা এত বিরল। বিশেষত পরিচালিত ভাষাগুলিতে।
— ডিন হার্ডিং
5
নাল অবজেক্টের জন্য -1।
— ডেডএমজি
4
পয়েন্টগুলি (4) এবং (5) শক্ত, তবে নুলওবজেক্ট কোনও প্রতিকার নয়। আপনি আরও খারাপ ফাঁদে পড়বেন - যুক্তি (কর্মপ্রবাহ) ত্রুটি। আপনি যখন বর্তমান পরিস্থিতিটি সঠিকভাবে জানেন, নিশ্চিতভাবেই এটি সাহায্য করতে পারে তবে অন্ধভাবে (নাল পরিবর্তে) এটি ব্যবহার করতে আপনার আরও বেশি ব্যয় হবে।
— গ্রীনল্ডম্যান
1
@ gnasher729, যখন ওজেক্টিভ-সি এর রানটাইম জাভা এবং অন্যান্য সিস্টেমের মতো নাল পয়েন্টার ব্যতিক্রম ছুঁড়ে ফেলবে না, কারণ আমি আমার উত্তরে যে কারণগুলি উল্লেখ করেছি তার জন্য নাল রেফারেন্স ব্যবহার করা আরও ভাল নয়। উদাহরণস্বরূপ, [self.navigationController.presentingViewController dismissViewControllerAnimated: YES completion: nil];রানটাইমের কোনও নেভিগেশন নিয়ন্ত্রণকারী যদি এটিকে নো-অপ্সের অনুক্রম হিসাবে গণ্য করে, তবে প্রদর্শনটি প্রদর্শন থেকে সরিয়ে দেওয়া হয়নি, এবং আপনি কী কারণে এটি নির্ধারণের চেষ্টা করে কয়েক ঘন্টা আপনার মাথা স্ক্র্যাচ করে এক্সকোডের সামনে বসে থাকতে পারেন।
— হুপার্নিকেটেস
48

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

Customer? c = Customer.GetByLastName("Goodman");
// note the question mark -- 'c' is either a Customer or null
if (c != null)
{
    // c is not null, therefore its type in this block is
    // now 'Customer' instead of 'Customer?'
    Console.WriteLine(c.FirstName + " " + c.LastName + " is awesome!");
}
else { Console.WriteLine("There was no customer named Goodman.  How lame!"); }

যদি আপনি একটিতে পদ্ধতিগুলি চাওয়ার চেষ্টা করেন তবে আপনার Customer?একটি সংকলন-সময় ত্রুটি পাওয়া উচিত। আরও ভাষা এটি না করার কারণ (আইএমও) হ'ল এটি যে স্কোপের মধ্যে রয়েছে তার উপর নির্ভর করে পরিবর্তনের জন্য পরিবর্তনের প্রকার সরবরাহ করে না If ভাষা যদি এটি পরিচালনা করতে পারে তবে সমস্যাটি পুরোপুরি সমাধান করা যেতে পারে টাইপ সিস্টেম।

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

— নোট করুন - একটি নাম ভাবেন
সূত্র
11
বাহ, খুব সুন্দর। সংকলনের সময়ে আরও অনেক ত্রুটি ধরা ছাড়াও, এটি GetByLastNameরিটার্ন নালাগুলি পাওয়া যায় না কিনা তা খুঁজে বের করার জন্য ডকুমেন্টেশন চেক করা থেকে আমাকে বাঁচায় (ব্যতিক্রম ছুঁড়ে দেওয়ার বিপরীতে) - আমি কেবল দেখতে পাচ্ছি যে এটি ফিরে আসে Customer?কি না Customer।
— টিম গুডম্যান
14
@ জেবিআরওয়িলকিনসন: ধারণাটি দেখানোর জন্য এটি কেবল একটি রান্না করা উদাহরণ, প্রকৃত বাস্তবায়নের উদাহরণ নয়। আমি আসলে এটি একটি সুন্দর ঝরঝরে ধারণা।
— ডিন হার্ডিং
1
আপনি ঠিক বলেছেন যে এটি নাল বস্তুর ধরণ নয়, যদিও।
— ডিন হার্ডিং
13
এই Haskell, একটি কি কল মত দেখায় Maybe- একটি Maybe Customerপারেন হয় Just c(যেখানে cএকটি হল Customer) অথবা Nothing। অন্যান্য ভাষায়, একে বলা হয় Option- এই প্রশ্নের অন্যান্য উত্তরগুলি দেখুন see
— ম্যাট্রিক্সফ্রোগ
2
@ সিমোন বার্কার: আপনি নিশ্চিত হয়ে উঠতে পারেন যে Customer.FirstNameপ্রকারের String(বিপরীতে String?) রয়েছে কিনা । এটাই আসল উপকার - কেবলমাত্র ভেরিয়েবল / বৈশিষ্ট্য যার অর্থহীন কোনও মূল্য নেই তা বাতিল হিসাবে ঘোষণা করা উচিত।
— যোগু
20

দুর্ভাগ্যজনক লক্ষণগুলি কভার করে এমন অনেক দুর্দান্ত উত্তর রয়েছে null, সুতরাং আমি একটি বিকল্প যুক্তি উপস্থাপন করতে চাই: নাল টাইপ সিস্টেমে একটি ত্রুটি।

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

জাভার একটি হাইপোথিকাল ডায়ালেক্ট বিবেচনা করুন বা আপনার পছন্দসই স্ট্যাটিকালি টাইপ করা ভাষা যাই হোক না কেন, "Hello, world!"আপনি যে কোনও ধরণের যে কোনও ভেরিয়েবলকে স্ট্রিং নির্ধারণ করতে পারেন :

Foo foo1 = new Foo();  // Legal
Foo foo2 = "Hello, world!"; // Also legal
Foo foo3 = "Bonjour!"; // Not legal - only "Hello, world!" is allowed

এবং আপনি যেমন ভেরিয়েবল চেক করতে পারেন:

if (foo1 != "Hello, world!") {
    bar(foo1);
} else {
    baz();
}

এ সম্পর্কে অসম্ভব কিছু নেই - কেউ চাইলে এ জাতীয় ভাষা ডিজাইন করতে পারে। বিশেষ মান হওয়া উচিত নয় "Hello, world!"- এটি 42 নম্বর হতে পারে, টিপল (1, 4, 9)বা বলুন null। তবে কেন আপনি এই কাজ করবেন? প্রকারের একটি ভেরিয়েবল Fooকেবলমাত্র ধরে রাখতে হবে Foo- এটি টাইপ সিস্টেমের পুরো পয়েন্ট! nullএখন Fooআর "Hello, world!"কিছু নয়। সবচেয়ে খারাপ, কোনও ধরণের nullমান নয় এবং এটি দিয়ে আপনি কিছুই করতে পারবেন না!

প্রোগ্রামার কখনই নিশ্চিত হতে পারে না যে কোনও চলক আসলে একটি ধারণ করে Fooএবং না প্রোগ্রামটি পারে; অপরিশোধিত আচরণ এড়ানোর জন্য, "Hello, world!"এগুলি হিসাবে ব্যবহার করার আগে ভেরিয়েবলগুলি পরীক্ষা করতে হবে Foo। নোট করুন যে পূর্ববর্তী স্নিপেটে স্ট্রিং চেক করার ফলে foo1 সত্যই সত্য প্রচার হয় না Foo- barনিরাপদ থাকার জন্য সম্ভবত তার নিজস্ব চেকও থাকবে।

প্যাটার্ন মিলের সাথে একটি Maybe/ Optionটাইপ ব্যবহার করে এর সাথে তুলনা করুন :

case maybeFoo of
 |  Just foo => bar(foo)
 |  Nothing => baz()

Just fooঅনুচ্ছেদের অভ্যন্তরে , আপনি এবং প্রোগ্রাম উভয়ই নিশ্চিতভাবে জানেন যে আমাদের Maybe Fooচলকটি সত্যই একটি Fooমূল্য ধারণ করে - সেই তথ্য কল চেইনে প্রচারিত হয় এবং barকোনও চেক করার দরকার নেই। কারণ Maybe Fooএটি একটি স্বতন্ত্র প্রকারের Foo, আপনি এটি ধারণ করতে পারে এমন সম্ভাবনাগুলি পরিচালনা করতে বাধ্য হন Nothing, তাই আপনি কখনই এ দ্বারা অন্ধ হয়ে যেতে পারেন না NullPointerException। আপনি আপনার প্রোগ্রামটি সম্পর্কে খুব সহজেই যুক্তি করতে পারেন এবং সংকলক নাল চেকগুলি বাদ দিতে পারে তা জেনে যে সমস্ত ধরণের ভেরিয়েবলগুলি Fooআসলেই Fooএস থাকে । সবাই জিতল।

— ডোভাল
সূত্র
পার্ল 6-এ নাল-জাতীয় মানগুলির সম্পর্কে কী? এগুলি সর্বদা টাইপ করা বাদে তারা এখনও নাল ull এটি কি এখনও লিখতে পারেন এমন কোনও সমস্যা my Int $variable = Int, যেখানে Intনালীর ধরণের মান আছে Int?
— কনরাড বোরোস্কি
@ এক্সফিক্স আমি পার্লের সাথে পরিচিত নই, তবে যতক্ষণ না আপনার this type only contains integersবিরুদ্ধাঙ্কিত বল প্রয়োগ করার উপায় নেই this type contains integers and this other value, আপনি যখনই কেবল পূর্ণসংখ্যার চান তখন আপনার সমস্যা হবে ।
— দোভাল
1
প্যাটার্ন মিলের জন্য +1। অপশনের ধরণগুলির উপরে উল্লিখিত উত্তরের সংখ্যার সাথে, আপনি কি ভাবেন যে কেউ প্যাটার্ন ম্যাথার্সের মতো একটি সাধারণ ভাষার বৈশিষ্ট্য তাদের নালীর চেয়ে কাজ করার জন্য আরও স্বজ্ঞাত করে তুলতে পারে fact
— জুলাই
1
আমি মনে করি প্যাটার্ন ম্যাচিংয়ের চেয়ে মোনাডিক বাঁধাই আরও কার্যকর ( আমার মনে হয় এটা ধরনের মত C # এর মজাদার এইজন্য ভাষায় এর কিছু (প্রচুর জন্য বিশেষ সিনট্যাক্স নির্বাণ ??, ?.যা Haskell মত ভাষা হিসেবে গ্রন্থাগার ফাংশন বাস্তবায়ন জন্য, ইত্যাদি)। আমি মনে করি এটি আরও ঝরঝরে। null/ Nothingপ্রচার কোনওভাবেই "বিশেষ" নয়, তাই কেন এটির জন্য আমাদের আরও সিনট্যাক্স শিখতে হবে?
— সারা
14

(পুরানো প্রশ্নের জন্য আমার টুপিটি রিংয়ে নিক্ষেপ করা;))

শূন্যের সাথে নির্দিষ্ট সমস্যাটি হ'ল এটি স্থির টাইপিংকে ভঙ্গ করে।

আমার যদি একটি থাকে Thing t, তবে সংকলকটি কল করতে পারে তার গ্যারান্টি দিতে পারে t.doSomething()। ভাল, UNLESS tরানটাইম এ শূন্য। এখন সব বেট বন্ধ আছে। সংকলকটি বলেছিল যে এটি ঠিক আছে তবে আমি পরে খুঁজে পেয়েছি যা tবাস্তবে নেই doSomething()। টাইপ ত্রুটিগুলি ধরার জন্য সংকলকটির উপর নির্ভর করার পরিবর্তে, এগুলি ধরার জন্য আমাকে রানটাইম পর্যন্ত অপেক্ষা করতে হবে। আমি পাশাপাশি পাইথন ব্যবহার করতে পারি!

সুতরাং, এক অর্থে, নাল প্রত্যাশিত ফলাফল সহ স্থিতিশীল টাইপ করা সিস্টেমে গতিশীল টাইপিংয়ের পরিচয় দেয়।

শূন্য বা negativeণাত্মক লগ ইত্যাদির দ্বারা বিভাজনের মধ্যে পার্থক্য হ'ল যখন আমি = 0, তখনও এটি একটি অন্তর্নিহিত। সংকলক এখনও তার ধরণের গ্যারান্টি দিতে পারে। সমস্যাটি হ'ল যুক্তিবিজ্ঞানটি সেই মানটিকে এমনভাবে ভুলভাবে প্রয়োগ করে যা যুক্তি দ্বারা অনুমোদিত নয় ... তবে যদি যুক্তিটি এটি করে, তবে এটি বাগের সংজ্ঞাটি much

(কম্পাইলার করতে যারা সমস্যার কিছু BTW, মত এক্সপ্রেশন ঝিমুনি মতো ধরতে। i = 1 / 0কম্পাইল সময়ে। কিন্তু আপনি কি সত্যিই কম্পাইলার একটি ফাংশন মধ্যে অনুসরণ করে এবং নিশ্চিত করুন যে পরামিতি সব ফাংশনের যুক্তি দিয়ে সামঞ্জস্যপূর্ণ হয় আশা করা যাবে না)

ব্যবহারিক সমস্যাটি হ'ল আপনি প্রচুর অতিরিক্ত কাজ করেন এবং রানটাইমের সময় নিজেকে রক্ষা করতে নাল চেক যোগ করেন তবে আপনি যদি কোনওটি ভুলে যান তবে কী হবে? সংকলক আপনাকে নির্ধারণ থেকে বিরত রাখে:

স্ট্রিং s = নতুন পূর্ণসংখ্যা (1234);

তাহলে কেন এটি এমন কোনও মান (নাল) এর জন্য অ্যাসাইনমেন্টের অনুমতি দেবে যা ডি-রেফারেন্সগুলি ভেঙে দেবে s?

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

— রব ওয়াই
সূত্র
3
সি তে, টাইপের একটি ভেরিয়েবল *intহয় একটি int, বা NULL। তেমনিভাবে সি ++ তে, টাইপের একটি চলক *Widgetহয় একটিকে চিহ্নিত করে Widget, এমন একটি জিনিস যা টাইপ থেকে আসে Widgetবা হয় NULL। জাভা এবং সি # এর মতো ডেরিভেটিভগুলির সাথে সমস্যা হ'ল তারা স্টোরেজ অবস্থানটি Widgetবোঝায় *Widget। সমাধানটি হ'ল ভান করা নয় যে কোনওটি *Widgetধরে রাখতে সক্ষম হবে না NULL, বরং একটি সঠিক Widgetস্টোরেজ-অবস্থানের ধরণ রয়েছে।
— সুপারক্যাট
14

একটি nullপয়েন্টার একটি সরঞ্জাম

শত্রু নয় আপনার ঠিক তাদের সঠিক ব্যবহার করা উচিত।

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

যদি এখনও নিশ্চিত না হন, আপনার দৃশ্যে মাল্টিথ্রেডিংয়ের একটি ভাল ডোজ যুক্ত করুন, তবে আবার চিন্তা করুন।

গল্পটির নৈতিক: বাচ্চাদের জল দিয়ে ফেলে দেবেন না। এবং দুর্ঘটনার জন্য সরঞ্জামগুলিকে দোষ দিবেন না। যে ব্যক্তি দীর্ঘকাল আগে শূন্য নম্বরটি আবিষ্কার করেছিলেন তিনি বেশ চালাক, সেদিন থেকে আপনি "কিছুই না" নাম রাখতে পারেন। nullপয়েন্টার এতদূর থেকে দূরে নয়।

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

  • NullObjectযখন কোনও পদ্ধতি বলা হয় তখন (তত্ত্ব অনুসারে) একটি রেফারেন্স কিছু না করে। সুতরাং, ত্রুটিযুক্তভাবে অচিহ্নহিত রেফারেন্সগুলির কারণে সূক্ষ্ম ত্রুটিগুলি প্রবর্তন করা যেতে পারে, যা এখন নন-নাল (ইয়াহা!) হওয়ার গ্যারান্টিযুক্ত তবে একটি অযাচিত ক্রিয়া সম্পাদন করে: কিছুই নয়। এনপিইর সাহায্যে সমস্যাটি স্পষ্টভাবেই যেখানে রয়েছে to একটি সঙ্গে NullObjectযে একরকম আচরণ করবে (কিন্তু ভুল), আমরা সনাক্ত করা হচ্ছে ত্রুটি ঝুঁকি (খুব) প্রয়াত পরিচয় দিন। এটি কোনও অবৈধ পয়েন্টার সমস্যার মতো দুর্ঘটনাক্রমে নয় এবং এর একই পরিণতি রয়েছে: রেফারেন্সটি এমন কোনও বিষয়কে নির্দেশ করে যা বৈধ ডেটার মতো দেখায়, তবে তা নয়, ডেটা ত্রুটির পরিচয় দেয় এবং এটি খুঁজে বের করা শক্ত হতে পারে। সত্যি কথা বলতে, এই ক্ষেত্রে আমি একটি চোখের পাতা ছাড়াই একটি এনপিই পছন্দ করি যা অবিলম্বে ব্যর্থ হয়, এখন,লজিকাল / ডেটা ত্রুটির কারণে যা হঠাৎ আমাকে পরে রাস্তায় নামায়। ত্রুটিগুলির ব্যয় সম্পর্কে আইবিএম সমীক্ষাটি মনে করুন যেগুলি কোন পর্যায়ে এটি সনাক্ত করা হয়?

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

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

— জেনসজি
সূত্র
কেন nullউপস্থিত থাকার জন্য আপনি একটি যুক্তি উপস্থাপন করতে পারেন ? "এটি কোনও সমস্যা নয়, কেবল কোনও ভুল করবেন না" দিয়ে কোনও ভাষার ত্রুটিযুক্ত হ্যান্ডওয়েভ করা সম্ভব।
— ডোভাল
আপনি কোন মান অবৈধ পয়েন্টার সেট করবেন?
— জেনসজি
ঠিক আছে, আপনি এগুলিকে কোনও মান হিসাবে সেট করবেন না কারণ আপনার এগুলি একেবারেই অনুমতি দেওয়া উচিত নয়। পরিবর্তে, আপনি একটি ভিন্ন ধরণের ভেরিয়েবল ব্যবহার করেন, সম্ভবত এটি বলা হয় Maybe Tযার মধ্যে দুটি হয় Nothingবা Tমান থাকতে পারে । এখানে মূল কথাটি হ'ল আপনাকে এটি ব্যবহারের অনুমতি দেওয়ার আগে Maybeকোনও সত্যই কোনও ধারণাগুলি রয়েছে কিনা তা যাচাই করতে বাধ্য করা হয়েছে T, এবং যদি তা না হয় তবে ক্রিয়াকলাপ সরবরাহ করে। এবং আপনি অবৈধ পয়েন্টারগুলিকে অস্বীকার করেছেন, এখন আপনাকে কখনই এমন কিছু যাচাই করতে হবে না Maybe।
— ডোভাল
1
আপনার সর্বশেষ উদাহরণে জেনসজি, কম্পাইলার কি প্রতিটি কল করার আগে আপনাকে নাল চেক করতে বাধ্য করে t.Something()? অথবা আপনি ইতিমধ্যে চেকটি করেছেন তা জানার কোনও উপায় আছে এবং আপনাকে আবার এটি করতে বাধ্য না করে? tএই পদ্ধতিতে প্রবেশের আগে আপনি যদি চেকটি করেন তবে কী হবে ? অপশন টাইপের সাথে, সংকলকটি জানে যে আপনি চেকটি এখনও করেছেন কিনা এর ধরণটি দেখে t। যদি এটি একটি অপশন হয় তবে আপনি এটি পরীক্ষা করে দেখেননি, যদি এটি যদি আন-র্যাপড মান থাকে তবে আপনার কাছে রয়েছে।
— টিম গুডম্যান
1
যখন কোন মান জিজ্ঞাসা করা হয় তখন আপনি কী বাতিল করবেন?
— জেনসজি
8

নাল রেফারেন্সগুলি একটি ভুল কারণ তারা অ-সংবেদনশীল কোডের অনুমতি দেয়:

foo = null
foo.bar()

বিকল্পগুলি রয়েছে, যদি আপনি টাইপ সিস্টেমটি উত্তোলন করেন:

Maybe<Foo> foo = null
foo.bar() // error{Maybe<Foo> does not have any bar method}

সাধারণত ধারণাটি হ'ল ভেরিয়েবলটি একটি বাক্সে রাখা, এবং কেবলমাত্র আপনি যা করতে পারেন তা এটি আনবক্সিং করা, পছন্দমতো আইফেলের প্রস্তাবিত সংকলক সহায়তা তালিকাভুক্ত করা।

হাস্কেলের স্ক্র্যাচ থেকে এটি রয়েছে ( Maybe), সি ++ তে আপনি লাভবান করতে পারেন boost::optional<T>তবে আপনি এখনও অপরিবর্তিত আচরণ পেতে পারেন ...

— ম্যাথিউ এম।
সূত্র
6
"লিভারেজ" এর জন্য -1!
— মার্ক সি সি
8
তবে অবশ্যই প্রচুর প্রচলিত প্রোগ্রামিং কনস্ট্রাক্টগুলি অযৌক্তিক কোডের জন্য অনুমতি দেয়, না? শূন্য দ্বারা বিভাজন (তর্কযুক্ত) অযৌক্তিক, তবে আমরা এখনও বিভাগকে অনুমতি দিই, এবং আশা করি প্রোগ্রামার মনে রাখে যে বিভাজকটি শূন্য নয় (বা ব্যতিক্রমটি পরিচালনা করবেন) তা পরীক্ষা করে দেখুন।
— টিম গুডম্যান
3
আমি নির্দিষ্ট আপনি "গোড়া থেকে" দ্বারা কি বোঝাতে চেয়েছেন নই, কিন্তু Maybeকোর ভাষা পাতাটা করা হয় না, এর সংজ্ঞা একটা মানসম্মত মঙ্গলাচরণ মধ্যে হতে হবে: data Maybe t = Nothing | Just t।
— ফ্রেডওভারফ্লো 21 ই
4
@ ফ্রেড ওভারফ্লো: যেহেতু উপস্থাপনাটি ডিফল্টরূপে লোড করা হয়, তাই আমি এটিকে "স্ক্র্যাচ থেকে" বিবেচনা করব, যে হাস্কেলের কাছে এই (এবং অন্যান্য) চমত্কার ভাষার সাধারণ নিয়মগুলির সাথে সংজ্ঞায়িত করার অনুমতি দেওয়ার জন্য একটি বিস্ময়কর পর্যাপ্ত ব্যবস্থা রয়েছে যা কেবল একটি বোনাস :)
— ম্যাথিউ এম।
2
@ টিমগুডম্যান যদিও শূন্য দ্বারা বিভাজন সমস্ত সংখ্যার মান ধরণের জন্য সেরা উদাহরণ হতে পারে না (আইইইই 754 শূন্য দ্বারা বিভাগের জন্য ফলাফলকে সংজ্ঞায়িত করে), যেখানে ক্ষেত্রে এটির ব্যতিক্রম হবে, পরিবর্তিত ধরণের Tমানগুলি অন্য ধরণের মানের দ্বারা বিভক্ত হওয়ার পরিবর্তে T, আপনি ধরণের Tমান দ্বারা ভাগ করে টাইপের মানগুলিতে অপারেশন সীমাবদ্ধ করবেন NonZero<T>।
— kbolino
8

এবং বিকল্প কি?

Ptionচ্ছিক প্রকার এবং প্যাটার্ন মিল। যেহেতু আমি সি # জানি না, তাই এখানে স্কালার নামক একটি কাল্পনিক ভাষায় কোডের একটি অংশ রয়েছে: # :-)

Customer.GetByLastName("Goodman")    // returns Option[Customer]
match
{
    case Some(customer) =>
    Console.WriteLine(customer.FirstName + " " + customer.LastName + " is awesome!");

    case None =>
    Console.WriteLine("There was no customer named Goodman.  How lame!");
}
— ফ্রেডওভারফ্লো
সূত্র
6

নালগুলির সাথে সমস্যাটি হ'ল যে ভাষাগুলি এগুলিকে আপনার বিরুদ্ধে রক্ষণাত্মকভাবে প্রোগ্রামিং করতে বাধ্য করে। এটি নিশ্চিত করতে অনেক বেশি প্রচেষ্টা (ডিফেনসিভ if-block ব্যবহারের চেষ্টা করার চেয়ে অনেক বেশি) লাগে

  1. আপনি যে বস্তুগুলি তাদের কাছ থেকে নালার প্রত্যাশা করবেন না তা সত্যই কখনই নাল হয় না এবং
  2. আপনার প্রতিরক্ষামূলক ব্যবস্থাগুলি কার্যকরভাবে সমস্ত সম্ভাব্য এনপিইগুলির সাথে ডিল করে।

সুতরাং, প্রকৃতপক্ষে, নালগুলি শেষ হওয়া ব্যয়বহুল জিনিস being

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

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

— উইনস্টন ইওয়ার্ট
সূত্র
4

সমস্যাটি এতটা নাল নয়, আপনি অনেকগুলি আধুনিক ভাষায় নন-নাল রেফারেন্স টাইপ নির্দিষ্ট করতে পারবেন না।

উদাহরণস্বরূপ, আপনার কোডটি দেখতে পারে

public void MakeCake(Egg egg, Flour flour, Milk milk)
{
    if (egg == null) { throw ... }
    if (flour == null) { throw ... }
    if (milk == null) { throw ... }

    egg.Crack();
    MixingBowl.Mix(egg, flour, milk);
    // etc
}

// inside Mixing bowl class
public void Mix(Egg egg, Flour flour, Milk milk)
{
    if (egg == null) { throw ... }
    if (flour == null) { throw ... }
    if (milk == null) { throw ... }

    //... etc
}

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

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

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

http://twistedoakstudios.com/blog/Post330_non-nullable-types-vs-c-fixing-the-billion-dollar-mistake

এটি সি # -> https://visualstudio.uservoice.com/forums/121579-visual-studio/category/30931-languages-c এর জন্য # 2 সবচেয়ে বেশি ভোট দেওয়া বৈশিষ্ট্য হিসাবেও তালিকাভুক্ত রয়েছে

— মাইকেল পার্কার
সূত্র
আমি মনে করি অপশন <T> সম্পর্কে আর একটি গুরুত্বপূর্ণ বিষয় হ'ল এটি একটি মোনাড (এবং সেইজন্য এন্ডোফান্টরও), সুতরাং আপনি Noneপ্রতিটি পদক্ষেপের জন্য স্পষ্টভাবে পরীক্ষা না করে alচ্ছিক ধরণের মান স্রোতে জটিল গণনা রচনা করতে পারেন ।
— সারা
3

নাল মন্দ। তবে নালীর অভাব আরও বড় মন্দ হতে পারে।

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

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

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

100 এর মধ্যে কমপক্ষে 99 বার নাল ব্যবহার করা পছন্দ করব। যদিও আমি সেগুলির স্বর সংস্করণে খেয়াল করে আনন্দের জন্য ঝাঁপিয়ে পড়ব।

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

সর্বাধিক সাধারণ ক্ষেত্রে অনুকূলিতকরণ।

সর্বদা শূন্যতার জন্য পরীক্ষা করা ক্লান্তিকর - আপনি কেবল গ্রাহক অবজেক্টকে ধরে রাখতে এবং এটিতে কাজ করতে সক্ষম হতে চান।

সাধারণ ক্ষেত্রে, এটি ঠিক কাজ করা উচিত - আপনি চেহারাটি দেখুন, অবজেক্টটি পাবেন এবং এটি ব্যবহার করুন।

ইন ব্যতিক্রমী ক্ষেত্রে , যেখানে আপনি (এলোমেলোভাবে) নামে একটি গ্রাহক আপ খুঁজছেন, বুদ্ধিমান না কিনা রেকর্ড / বস্তু বিদ্যমান, আপনি কিছু ইঙ্গিত যে এই ব্যর্থ প্রয়োজন চাই। এই পরিস্থিতিতে, উত্তরটি হ'ল একটি রেকর্ডনটফাউন্ড ব্যতিক্রম ছোঁড়া (বা নীচে এসকিউএল সরবরাহকারী আপনার জন্য এটি করতে দিন)।

আপনি যদি এমন পরিস্থিতিতে থাকেন যে আপনি জানেন না যে আপনি যে ডেটা (প্যারামিটার) আসছেন তাতে বিশ্বাস করতে পারবেন কিনা, সম্ভবত এটি কোনও ব্যবহারকারী দ্বারা প্রবেশ করানো হয়েছে, তবে আপনি 'ট্রাইগেটকাস্টমার (নাম, গ্রাহক আউট)' সরবরাহ করতে পারেন প্যাটার্ন। Int.Parse এবং int.TryParse এর সাথে ক্রস-রেফারেন্স।

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

ব্যতিক্রম প্রমাণিত হয় না!

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

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

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

ব্যতিক্রম এড়াতে আপনার কোড বুলেটপ্রুফ তৈরি করা খারাপ ধারণা, ব্যতিক্রম স্থির করে আপনাকে কোড বুলেটপ্রুফ তৈরি করা, ভাল আমি এই পথটি বেছে নেব।

— ইলিয়া গাজমান
সূত্র
1
আমি কয়েক বছর আগে প্রশ্নটি পোস্ট করার চেয়ে এখন অপশনের ধরণ সম্পর্কে আরও কিছুটা জানি, যেহেতু আমি এখন এগুলি স্কালায় নিয়মিত ব্যবহার করি। অপশনটির বিন্দুটি হ'ল এটি Noneএমন কোনও সংকেত প্রদান করে যা একটি সংকলন-সময় ত্রুটির বিকল্প নয়, এবং একইভাবে Optionএটির কোনও মান ব্যবহার করে যেমন এটি প্রথম পরীক্ষা না করেই একটি সংকলন-সময় ত্রুটি। সংকলন ত্রুটিগুলি অবশ্যই রান-টাইম ব্যতিক্রমগুলির চেয়ে সুন্দর।
— টিম গুডম্যান
উদাহরণস্বরূপ: আপনি বলতে পারবেন না s: String = None, আপনাকে বলতে হবে s: Option[String] = None। এবং যদি sকোনও বিকল্প হয় s.lengthতবে আপনি এটি বলতে পারবেন না তবে আপনি এটি পরীক্ষা করতে পারেন যে এটির একটি মান রয়েছে এবং একই সাথে প্যাটার্ন s match { case Some(str) => str.length; case None => throw RuntimeException("Where's my value?") }
— টিম গুডম্যান
দুর্ভাগ্যক্রমে স্কালায় আপনি এখনও বলতে পারেনs: String = null , তবে এটি জাভা সহ আন্তঃযোগিতা মূল্য। আমরা সাধারণত আমাদের স্কালা কোডে এই ধরণের জিনিসটিকে অস্বীকার করি।
— টিম গুডম্যান
2
তবে আমি এই সাধারণ মন্তব্যে একমত যে ব্যতিক্রমগুলি (সঠিকভাবে ব্যবহৃত) কোনও খারাপ জিনিস নয়, এবং গিলে ফেলে একটি ব্যতিক্রমকে "ফিক্সিং" করা সাধারণত একটি ভয়ানক ধারণা। তবে অপশন টাইপের সাথে লক্ষ্যটি ব্যতিক্রমগুলি সংকলন-সময় ত্রুটিতে রূপান্তর করা, যা আরও ভাল জিনিস।
— টিম গুডম্যান
@ টিম গুডম্যান এটি কেবল কৌশল হিসাবে কাজ করে না এটি জাভা এবং অ্যাকশনস্ক্রিপ্ট 3 এর মতো অন্যান্য ভাষায়ও ব্যবহার করা যেতে পারে? এছাড়াও আপনি পুরো উদাহরণ সহ আপনার উত্তরটি সম্পাদনা করতে পারলে ভাল লাগবে।
— ইলিয়া গাজমান
0

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

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

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

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

val customer = customerDb getByLastName "Goodman"
val awesomeMessage =
  customer map (c => s"${c.firstName} ${c.lastName} is awesome!")
val notFoundMessage = "There was no customer named Goodman.  How lame!"
println(awesomeMessage getOrElse notFoundMessage)

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

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

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

NULL এর কেন্দ্রীয় সমস্যাটি হ'ল এটি সিস্টেমকে অবিশ্বাস্য করে তোলে। ১৯৮০ সালে টনি হোয়ার তার ট্যুরিং অ্যাওয়ার্ডকে উত্সর্গীকৃত কাগজে লিখেছিলেন:

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

এর পরে এডিএ ভাষা অনেক বদলেছে, তবে জাভা, সি # এবং আরও অনেক জনপ্রিয় ভাষায় এ জাতীয় সমস্যা এখনও বিদ্যমান।

ক্লায়েন্ট এবং সরবরাহকারীদের মধ্যে চুক্তি তৈরি করা বিকাশকারীর কর্তব্য। উদাহরণস্বরূপ, সি # তে, জাভা হিসাবে, আপনি পঠনযোগ্য (দুটি বিকল্প) তৈরি করে রেফারেন্সের Genericsপ্রভাব হ্রাস করতে ব্যবহার করতে পারেন :NullNullableClass<T>

class NullableClass<T>
{
     public HasValue {get;}
     public T Value {get;}
}

এবং তারপরে এটি ব্যবহার করুন

NullableClass<Customer> customer = dbRepository.GetCustomer('Mr. Smith');
if(customer.HasValue){
  // one logic with customer.Value
}else{
  // another logic
}

অথবা সি # এক্সটেনশন পদ্ধতিগুলির সাথে দুটি বিকল্প শৈলী ব্যবহার করুন:

customer.Do(
      // code with normal behaviour
      ,
      // what to do in case of null
)

পার্থক্যটি তাৎপর্যপূর্ণ। কোনও পদ্ধতির ক্লায়েন্ট হিসাবে আপনি কী জানেন তা জানেন। একটি দলের নিয়ম থাকতে পারে:

যদি কোনও শ্রেণি NullableClass টাইপ না করে থাকে তবে এর উদাহরণটি অবশ্যই নাল নয় ।

দলটি সংকলনের সময় ডিজাইন দ্বারা চুক্তি এবং স্থিতিশীল চেকিং ব্যবহার করে এই ধারণাটিকে শক্তিশালী করতে পারে , যেমন পূর্বশর্ত সহ:

function SaveCustomer([NotNullAttribute]Customer customer){
     // there is no need to check whether customer is null 
     // it is a client problem, not this supplier
}

বা একটি স্ট্রিং জন্য 

function GetCustomer([NotNullAndNotEmptyAttribute]String customerName){
     // there is no need to check whether customerName is null or empty 
     // it is a client problem, not this supplier
}

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

— আর্ট্রু
সূত্র
0

না।

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

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

— বেন লেগিয়েরো
সূত্র
-1

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

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

— শীতল শাহ
সূত্র
-1

এর বিরুদ্ধে আমার একটি সাধারণ আপত্তি রয়েছে null:

অস্পষ্টতার পরিচয় দিয়ে এটি আপনার কোডটির শব্দার্থতাকে সম্পূর্ণরূপে ভেঙে দেয় ।

প্রায়শই আপনি ফলাফলটি নির্দিষ্ট ধরণের হওয়ার আশা করেন। এটি শব্দার্থগত শব্দ। বলুন, আপনি কোনও নির্দিষ্ট ব্যবহারকারীর জন্য ডাটাবেসটি জিজ্ঞাসা করেছিলেন id, আপনি প্রত্যাশা করেছেন যে রেজাল্টটি নির্দিষ্ট ধরণের (= user) হবে। কিন্তু, যদি এই আইডির কোনও ব্যবহারকারী না থাকে? একটি (খারাপ) সমাধান হ'ল: একটি nullমান যুক্ত করা। সুতরাং ফলাফল অবিশ্বাস্য : হয় এটি হয় userবা এটি হয় null। তবে nullপ্রত্যাশিত ধরণ নয়। এবং এখানেই কোডের গন্ধ শুরু হয়।

এড়ানোতে null, আপনি আপনার কোড শব্দার্থবিজ্ঞানযুক্ত পরিষ্কার করুন।

আছে উপায় সবসময় চারপাশে আছে null: সংগ্রহের refactoring, Null-objects, optionalsইত্যাদি

— টমাস জাঙ্ক
সূত্র
-2

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

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

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

— supercat
সূত্র
-2

হ্যাঁ, বস্তু-ভিত্তিক বিশ্বে NULL একটি ভয়ানক নকশা । সংক্ষেপে, নুল ব্যবহারের দিকে নিয়ে যায়:

  • অ্যাডহক ত্রুটি পরিচালনা (ব্যতিক্রম পরিবর্তে)
  • অস্পষ্ট শব্দার্থক
  • দ্রুত ব্যর্থতার পরিবর্তে ধীর
  • কম্পিউটার চিন্তা বনাম বস্তু চিন্তাভাবনা
  • পরিবর্তনীয় এবং অসম্পূর্ণ বস্তু

বিস্তারিত ব্যাখ্যার জন্য এই ব্লগ পোস্টটি দেখুন: http://www.yegor256.com/2014/05/13/why-null-is-bad.html

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