নাল খারাপ নকশা ফিরে কি? [বন্ধ]

Question

আমি কিছু ভয়েস শুনেছি যে পদ্ধতিগুলি থেকে ফেরত নাল মান পরীক্ষা করা খারাপ নকশা is আমি এর কিছু কারণ শুনতে চাই।

সুডোকোড:

variable x = object.method()
if (x is null) do something

Comments

বিস্তৃত: খারাপ লোক বলে এই লোকেরা কোথায়? লিঙ্ক?

— jcollum

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

— ব্ল্যাকটাইগারএক্স

ফিরিয়ে দেওয়ার কোনও ডেটা নেই বলেই ব্যতিক্রম উত্থাপন অবিশ্বাস্যরকম বিরক্তিকর। সাধারণ প্রোগ্রাম প্রবাহ ব্যতিক্রম ছোঁড়া উচিত নয়।

— থোররিন

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

— থোররিন

@ থোররিন: "সাধারণ" প্রোগ্রাম প্রবাহটি বেশ প্রসারিত ধারণা: আসলে কোনও যুক্তির দৃ really় ভিত্তি নয়।

— টমিসলভ নাকিক-আলফায়ারভিক

Answer 1

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

উদাহরণস্বরূপ, যদি আমি জাভাতে এমন কোনও পদ্ধতি সংজ্ঞায়িত করতে পারি যা কোনও সংগ্রহ ফিরিয়ে দেয় তবে আমি সাধারণত Collections.emptyList()ক্লায়েন্ট কোডটি ক্লিনার বলে নাল পরিবর্তে খালি সংগ্রহ (অর্থাত্ ) ফেরত দিতে পছন্দ করব; যেমন

Collection<? extends Item> c = getItems(); // Will never return null.

for (Item item : c) { // Will not enter the loop if c is empty.
  // Process item.
}

... যা এর চেয়ে পরিষ্কার:

Collection<? extends Item> c = getItems(); // Could potentially return null.

// Two possible code paths now so harder to test.
if (c != null) {
  for (Item item : c) {
    // Process item.
  }
}

Comments

হ্যাঁ, নাল ফিরে আসার চেয়ে আরও ভাল উপায় এবং ক্লায়েন্ট কেসটি মোকাবেলা করার জন্য মনে রাখে।

— djna

আমি আনন্দের সাথে সম্মত হই যে শূন্য পাত্রে (বা স্ট্রিং) বিকল্প হিসাবে ব্যবহৃত হলে নাল ফেরানো পাগল। যদিও এটি সাধারণ ঘটনা নয়।

— এমসাল্টাররা

আমার জন্য নাল অবজেক্ট প্যাটার্নের জন্যও +1। এছাড়াও যখন আমি আসলে নাল ফিরে আসতে চাই, আমি এটিকে স্পষ্ট করার জন্য getCustomerOrNull () এর মতো পদ্ধতির নামকরণ করছি। আমি মনে করি কোনও পাঠক বাস্তবায়নের দিকে নজর দিতে না চাইলে একটি পদ্ধতির নামকরণ করা হয়েছে।

— মাইক ভ্যালেন্টি

'// এখন দুটি সম্ভাব্য কোড পাথ' মন্তব্যটি সঠিক নয়; আপনার উভয় উপায়ে দুটি কোড পাথ রয়েছে। তবে আপনার প্রথম উদাহরণে নাল সংগ্রহ সামগ্রীর সাথে, 'নাল' কোডের পথটি ছোট is আপনার কাছে এখনও দুটি পথ রয়েছে এবং আপনার এখনও দুটি পথ পরীক্ষা করতে হবে।

— ফ্রেরিচ রাবাবে

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

— Andrzej ডয়েল

Answer 2

এখানে কারণ।

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

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

Comments

এটি এই উত্তরে উল্লিখিত নাল অবজেক্ট প্যাটার্নটি: স্ট্যাকওভারফ্লো

— স্কট ডরম্যান

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

— বিটিএ

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

— ম্যাক্স চের্নিয়াক

দুর্ভাগ্যক্রমে, কলিং কোড সর্বদা খালি সংগ্রহের ক্ষেত্রে বিবেচনা করে না (অনেকটা পছন্দ মতো এটি নাল কেস বিবেচনা করে না)। সমস্যা হতে পারে বা নাও হতে পারে।

— শ্রীধর সারনোবাত

Answer 3

