উদ্দেশ্যমূলক আচরণ করার আগে যদি ফাংশনগুলিকে নাল চেক করতে হয় তবে এটি কি এই খারাপ নকশা?

Question

সুতরাং আমি জানি না এটি ভাল বা খারাপ কোড ডিজাইন কিনা তাই আমি ভেবেছিলাম আমি আরও ভাল জিজ্ঞাসা করব।

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

খুব মৌলিক উদাহরণের জন্য:

// fields and properties
private Entity _someEntity;
public Entity SomeEntity => _someEntity;

public void AssignEntity(Entity entity){
    _someEntity = entity;
}
public void SetName(string name)
{
    if (_someEntity == null) return; //check to avoid null ref
    _someEntity.Name = name;
    label.SetText(_someEntity.Name);
}

আপনি দেখতে পাচ্ছেন প্রতিটি সময় নাল জন্য im পরীক্ষা করা। কিন্তু পদ্ধতিতে কি এই চেকটি রাখা উচিত নয়?

উদাহরণস্বরূপ বাহ্যিক কোডগুলি হাতের আগে ডেটা পরিষ্কার করা উচিত যাতে পদ্ধতিগুলি নীচের মত যাচাই করার প্রয়োজন হয় না:

 if(entity != null) // this makes the null checks redundant in the methods
 {
     Manager.AssignEntity(entity);
     Manager.SetName("Test");
 }

সংক্ষেপে, পদ্ধতিগুলি "ডেটা বৈধকরণের" হওয়া উচিত এবং তারপরে ডেটাতে তাদের প্রক্রিয়াজাতকরণ করা উচিত, বা পদ্ধতিটি কল করার আগে এটির নিশ্চয়তা দেওয়া উচিত, এবং যদি আপনি পদ্ধতিটি কল করার আগে বৈধতা দিতে ব্যর্থ হন তবে এটি একটি ত্রুটি ছুঁড়ে ফেলবে (বা ধরুন ত্রুটি)?

Comments

যখন কেউ নাল চেক করতে ব্যর্থ হয় এবং সেটনাম যেভাবেই ব্যতিক্রম ছুঁড়ে ফেলে?

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

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

— gnasher729 21

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

— mgarciaisaia

সি # 8 এর সাথে আপনার সঠিক সেটিংস চালু হওয়ার সাথে আপনাকে কখনই নাল রেফারেন্স ব্যতিক্রমগুলি নিয়ে চিন্তা করতে হবে না: ব্লগস.এমএসএনএন.মাইক্রোসফট.ডটনেট

— /

সি # ভাষা দল নালযোগ্য রেফারেন্স প্রকারগুলি (এবং অণুযোগ্য

— মাফাই

Answer 1

আপনার মৌলিক উদাহরণের সমস্যাটি নাল চেক নয়, এটি নীরব ব্যর্থ ।

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

1. চেক করতে বিরক্ত করবেন না, এবং রানটাইমটি নালপয়েন্টার ব্যতিক্রম নিক্ষেপ করুন।
2. বেসিক এনপিই ম্যাসেজের চেয়ে ভাল একটি বার্তা সহ পরীক্ষা করুন এবং নিক্ষেপ করুন।

তৃতীয় সমাধানটি বেশি কাজ করা তবে এটি অনেক বেশি শক্তিশালী:

3. আপনার শ্রেণীর কাঠামোটি এমন করুন যে এটি _someEntityকখনও অবৈধ অবস্থায় থাকা কার্যত অসম্ভব । এটি করার একটি উপায় হ'ল তাড়াতাড়ি পরিত্রাণ পাওয়া AssignEntityএবং তা ইনস্ট্যান্টেশনের প্যারামিটার হিসাবে প্রয়োজন। অন্যান্য নির্ভরতা ইনজেকশন কৌশলগুলিও কার্যকর হতে পারে।

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

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

Comments

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

— whatsisname

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

— মার্টিনাস

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

— jpmc26

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

— ডায়োগো কলারস

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

— এমব্রিগ

Answer 2

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

এই সমস্যাটির জন্য একটি পন্থা তাই আরও রক্ষণাত্মক হওয়া এবং নিম্নলিখিতগুলির একটি করা:

1. একটি স্থানীয় অনুলিপি তৈরি করুন _someEntityএবং পদ্ধতিটির মাধ্যমে অনুলিপি করুন,
2. _someEntityপদ্ধতিটি কার্যকর হওয়ার সাথে সাথে এটি পরিবর্তন হয় না তা নিশ্চিত করতে চারপাশে একটি লক ব্যবহার করুন ,
3. আপনি প্রাথমিক নাল চেক (এই ক্ষেত্রে, একটি ক্রিয়া) সম্পাদন করতে চাইলে পদ্ধতির মধ্যে ঘটে যাওয়া যে কোনওটির try/catchউপর একই ক্রিয়া করুন এবং ব্যবহার করুন ।NullReferenceExceptionnop

তবে আপনার যা করা উচিত তা হ'ল থামুন এবং নিজেকে প্রশ্ন করুন: আপনার কি আসলে _someEntityওভাররাইট করার অনুমতি দেওয়ার দরকার আছে ? কনস্ট্রাক্টরের মাধ্যমে কেন এটি একবার সেট করবেন না। এইভাবে, আপনার কেবল প্রয়োজন কেবল সেই একবারে যাচাই করা দরকার:

private readonly Entity _someEntity;

public Constructor(Entity someEntity)
{
    if (someEntity == null) throw new ArgumentNullException(nameof(someEntity));
    _someEntity = someEntity;
}

public void SetName(string name)
{
    _someEntity.Name = name;
    label.SetText(_someEntity.Name);
}

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

বোনাস মন্তব্য হিসাবে, আমি মনে করি আপনার কোডটি অদ্ভুত এবং উন্নত হতে পারে। সব:

private Entity _someEntity;
public Entity SomeEntity => _someEntity;

public void AssignEntity(Entity entity){
    _someEntity = entity;
}

এর সাথে প্রতিস্থাপন করা যেতে পারে:

public Entity SomeEntity { get; set; }

যার একই কার্যকারিতা রয়েছে, সম্পত্তি নামকারের মাধ্যমে ক্ষেত্রটি সেট করতে সক্ষম হওয়ার পরিবর্তে আলাদা নামের সাথে কোনও পদ্ধতির পরিবর্তে save

Comments

কেন এই প্রশ্নের উত্তর দেয়? প্রশ্নটি নাল চেকিংয়ের ঠিকানা দেয় এবং এটি একটি কোড পর্যালোচনা pretty

— আইইটিবেগেলস

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

— ডেভিড আরনো

Answer 3

কিন্তু পদ্ধতিতে কি এই চেকটি রাখা উচিত নয়?

এটি আপনার পছন্দ।

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

কী ধরণের চুক্তি আপনি ডিজাইন করতে চান তা আপনার হাতে। গুরুত্বপূর্ণ বিষয়গুলি হল

• দরকারী এবং সামঞ্জস্যপূর্ণ এবং

• এটি ভাল নথিভুক্ত করার জন্য, বিশেষত যারা প্রান্ত ক্ষেত্রে।

কীভাবে আপনার পদ্ধতিটি বলা হচ্ছে তা কী কী?

Comments

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

— Deduplicator

Answer 4

অন্য উত্তরগুলি ভাল; অ্যাক্সেসিবিলিটি মডিফায়ার সম্পর্কে কিছু মন্তব্য করে আমি তাদের প্রসারিত করতে চাই। প্রথমত, nullকখনই বৈধ না হলে কী করবেন :

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

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

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

উদাহরণস্বরূপ, আপনি এই পরিস্থিতিতে থাকতে চান না:

class Person { ... }
...
class ExpenseReport { 
  public void SubmitReport(Person approver) { 
    if (approver == null) ... do something ...

এবং কল সাইটে:

// I guess this works but I don't know what it means
expenses.SubmitReport(null); 

কারণ (1) আপনি আপনার কলারদের প্রশিক্ষণ দিচ্ছেন যে নাল একটি ভাল মান এবং (2) এই মানটির শব্দার্থকতা কী তা স্পষ্ট নয়। বরং এটি করুন:

class ExpenseReport { 
  public static readonly Person ApproverNotRequired = new Person();
  public static readonly Person ApproverUnknown = new Person();
  ...
  public void SubmitReport(Person approver) { 
    if (approver == null) throw ...
    if (approver == ApproverNotRequired) ... do something ...
    if (approver == ApproverUnknown) ... do something ...

এবং এখন কল সাইটটি এর মতো দেখাচ্ছে:

expenses.SubmitReport(ExpenseReport.ApproverNotRequired);

এবং এখন কোডটির পাঠক জানে এটির অর্থ।

Comments

আরও ভাল, ifনাল বস্তুর জন্য s এর একটি চেইন রাখবেন না বরং তাদের সঠিকভাবে আচরণ করার জন্য পলিমারফিজম ব্যবহার করুন।

— কনরাড রুডল্ফ

@ কনরাড রুডল্ফ: প্রকৃতপক্ষে, এটি প্রায়শই ভাল কৌশল। আমি এটি ডেটা স্ট্রাকচারের জন্য ব্যবহার করতে চাই, যেখানে আমি এমন একটি EmptyQueueটাইপ তৈরি করি যা যখন শনাক্ত হওয়ার পরে নিক্ষেপ করা হয় ইত্যাদি on

— এরিক লিপার্ট

@ এরিকলিপার্ট - আমাকে ক্ষমা করুন কারণ আমি এখনও এখানে শিখছি, তবে ধরুন যে Personক্লাসটি অপরিবর্তনীয় ছিল এবং যদি এটিতে শূন্য আর্গুমেন্ট কনস্ট্রাক্টর না থাকে তবে আপনি কীভাবে আপনার ApproverNotRequiredবা ApproverUnknownউদাহরণগুলি তৈরি করবেন? অন্য কথায়, আপনি কনস্ট্রাক্টরকে কোন মানটি পাস করবেন?

আমি আপনার উত্তর / মন্তব্যগুলি এসই জুড়ে বাম্পিং করতে পছন্দ করি, তারা সর্বদা অন্তর্দৃষ্টিশীল। অভ্যন্তরীণ / বেসরকারী পদ্ধতিগুলির প্রতি

— দৃ saw়তা দেখানোর সাথে সাথেই

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

— এরিক লিপার্ট

Answer 5

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

public static class Foo {
    public static void Frob(Bar a, Bar b) {
        if (a == null) throw new ArgumentNullException(nameof(a));
        if (b == null) throw new ArgumentNullException(nameof(b));

        a.Something = b.Something;
    }
}

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

a.Something = b.Something;

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

আমি লক্ষ্য করব যে আপনার মূল কোডটিতে প্যাটার্ন:

if (x == null) return;

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

Answer 6

না মোটেও নয়, তবে এটি নির্ভর করে।

আপনি যদি এটিতে প্রতিক্রিয়া জানাতে চান তবে কেবল নাল রেফারেন্স চেক করুন।

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

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

Answer 7

@ নাল এর উত্তরে কিছুটা বাড়ানোর কথা, তবে আমার অভিজ্ঞতায় নাল যাচাই করা যায় না কেন তা পরীক্ষা করে দেখুন।

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

এখন, আপনি কীভাবে কোনও nullমূল্যের সাথে কীভাবে व्यवहार করেন, এটি আপনার ব্যবহারের ক্ষেত্রে খুব বেশি নির্ভর করে।

যদি nullকোনও গ্রহণযোগ্য মান হয়, যেমন, এমএসভিসি রুটিন _স্প্লিটপথ () এর পঞ্চম প্যারামিটারগুলির মধ্যে দ্বিতীয়টির কোনওটি, তবে নীরবে এটির সাথে আচরণ করা সঠিক আচরণ।

যদি nullপ্রশ্নটি রুটিনকে কল করার সময় কখনও না ঘটে, যেমন ওপি'র ক্ষেত্রে এপিআই চুক্তিটি AssignEntity()একটি বৈধ সাথে ডাকা প্রয়োজন , Entityতবে একটি ব্যতিক্রম নিক্ষেপ করুন, বা অন্যথায় আপনি প্রক্রিয়াটিতে প্রচুর শব্দ করবেন তা নিশ্চিত করতে ব্যর্থ হন।

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

Comments

বা এটি পুরোপুরি এড়িয়ে চলুন (48 মিনিট 29 সেকেন্ড: "আপনার প্রোগ্রামের নিকটে কোথাও কোনও নাল পয়েন্টার ব্যবহার করবেন না বা অনুমতি দিন না" )।

— পিটার মর্টেনসেন