নাল ফেরার ভাল ব্যবহার:

• যদি নালটি একটি কার্যকর কার্যকরী ফলাফল হয়, উদাহরণস্বরূপ: FindFirstObjectThatNeedsProcessing () পাওয়া না গেলে নাল ফিরে আসতে পারে এবং কলকারী সেই অনুসারে চেক করা উচিত।

খারাপ ব্যবহার: ব্যতিক্রমী পরিস্থিতি প্রতিস্থাপন বা আড়াল করার চেষ্টা করা যেমন:

• ধরা (...) এবং নাল ফিরে
• এপিআই নির্ভরতা সূচনা ব্যর্থ হয়েছে
• ডিস্কের জায়গার বাইরে
• অবৈধ ইনপুট পরামিতি (প্রোগ্রামিং ত্রুটি, ইনপুটগুলি কলার দ্বারা স্যানিটাইজ করতে হবে)
• ইত্যাদি

এই ক্ষেত্রে ব্যতিক্রম ছুঁড়ে ফেলা অধিক পর্যাপ্ত:

• একটি নাল রিটার্ন মান কোনও অর্থবহ ত্রুটির তথ্য সরবরাহ করে না
• তাত্ক্ষণিক কলার সম্ভবত ত্রুটির শর্তটি পরিচালনা করতে পারে না
• কলার নাল ফলাফলের জন্য যাচাই করে নেওয়ার কোনও গ্যারান্টি নেই

তবে ব্যতিক্রমগুলি সাধারণ প্রোগ্রাম অপারেশন শর্তাদি যেমন পরিচালনা করতে ব্যবহার করা উচিত নয়:

• অবৈধ ব্যবহারকারীর নাম / পাসওয়ার্ড (বা কোনও ব্যবহারকারীর দ্বারা সরবরাহ করা ইনপুট)
• ভাঙ্গা লুপগুলি বা অ-স্থানীয় গোটো হিসাবে

Comments

যদিও "অবৈধ ব্যবহারকারীর নাম" ব্যাতিক্রমের কোনও ভাল কারণ বলে মনে হচ্ছে।

— থিলো

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

— জিরো কনসেপ্ট

দেখুন: stackoverflow.com/questions/77127/when-to-throw-an-exception

— ZeroConcept

আমি বলতে চাই এটি নির্ভর করে: ঠিক আছে boolean login(String,String)বলে মনে হয় এবং ঠিক তাই হয়AuthenticationContext createAuthContext(String,String) throws AuthenticationException

— sfussnegger

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

— স্কট এম গার্ডনার

Answer 4

হ্যাঁ, এনইউএলএলকে ফিরিয়ে দেওয়া হ'ল এক ভয়ঙ্কর নকশা object সংক্ষেপে, নুল ব্যবহারের দিকে নিয়ে যায়:

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

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

Comments

আমি দৃ strongly়ভাবে একমত। আমি নাল অবজেক্ট প্যাটার্নটিও পছন্দ করি না যা একটি 'হোয়াইটওয়াশ' বিলম্ব কৌশল বলে মনে হয়। হয় আপনার পদ্ধতিটি সর্বদা সফল হওয়ার জন্য মনে করা হয় বা এটি সফল নাও হতে পারে। যদি এটি সর্বদা সফল হয়, তবে নিক্ষেপ করুন যদি সফল নাও হতে পারে, তবে পদ্ধতি নকশা তাই ভোক্তা জানে, যেমন bool TryGetBlah(out blah)বা FirstOrNull()বা MatchOrFallback(T fallbackValue)।

— লুক পুপলেট

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

— শ্রীধর সারনোবাত

Answer 5

কে বলেছে এটি খারাপ নকশা?

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

Comments

+1 টি। যে সমস্যাটি ঘটনাস্থলে প্রশমিত হতে পারে তার জন্য ব্যতিক্রম ছুঁড়ে ফেলেছে তা আমাকে দুঃখিত করে।

— জেকেস

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

— djna

@ ডিজেনা: আমার ধারণা এটি অত্যন্ত দুঃখজনক তবে আমি দেখতে পেয়েছি যে একই ধরণের কোডারগুলি নালদের জন্য যাচাই করতে "ভুলে" যায় তারা হ'ল যারা চেক করা ব্যতিক্রমগুলির সাথে ঘন ঘন ঘন তাদের গ্রাস করে end

— রেন্ডি

নাল চেকের অনুপস্থিতির চেয়ে খালি ক্যাচ ব্লকের উপস্থিতি চিহ্নিত করা সহজ।

— প্রেস্টন

@ প্রেস্টন: আমি দৃ strongly়ভাবে একমত নই। নাল চেকের অনুপস্থিতি যখন আপনি ক্র্যাশ হয়ে যাবেন তখনই আপনি তাৎক্ষণিকভাবে তা দেখতে পাবেন। গিলে নেওয়া ব্যতিক্রম বছরের পর বছর ধরে রহস্যময় এবং সূক্ষ্ম ত্রুটির প্রস্তাব দিতে পারে ...

— বেসকা

Answer 6

আপনি এতক্ষণ যা বলেছেন তার ভিত্তিতে, আমি মনে করি পর্যাপ্ত তথ্য নেই।

একটি ক্রিয়েট উইজেট () পদ্ধতি থেকে নাল ফেলা খারাপ মনে হয়।

একটি FindFooInBar () পদ্ধতি থেকে নালায় ফেরা ভাল মনে হচ্ছে।

Comments

আমার কনভেনশন এর অনুরূপ: একক আইটেম ক্যোয়ারী - Create... নতুন উদাহরণ দেয়, বা ছোঁড়ে ; Get...প্রত্যাশিত বিদ্যমান উদাহরণটি ফেরত দেয় , বা ছোঁড়ে ; GetOrCreate...একটি বিদ্যমান উদাহরণ, বা নতুন উদাহরণ উপস্থিত না থাকলে, বা ছুঁড়ে ফেলে দেয় ; Find...একটি বিদ্যমান উদাহরণ প্রদান করে, যদি এটি বিদ্যমান থাকে, বাnull । সংগ্রহের প্রশ্নের জন্য - Get... সর্বদা একটি সংগ্রহ ফিরিয়ে দেয়, যা কোনও মিল খুঁজে পাওয়া যায় না যদি খালি থাকে empty

— জোহান জেরেল

ইয়েজিওর 256 এবং হাকুইনিনের উত্তরে দেওয়া কারণগুলির জন্য NUL এর খারাপ, একটি বৈধ কিন্তু খালি বস্তু ফেরানো তাত্পর্য যুক্তিকে সরল করে

— রব 11311

Answer 7

এর উদ্ভাবক বলেছেন এটি এক বিলিয়ন ডলারের ভুল!

Answer 8

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

Comments

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

— ম্যাটড্যাভি

সমস্যাটি কি আপনি জানেন না এটি একটি "অনুপস্থিত মান" nullবা "আরম্ভ নয়"null

— সার্ভ এড

Answer 9

আপনি যদি সমস্ত উত্তর পড়েন তবে এটি পরিষ্কার হয়ে যায় যে এই প্রশ্নের উত্তরটি ধরণের পদ্ধতির উপর নির্ভর করে।

প্রথমত, যখন ব্যতিক্রমী কিছু ঘটে (আইওপ্রব্লেম ইত্যাদি), যৌক্তিকভাবে ব্যতিক্রম ছুঁড়ে দেওয়া হয়। যখন ঠিক কিছু ব্যতিক্রমী হয় তখন সম্ভবত অন্য কোনও বিষয়ের জন্য ..

যখনই কোনও পদ্ধতির প্রত্যাশা করা হয় তখন সম্ভবত দুটি ফলাফল নেই:

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

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

আমি এখনও নামটির সাথে পুরোপুরি ঠিক নেই, তবে এর থেকে ভাল আর কিছু করতে পারিনি। সুতরাং আমি আপাতত যে সাথে চালাচ্ছি।

Answer 10

আমার এই অঞ্চলে একটি সম্মেলন হয়েছে যা আমাকে ভালভাবে উপভোগ করেছে

একক আইটেম প্রশ্নের জন্য:

• Create...একটি নতুন উদাহরণ দেয়, বা ছোঁড়া
• Get...প্রত্যাশিত বিদ্যমান উদাহরণটি দেয় বা নিক্ষেপ করে
• GetOrCreate...কোনও বিদ্যমান উদাহরণ বা নতুন উদাহরণ উপস্থিত না থাকলে, বা নিক্ষেপ করে না returns
• Find...একটি বিদ্যমান উদাহরণ প্রদান করে, যদি এটি বিদ্যমান থাকে, বাnull

সংগ্রহের প্রশ্নের জন্য:

• Get... সর্বদা একটি সংগ্রহ ফিরিয়ে দেয়, যা [1] আইটেমের কোনও মিল না পাওয়া গেলে খালি

[1] ফাংশনের নাম বা পরামিতি হিসাবে দেওয়া কিছু মানদণ্ড, সুস্পষ্ট বা অন্তর্নিহিত given

Comments

গেটওন এবং ফাইন্ডঅন খুঁজে পাওয়া না গেলে কেন আলাদা হয়?

— ভ্লাদিমির ভুকানাক

আমি পার্থক্য বর্ণনা। আমি Getযখন এটি সেখানে থাকার প্রত্যাশা করব তখন আমি এটি ব্যবহার করি , যাতে এটি যদি না থাকে তবে এটি একটি ত্রুটি এবং আমি নিক্ষেপ করি - আমাকে কখনই ফেরতের মান পরীক্ষা করার দরকার নেই। আমি এটি ব্যবহার Findকরি কিনা তা যদি আমি সত্যিই না জানি বা ব্যবহার করি - তবে আমার ফেরতের মানটি পরীক্ষা করতে হবে।

— জোহান জেরেল

Answer 11

ব্যতিক্রম অন্যান্য পরিস্থিতিতে ব্যতিক্রম al

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

Comments

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

— প্রেস্টন

Answer 12

এটি কোনওভাবেই অর্থপূর্ণ হলে নাল ফিরে ফেলা ভাল:

public String getEmployeeName(int id){ ..}

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

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

public Integer getId(...){
   try{ ... ; return id; }
   catch(Exception e){ return null;}
}

Comments

হা. যদি আপনার একটি ত্রুটির শর্ত থাকে তবে একটি ব্যতিক্রম ছুঁড়ে দিন।

— ডেভিড থর্নলি

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

— থোররিন

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

— স্টিভ বি

একটি হ্যাশ টেবিল যে কীটির অস্তিত্ব নেই তার জন্য নাল ফেরানো খারাপ। স্বয়ংক্রিয়ভাবে এটির অর্থ হ'ল আপনি অসামঞ্জস্য কোড ছাড়াই মান হিসাবে নাল সঞ্চয় করতে পারবেন না।

— আরএইচসিগার

Answer 13

এটি অগত্যা কোনও খারাপ নকশা নয় - অনেকগুলি ডিজাইনের সিদ্ধান্তের সাথে এটি নির্ভর করে।

যদি পদ্ধতির ফলাফল এমন কিছু হয় যা সাধারণ ব্যবহারে ভাল ফলাফল না করে তবে নাল ফেরানো ভাল:

object x = GetObjectFromCache();   // return null if it's not in the cache

যদি সত্যিই সর্বদা একটি নন-ফলাফল হওয়া উচিত, তবে একটি ব্যতিক্রম ছুঁড়ে ফেলা ভাল:

try {
   Controller c = GetController();    // the controller object is central to 
                                      //   the application. If we don't get one, 
                                      //   we're fubar

   // it's likely that it's OK to not have the try/catch since you won't 
   // be able to really handle the problem here
}
catch /* ... */ {
}

Comments

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

— djna

বা বার্তা স্ট্রিংয়ে ডায়াগোনস্টিক তথ্য সহ একটি রানটাইম এক্সসেপশনে ব্যতিক্রমটি মোড়ানো। তথ্য একসাথে রাখুন।

— থরবজর্ন রাভন অ্যান্ডারসন

এখন (2018 এ) আমি আর সম্মতি জানাতে পারি না এবং এরকম ক্ষেত্রে আমাদের ফিরে আসার পক্ষে করা উচিতOptional<>

— পাইোটার মুলার

Answer 14

নির্দিষ্ট পরিস্থিতিতে, আপনি ব্যর্থতা হওয়ার সাথে সাথেই এটি লক্ষ্য করতে চান।

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

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

Answer 15

নাল ফিরতে আপনি কোন বিকল্পগুলি দেখছেন?

আমি দুটি কেস দেখতে পাচ্ছি:

• FindAnItem (আইডি) আইটেমটি পাওয়া না গেলে এটি করা উচিত

এক্ষেত্রে আমরা পারলাম: নাল ফিরুন বা একটি (পরীক্ষিত) ব্যতিক্রম নিক্ষেপ করুন (বা সম্ভবত কোনও আইটেম তৈরি করুন এবং এটি ফেরত দিন)

• listItemsMatching (মানদণ্ড) কিছু না পাওয়া গেলে এই রিটার্নটি কী করা উচিত?

এই ক্ষেত্রে আমরা নাল ফিরিয়ে দিতে, একটি খালি তালিকা ফিরতে বা একটি ব্যতিক্রম নিক্ষেপ করতে পারি।

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

x = find();
x.getField();  // bang null pointer exception

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

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

Comments

প্রোগ্রামটির স্বাভাবিক প্রবাহ চলাকালীন সম্ভবত যে অবস্থাটি হওয়ার সম্ভাবনা রয়েছে তা নির্দেশ করতে ব্যতিক্রম ছুঁড়ে ফেলার ফলে বাছাইয়ের চেষ্টা করুন {x = Find ()} ক্যাচ (রেকর্ডনটফাউন্ড ই) {// ডু স্টাফ of

— কোয়ান্ট_দেব

খালি তালিকা ফিরিয়ে দেওয়া একটি ভাল সমাধান তবে কেবল যখন পদ্ধতিটি প্রসঙ্গে থাকে যা তালিকাগুলি ফিরে আসতে পারে। "ফাইন্ডবাইআইডি" পরিস্থিতিগুলির জন্য আপনাকে শূন্য হওয়া দরকার। আমি রেকর্ডনটফাউন্ড ব্যতিক্রম পছন্দ করি না।

— থিলো

সুতরাং এটি আমাদের মতামতের ভিন্নতার ক্রুक्स। আমার দৃষ্টিতে x = find () এর মধ্যে সৌন্দর্যের তেমন পার্থক্য নেই; যদি (x = নাল) {work} অন্যথায় stuff স্টাফ করুন} এবং ধরার চেষ্টা করুন। এবং, প্রয়োজনে আমি কোডের নির্ভুলতার জন্য সৌন্দর্যের ত্যাগ করতে প্রস্তুত। আমার জীবনে প্রায়শই আমার কোডের মুখোমুখি হয় যেখানে রিটার্ন মানগুলি পরীক্ষা করা হয় নি।

— djna

Answer 16

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

Answer 17

পূর্ববর্তী কলটি শূন্য ছিল কিনা তা নির্ধারণ করার জন্য তাদের অন্য পদ্ধতিতে কল করুন। ;-) আরে, জেডিবিসির পক্ষে এটি যথেষ্ট ভাল ছিল

Answer 18

এই থ্রেডের পিছনের বেস ধারণাটি ডিফেন্সিভভাবে প্রোগ্রাম করা। যে, অপ্রত্যাশিত বিরুদ্ধে কোড। বিভিন্ন জবাবের একটি অ্যারে রয়েছে:

অ্যাডামস্কি নাল অবজেক্ট প্যাটার্নটি দেখার পরামর্শ দিয়েছিলেন, সেই উত্তরটির সাথে সেই পরামর্শটির পক্ষে ভোট দেওয়া হয়েছে।

মাইকেল ভ্যালেন্টি বিকাশকারীকে কী প্রত্যাশা করা যেতে পারে তা জানানোর জন্য একটি নামকরণের সম্মেলনের পরামর্শ দেয়। জিরো কনসেপ্ট ব্যতিক্রমের যথাযথ ব্যবহারের পরামর্শ দেয়, যদি এটি NUL এর কারণ হয়। এবং অন্যদের.

আমরা যদি সর্বদা রক্ষণাত্মক প্রোগ্রামিং করতে চাই "নিয়ম" তৈরি করি তবে আমরা দেখতে পাব যে এই পরামর্শগুলি বৈধ।

তবে আমাদের কাছে দুটি বিকাশের পরিস্থিতি রয়েছে।

বিকাশকারী "রচয়িতা" ক্লাস: লেখক

অন্য (সম্ভবত) বিকাশকারী দ্বারা "গ্রাসিত" শ্রেণি: বিকাশকারী

কোনও শ্রেণি একটি রিটার্ন মান সহ পদ্ধতিগুলির জন্য NULL প্রদান করে কিনা তা নির্বিশেষে, বিকাশকারীকে বস্তুটি বৈধ কিনা তা পরীক্ষা করতে হবে।

যদি বিকাশকারী এটি করতে না পারে তবে সেই শ্রেণি / পদ্ধতিটি নির্বিচারক নয়। এটি হ'ল, যদি "পদ্ধতি কল" অবজেক্টটি পেতে চায় তবে এটি "বিজ্ঞাপন" হিসাবে কী করে না (যেমন getEmployee) এটি চুক্তি ভঙ্গ করেছে।

কোনও শ্রেণীর লেখক হিসাবে আমি কোনও পদ্ধতি তৈরি করার সময় সর্বদা সদয় এবং প্রতিরক্ষামূলক (এবং সংজ্ঞাবাদী) হতে চাই।

সুতরাং প্রদত্ত যে NULL বা NULL OBJECT (উদাহরণস্বরূপ (যদি NullEmployee.ISVALID হিসাবে কর্মচারী)) পরীক্ষা করা দরকার এবং এটি কর্মচারীদের সংগ্রহের সাথে ঘটতে পারে তবে নাল অবজেক্টের পদ্ধতিকেই হল আরও ভাল পদ্ধতির।

তবে আমি মাইকেল ভ্যালেন্টির এই পদ্ধতির নামকরণের পরামর্শটিও পছন্দ করি যা অবশ্যই নালাগুলি ফিরে আসবে যেমন getEmployeeOrNull।

কোনও লেখক যিনি ব্যতিক্রম ছুঁড়েছেন এটি বিকাশকারীর পক্ষে অবজেক্টের বৈধতা পরীক্ষা করার জন্য পছন্দটি সরিয়ে দিচ্ছেন, যা বস্তুর সংগ্রহের ক্ষেত্রে খুব খারাপ and

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

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

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

অন্য বর্গ / পদ্ধতি থেকে ফিরে আসা সামগ্রীর বৈধতা পরীক্ষা করতে বিকাশকারীকে সর্বদা রক্ষণাত্মক প্রোগ্রামিং ব্যবহার করা উচিত।

শুভেচ্ছা

GregJF

Answer 19

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

Answer 20

জটিল প্রোগ্রামগুলির বিকাশের সময় অজান্তেই নাল ফাংশনগুলি দেখা দিতে পারে এবং ডেড কোডের মতো এ জাতীয় ঘটনাগুলি প্রোগ্রাম কাঠামোর গুরুতর ত্রুটিগুলি নির্দেশ করে।

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

নাল_ফানশন @ উইকিপিডিয়া

Answer 21

ঠিক আছে, এটি নিশ্চিত যে পদ্ধতিটির উদ্দেশ্য নির্ভর করে ... কখনও কখনও, তার চেয়ে ব্যতিক্রম একটি ভাল পছন্দ হতে পারে। এটি সমস্ত ক্ষেত্রে থেকে কেস নির্ভর করে।

Answer 22

কোডটি যদি এমন কিছু হয়:

command = get_something_to_do()

if command:  # if not Null
    command.execute()

যদি আপনার একটি ডামি অবজেক্ট থাকে যার এক্সিকিউট () পদ্ধতিটি কিছুই করে না, এবং আপনি উপযুক্ত ক্ষেত্রে নলের পরিবর্তে ফিরে এসেছেন, আপনাকে নুল কেসটি পরীক্ষা করতে হবে না এবং পরিবর্তে কেবল এটি করতে পারবেন:

get_something_to_do().execute()

সুতরাং, এখানে সমস্যাটি একটি ব্যতিক্রম ব্যান্ডের তুলনায় NUL অনুসন্ধানের মধ্যে নয়, পরিবর্তে কলারটির মধ্যে বিশেষ নন-কেসগুলি আলাদাভাবে পরিচালনা করতে হবে (যেভাবেই হোক না কেন) is

Answer 23

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

Answer 24

গ দিন,

যখন আপনি একটি নতুন অবজেক্ট তৈরি করতে অক্ষম হন তখন NULL ফিরিয়ে দেওয়া অনেকগুলি API এর জন্য স্ট্যান্ডার্ড অনুশীলন।

কেন এটা খারাপ ডিজাইন আমার কোনও ধারণা নেই।

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

আছে HTH

'Avahappy,

Comments

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

— থিলো

@ তিলো, সি তে কীভাবে তা করতে হয় তা আমাকে দেখান এবং আমি সবচেয়ে আগ্রহী হব।

— রব ওয়েলস

@ রবওয়েলস সি কোনও অবজেক্ট-ভিত্তিক ভাষা নয়, তবে এই প্রশ্নটিকে "

— ওওপ

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

— রব ওয়েলস