জাভাতে নালগুলি হ্যান্ডেল করার সর্বোত্তম উপায়? [বন্ধ]

21

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

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

আপনার চিন্তা কি?

java  null 
— শন এফ
সূত্র
5
আপনি কেন "নালার কারণটি ঠিক করবেন না"? কেন এটি একমাত্র বুদ্ধিমান পছন্দ নয় এর একটি উদাহরণ আপনি সরবরাহ করতে পারেন? স্পষ্টতই, কিছু অবশ্যই আপনাকে সুস্পষ্ট থেকে দূরে ঠেলে দিবে। এটা কি? মূল কারণটি আপনার প্রথম পছন্দটি কেন ঠিক করা হচ্ছে না?
— এসলট
সমস্যাটির মূল কারণটি ঠিক করা স্বল্পমেয়াদে সহায়তা করতে পারে তবে কোডটি এখনও যদি রক্ষণাত্মকভাবে নালগুলির জন্য যাচাই করা না হয় এবং অন্য কোনও প্রক্রিয়া যা পুনরায় ব্যবহার করতে পারে তবে এটি আবার ঠিক করতে হবে।
— শান এফ
2
@ শনফ এফ: কোডটি নষ্ট হয়ে গেলে এটি ভেঙে যায়। কোডটি কীভাবে অপ্রত্যাশিত নাল উত্পাদন এবং স্থির না হওয়া সম্ভব তা আমি পাই না। স্পষ্টতই, কিছু "বোবা ম্যানেজমেন্ট" বা "রাজনৈতিক" জিনিস চলছে। অথবা এমন কোনও কিছু যা ভ্রান্ত কোডটি কোনওভাবে গ্রহণযোগ্য হতে দেয়। আপনি কীভাবে ভুল কোড সংশোধন হচ্ছে না তা ব্যাখ্যা করতে পারেন? এমন রাজনৈতিক পটভূমি যা আপনাকে এই প্রশ্ন জিজ্ঞাসা করতে পরিচালিত করে?
— এস্লট
1
"এরপরে ডেটা তৈরির পক্ষে যেগুলি শূন্য ছিল তার পক্ষে দুর্বল" এর অর্থ কী? যদি "আমি ডেটা তৈরির রুটিন ঠিক করতে পারি" তবে আর কোনও দুর্বলতা নেই। আমি বুঝতে সক্ষম নই যে এই "পরবর্তী ডেটা তৈরির যেটিতে শূন্যতা ছিল" এর অর্থ কী? বগি সফটওয়্যার?
— এস .লট
1
@ এসলট, এনক্যাপসুলেশন এবং একক দায়িত্ব। আপনার সমস্ত কোড আপনার অন্যান্য কোডগুলি কী করে "জানে" না। কোনও শ্রেণি যদি ফ্রোবিনেটরদের গ্রহণ করে, কে ফ্রোবাইনেটর এবং কীভাবে তৈরি করেছে সে সম্পর্কে এটি যতটা সম্ভব অনুমান করে। এটি "বাহ্যিক" কোড থেকে আসে, বা এটি কোড ভিত্তির ভিন্ন অংশ থেকে সবেমাত্র আসে। আমি বলছি না যে আপনার বগি কোড ঠিক করা উচিত নয়; তবে "ডিফেন্সিভ প্রোগ্রামিং" অনুসন্ধান করুন এবং ওপিকে কী উল্লেখ করা হচ্ছে তা আপনি খুঁজে পাবেন।
— পল ড্রপার

উত্তর:

45

যদি নাল আপনার পদ্ধতির জন্য যুক্তিসঙ্গত ইনপুট প্যারামিটার হয় তবে পদ্ধতিটি ঠিক করুন। যদি না হয়, কলার ঠিক করুন। "যুক্তিসঙ্গত" একটি নমনীয় শব্দ, সুতরাং আমি নিম্নলিখিত পরীক্ষার প্রস্তাব করছি: পদ্ধতিটি কীভাবে নাল ইনপুট হ্যান্ড করা উচিত? আপনি একটির বেশি সম্ভব উত্তর খুঁজে, তাহলে নাল না একটি যুক্তিসঙ্গত ইনপুট।

— user281377
সূত্র
1
এটা সত্যিই হিসাবে সহজ।
— বিজিকলপ
3
পেয়ারাতে খুব সুন্দর সাহায্যকারী পদ্ধতি রয়েছে যা নাল চেককে সহজ করে তোলে Precondition.checkNotNull(...)। দেখুন stackoverflow.com/questions/3022319/...
আমার নিয়ম হ'ল যদি সম্ভব হয় তবে বোধগম্য ডিফল্টগুলিতে সবকিছুই আরম্ভ করা এবং পরে নাল ব্যতিক্রমগুলি নিয়ে চিন্তা করা।
— davidk01
থরবজর্ন: সুতরাং এটি একটি দুর্ঘটনাজনিত নলপয়েন্টার এক্সসেপশনকে একটি ইচ্ছাকৃত নলপয়েন্টারএক্সসেপশনকে প্রতিস্থাপন করে? কিছু ক্ষেত্রে, প্রাথমিক চেক করা দরকারী বা এমনকি প্রয়োজনীয় হতে পারে; তবে আমি প্রচুর সংজ্ঞাহীন বয়লারপ্লেট নাল চেককে ভয় করি যা খুব কম মূল্য যুক্ত করে এবং প্রোগ্রামটিকে আরও বড় করে তোলে।
— ব্যবহারকারী 281377
6
যদি নাল আপনার পদ্ধতির কোনও যুক্তিসঙ্গত ইনপুট প্যারামিটার না হয় তবে পদ্ধতিটির কলগুলি ঘটনাক্রমে নাল পাস করার সম্ভাবনা রয়েছে (বিশেষত যদি পদ্ধতিটি সর্বজনীন হয়), আপনি নালার সময় আপনার পদ্ধতিটি নিক্ষেপ করতেও চাইতে পারেন IllegalArgumentException। এটি বাগের কোডগুলিতে (পদ্ধতিটিতে না থেকে বরং) পদ্ধতিটির কলকারীদেরকে ইঙ্গিত দেয়।
— ব্রায়ান
20

নাল ব্যবহার করবেন না, ptionচ্ছিক ব্যবহার করুন

আপনি উল্লেখ করেছেন যে, nullজাভাতে সবচেয়ে বড় সমস্যা হ'ল এটি সর্বত্র বা কমপক্ষে সমস্ত রেফারেন্স ধরণের জন্য ব্যবহার করা যেতে পারে ।

এটি হতে পারে nullএবং এটি কী হতে পারে তা বলা অসম্ভব ।

জাভা 8 প্রবর্তন অনেক ভালো প্যাটার্ন: Optional।

এবং ওরাকল থেকে উদাহরণ:

String version = "UNKNOWN";
if(computer != null) {
  Soundcard soundcard = computer.getSoundcard();
  if(soundcard != null) {
    USB usb = soundcard.getUSB();
    if(usb != null) {
      version = usb.getVersion();
    }
  }
}

যদি এগুলির প্রতিটি একটি সফল মান ফেরত দিতে বা না পারে তবে আপনি এপিআইগুলিকে Optionalএস তে পরিবর্তন করতে পারেন :

String name = computer.flatMap(Computer::getSoundcard)
    .flatMap(Soundcard::getUSB)
    .map(USB::getVersion)
    .orElse("UNKNOWN");

প্রকারে স্পষ্টভাবে এনকোডিং বিকল্পের দ্বারা, আপনার ইন্টারফেসগুলি আরও ভাল হবে এবং আপনার কোডটি আরও পরিষ্কার হবে।

আপনি যদি জাভা 8 ব্যবহার না করে com.google.common.base.Optionalথাকেন তবে গুগল পেয়ারাতে দেখতে পারেন ।

পেয়ারা টিমের একটি ভাল ব্যাখ্যা: https://github.com/google/guava/wiki/UsingAndAvoidingNullExplained

নালাগুলির অসুবিধাগুলির আরও সাধারণ ব্যাখ্যা, বেশ কয়েকটি ভাষার উদাহরণ সহ: https://www.lucidchart.com/techblog/2015/08/31/the-worst-mistake-of-computer-s विज्ञान/

@ ননল, @ ননবল

জাভা 8 আইডিইর মতো সমস্যাগুলি ধরার জন্য কোড চেক করার সরঞ্জামগুলিতে সহায়তা করতে এই টীকাগুলি যুক্ত করে। তারা তাদের কার্যকারিতা মধ্যে মোটামুটি সীমিত।

যখন এটি বোধগম্য হয় তা পরীক্ষা করুন

আপনার কোড চেকিংয়ের 50% নাল লিখবেন না, বিশেষত যদি আপনার কোডটি কোনও nullমান দিয়ে করতে পারে তেমন বুদ্ধিমান কিছুই না থাকে ।

অন্যদিকে, যদি nullকিছু ব্যবহার করা যায় এবং কিছু বোঝাতে পারে তবে এটি অবশ্যই নিশ্চিত করে নিন।

শেষ পর্যন্ত, আপনি অবশ্যই nullজাভা থেকে সরাতে পারবেন না । আমি Optionalযখনই সম্ভব বিমূর্তিটি প্রতিস্থাপনের দৃ strongly়রূপে পরামর্শ দিচ্ছি , এবং nullঅন্যান্য সময়ে যাচাই করা উচিত যে আপনি এটি সম্পর্কে যুক্তিসঙ্গত কিছু করতে পারেন।

— পল ড্রাগার
সূত্র
2
সাধারণত, চার বছরের পুরানো প্রশ্নের উত্তরগুলি নিম্ন মানের কারণে মুছে ফেলা হয়। জাভা 8 (যা আগে উপস্থিত ছিল না) সমস্যাটি কীভাবে সমাধান করতে পারে সে সম্পর্কে কথা বলা ভাল কাজ।
তবে অবশ্যই মূল প্রশ্নের সাথে অপ্রাসঙ্গিক। এবং যুক্তিটি আসলে toচ্ছিক বলার কী আছে?
— জেভেন্টিং
5
@ জওয়েন্টিং এটি মূল প্রশ্নের সাথে সম্পূর্ণ প্রাসঙ্গিক। "স্ক্রু ড্রাইভারের সাথে পেরেক চালানোর সর্বোত্তম উপায় কী" এর উত্তর হ'ল "স্ক্রু ড্রাইভারের পরিবর্তে হাতুড়িটি ব্যবহার করুন"।
— দেনিথ
@ জেন্টিং, আমি মনে করি আমি এটি আবৃত করেছি, তবে স্পষ্টতার জন্য: যুক্তিটি alচ্ছিক নয়, আমি সাধারণত নালার জন্য পরীক্ষা করতাম না। আপনার কাছে 100 টি লাইন নাল চেকিং এবং 40 লাইনের পদার্থ থাকবে। আরও পাবলিক ইন্টারফেসে নাল পরীক্ষা করুন, বা নালটি আসলে বোধগম্য হবে (যেমন যুক্তিটি alচ্ছিক)।
— পল ড্রপার
4
@ জে-বস, কিভাবে, জাভা, আপনি হবে না একটি অবারিত আছে NullPointerException? একটি NullPointerExceptionআক্ষরিক ঘটতে পারে প্রত্যেক সময় আপনি জাভা একটি দৃষ্টান্ত পদ্ধতি কল। আপনি throws NullPointerExceptionপ্রায় প্রতিটি একক পদ্ধতিতে পেতে পারেন।
— পল ড্রাগন
8

এটি পরিচালনা করার একাধিক উপায় রয়েছে, এতে আপনার কোডটি মেশানো if (obj != null) {}আদর্শ নয়, এটি অগোছালো, পরে রক্ষণাবেক্ষণ চক্রের সময় কোডটি পড়ার সময় শব্দের যোগ করে এবং ত্রুটি প্রবণ হয়, কারণ এই বয়লার প্লেট মোড়ানোটি ভুলে যাওয়া সহজ।

আপনি যদি কোডটি চুপ করে চালানো চালিয়ে যেতে চান বা ব্যর্থ হন তবে এটি নির্ভর করে। কি nullএকটি ত্রুটি অথবা একটি প্রত্যাশিত শর্ত।

নাল কি

প্রতিটি তফসিল এবং ক্ষেত্রে, নাল তথ্য সম্পূর্ণরূপে অভাব প্রতিনিধিত্ব করে। ডাটাবেসগুলিতে নালগুলি সেই কলামটির জন্য একটি মানের অভাব উপস্থাপন করে। একটি নাল Stringশূন্যের মতো নয়, তাত্ত্বিকভাবে Stringনাল intজেরোর মতো জিনিস নয়। অনুশীলনে "এটি নির্ভর করে"। খালি স্ট্রিং ক্লাসের জন্য Stringএকটি ভাল Null Objectবাস্তবায়ন করতে পারে , কারণ Integerএটি ব্যবসার যুক্তি নির্ভর করে।

বিকল্পগুলি হ'ল:

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

  2. Null Checkerপরামিতিগুলি শূন্য হতে বাধা দেয় এমন দিকগুলির সাথে পদ্ধতিগুলি বুনতে অ্যাসপেক্ট ওরিয়েন্টেড সরঞ্জামগুলি ব্যবহার করুন । এটি এমন nullএকটি ক্ষেত্রে যেখানে ত্রুটি রয়েছে।

  3. কম শব্দের assert()চেয়ে বেশি ভাল ব্যবহার করবেন না if (obj != null){}।

  4. একটি চুক্তি প্রয়োগকারী সরঞ্জাম যেমন জাভার জন্য চুক্তি ব্যবহার করুন । AspectJ এর মতো কিছু হিসাবে একই ব্যবহারের ক্ষেত্রে ক্ষেত্রে আরও নতুন এবং বাহ্যিক কনফিগারেশন ফাইলের পরিবর্তে টিকা ব্যবহার করে। উভয় দিকের দিক থেকে এবং কাজগুলির মধ্যে সেরা।

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

2, 3 এবং 4 NullPointerExceptionহ'ল আরও কিছু তথ্যমূলক কিছু প্রতিস্থাপনের জন্য কেবল বিকল্প সুবিধা ব্যতিক্রম জেনারেটর যা সর্বদা এবং উন্নতি।

শেষে

nullজাভা প্রায় সব ক্ষেত্রেই একটি যুক্তি ত্রুটি। এর মূল কারণটি দূর করার জন্য আপনার সর্বদা প্রচেষ্টা করা উচিত NullPointerExceptions। আপনার nullশর্তগুলি ব্যবসার যুক্তি হিসাবে ব্যবহার না করার চেষ্টা করা উচিত । if (x == null) { i = someDefault; }কেবলমাত্র সেই ডিফল্ট অবজেক্ট দৃষ্টান্তের জন্য প্রাথমিক দায়িত্বটি তৈরি করুন।

যদি সম্ভব হয় নাল অবজেক্ট প্যাটার্নটি হ'ল উপায়, নাল কেসটি হ্যান্ডেল করার জন্য এটি সর্বাধিক দৃষ্টিনন্দন উপায়। এটি বিরল যে আপনি উত্পাদনে স্টাফগুলি ফুটিয়ে তুলতে নাল চান!
— রিচার্ড মিসকিন
@ রিচার্ড: যদি nullতা অপ্রত্যাশিত না হয় তবে তা সত্য ত্রুটি, তারপরে সমস্ত কিছু সম্পূর্ণ বন্ধ হয়ে যাওয়া উচিত।
ডাটাবেসগুলিতে এবং প্রোগ্রামিং কোডে নাল একটি গুরুত্বপূর্ণ দিক থেকে আলাদাভাবে পরিচালিত হয়: প্রোগ্রামিংয়ে, null == null(এমনকি পিএইচপিতে), তবে null != nullডাটাবেসগুলিতে , কারণ ডাটাবেসে এটি "কিছুই না" পরিবর্তে একটি অজানা মান উপস্থাপন করে । দুটি অজানা অগত্যা সমান নয়, দুটি নোটিশ সমান।
— সাইমন ফোর্সবার্গ
8

নাল চেক যোগ করার ফলে পরীক্ষার সমস্যা হতে পারে। এই দুর্দান্ত বক্তৃতা দেখুন ...

গুগল টেকের আলোচনার বক্তৃতাটি দেখুন: "ক্লিন কোড কথাবার্তা - জিনিসগুলির জন্য তাকান না!" তিনি 24 মিনিটের দিকে এটি সম্পর্কে কথা বলেন

http://www.youtube.com/watch?v=RlfLCWKxHJ0&list=PL693EFD059797C21E

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

এছাড়াও, যখন আপনি কিছু বস্তুর অস্তিত্বের জন্য পূর্ব শর্ত তৈরি করেন যেমন 

class House(Door door){

    .. null check here and throw exception if Door is NULL
    this.door = door
}

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

যারা মক সৃষ্টি জাহান্নামের মধ্য দিয়ে ভোগ করেছেন তারা এই ধরণের বিরক্তি সম্পর্কে ভাল জানেন।

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

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

— কনস্ট্যান্টিন
সূত্র
4

tl; dr - অপ্রত্যাশিতদের জন্য ভাল যাচাই করা ভাল nullতবে কোনও অ্যাপ্লিকেশন তাদের ভাল করার চেষ্টা করার জন্য BAD।

বিস্তারিত

স্পষ্টতই, এমন পরিস্থিতি রয়েছে যেখানে nullকোনও পদ্ধতির বৈধ ইনপুট বা আউটপুট এবং অন্যেরা যেখানে তা নয়।

বিধি # 1:

এমন একটি পদ্ধতির জাভাডোক যা কোনও nullপ্যারামিটারকে মঞ্জুরি দেয় বা কোনও nullমান প্রদান করে তা অবশ্যই স্পষ্টভাবে এটি নথিভুক্ত করতে হবে এবং এটি কী তা ব্যাখ্যা করবেnull অর্থ ।

বিধি # 2:

কোনও API পদ্ধতি গ্রহণ বা ফিরে হিসাবে নির্দিষ্ট করা উচিত নয় null যদি না তা করার উপযুক্ত কারণ থাকে is

কোনও পদ্ধতির "চুক্তি" ভিস-এ-ভিস nullএর স্পষ্ট বিবরণ দেওয়া , এটি একটি প্রোগ্রামিং ত্রুটিnull যেখানে পাস করা উচিত নয় সেখানে পাস বা ফিরিয়ে দেওয়া একটি ।

বিধি # 3:

কোনও অ্যাপ্লিকেশনটির প্রোগ্রামিং ত্রুটি "ভাল করার" চেষ্টা করা উচিত নয়।

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

বিধি # 4:

যেখানে সম্ভব, সেখানে প্রোগ্রামিংয়ের ত্রুটিগুলি শনাক্ত করার জন্য আপনার কোডটি লিখুন।

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

public setName(String name) {
    // This also detects `null` as an (intended) side-effect
    if (name.length() == 0) {
        throw new IllegalArgumentException("empty name");
    }
}

(স্পষ্টতই এমন ঘটনা রয়েছে যেখানে 3 এবং 4 এর বিধিগুলি বাস্তবের সাথে মেজাজ করা উচিত instance উদাহরণস্বরূপ (বিধি 3), কিছু প্রকারের অ্যাপ্লিকেশনগুলিতে সম্ভবত প্রোগ্রামিং ত্রুটিগুলি সনাক্ত করার পরে চালিয়ে যাওয়ার চেষ্টা করতে হবে And এবং (নিয়ম 4) খারাপ পরামিতিগুলির জন্য খুব বেশি চেক থাকতে পারে একটি কর্মক্ষমতা প্রভাব।)

— স্টিফেন সি
সূত্র
3

আমি রক্ষণাত্মক হতে পদ্ধতিটি স্থির করার সুপারিশ করব। এই ক্ষেত্রে: 

String go(String s){  
    return s.toString();  
}

এর লাইনের সাথে আরও হওয়া উচিত: 

String go(String s){  
    if(s == null){  
       return "";  
    }     
    return s.toString();  
}

আমি বুঝতে পেরেছি এটি একেবারে তুচ্ছ, কিন্তু যদি চালকরা প্রত্যাশা করে যে কোনও বস্তু তাদের একটি ডিফল্ট বস্তু দেয় যা শূন্যতার পাশ কাটিয়ে দেবে না।

— Woot4Moo
সূত্র
10
এটিতে একটি বাজে পার্শ্ব-প্রতিক্রিয়া রয়েছে যে কলার (প্রোগ্রামার যিনি এই API এর বিরুদ্ধে কোড করেন) "ডিফল্ট" আচরণ পেতে প্যারামিটার হিসাবে নাল পাস করার অভ্যাস বিকাশ করতে পারে।
— গোরান জোভিক
2
এটি যদি জাভা হয় তবে আপনার ব্যবহার new String()করা উচিত নয় ।
— বিজিক্লপ
1
@ বিজিক্লপ আসলে এটি বেশিরভাগ উপলব্ধির চেয়ে অনেক বেশি গুরুত্বপূর্ণ।
— Woot4Moo
1
আমার মতে যুক্তিটি বাতিল হয়ে থাকলে একটি দৃ an় অবস্থান রাখা এবং একটি ব্যতিক্রম ছুঁড়তে আরও বুদ্ধিমান হয়, কারণ এটি স্পষ্টতই কলারের ভুল। কলার ভুলগুলি চুপচাপ "সংশোধন" করবেন না; পরিবর্তে, তাদের সম্পর্কে তাদের সচেতন করুন।
— আন্দ্রেস এফ।
1
@ Woot4Moo সুতরাং আপনার নিজের কোড লিখুন যা তার পরে ব্যতিক্রম ছুঁড়ে ফেলে। গুরুত্বপূর্ণ বিষয়টি হ'ল কলকারীকে জানানো যে তাদের পাস হওয়া যুক্তিগুলি ভুল, এবং যত তাড়াতাড়ি সম্ভব তাদের বলুন। নিঃশব্দে nullএস সংশোধন করা সবচেয়ে খারাপ সম্ভাব্য বিকল্প, এনপিই নিক্ষেপের চেয়েও খারাপ।
— আন্দ্রেস এফ।
2

নাল সম্পর্কে নিম্নলিখিত সাধারণ নিয়মাবলী আমাকে এখনও পর্যন্ত অনেক সাহায্য করেছে:

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

  2. যদি নাল আপনার ডেটা মডেলের উপযুক্ত মানগুলির ডোমেনের মধ্যে থাকে তবে এটি যথাযথভাবে মোকাবেলা করুন।

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

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

এটি নালাগুলি সম্পর্কে প্রায়শই কিছুটা ঝোঁক দেয় যা প্রায়শই ফেইডস এবং প্রক্সিগুলির দিকে পরিচালিত করে যা বাইরের পৃথিবীতে ইন্টারফেস সিস্টেম এবং প্রচুর অতিরিক্ত অপ্রয়োজনীয়তার সাথে অভ্যন্তরে কঠোরভাবে নিয়ন্ত্রণিত মানগুলি নিয়ে আসে। এখানে বাইরের বিশ্বের অর্থ অনেক কিছুই আমি নিজের কোড করি নি। এটি একটি ব্যয় রানটাইম বহন করে তবে এখনও পর্যন্ত আমি কোডের "নাল নিরাপদ বিভাগ" তৈরি করে খুব কমই এটিকে অনুকূল করতে হয়েছিল। আমার অবশ্যই বলতে হবে যে আমি বেশিরভাগই স্বাস্থ্যসেবা জন্য দীর্ঘ চলমান সিস্টেম তৈরি করি এবং সর্বশেষ যেটিটি আমি চাই তা হ'ল আপনার আয়োডিন অ্যালার্জি সিটি স্ক্যানারের ক্র্যাশগুলিতে নিয়ে যাওয়া ইন্টারফেস সাবসিস্টেমটি অপ্রত্যাশিত নাল পয়েন্টারটির কারণে ঘটেছিল কারণ অন্য কোনও সিস্টেমে অন্য কেউ কখনই বুঝতে পারেনি যে নামগুলি পারে অ্যাস্ট্রোফ্রেস বা characters 耒耨 like এর মতো অক্ষর থাকতে পারে

যাইহোক .... আমার 2 সেন্ট

— Newtopian
সূত্র
1

আমি কার্যকরী ভাষা থেকে বিকল্প / কিছু / কিছুই না প্যাটার্ন ব্যবহার করার প্রস্তাব করব। আমি জাভা বিশেষজ্ঞ নই, তবে আমি নিজের সি # প্রকল্পে এই নিদর্শনটির নিজস্ব প্রয়োগটি নিবিড়ভাবে ব্যবহার করি এবং আমি নিশ্চিত যে এটি জাভা বিশ্বে রূপান্তরিত হতে পারে।

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

এই ক্ষেত্রে, আপনাকে অবশ্যই মান অনুপস্থিতির সম্ভাবনাটি পরিচালনা করতে হবে এবং আপনি যদি কোড পর্যালোচনা করেন তবে সহজেই ভুল হ্যান্ডলিংয়ের স্থান খুঁজে পেতে পারেন। সি # ভাষার বাস্তবায়ন থেকে অনুপ্রেরণা পেতে আমার বিটবাকেট সংগ্রহস্থলটি দেখুন https://bitbucket.org/mikegirkin/optionsomenone

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

— Hedin
সূত্র
0

ঠিক আছে যদি আপনার পদ্ধতির সম্ভাব্য ফলাফলগুলির একটি নাল মান হয় তবে তার জন্য আপনার ডিফেন্সিয়ালি কোড করা উচিত code

যথারীতি এটি জীবনের বেশিরভাগ জিনিসগুলির মতো, মামলার উপর নির্ভর করে :)

— jonezy
সূত্র
0

অ্যাপাচি কমন্সের ল্যাং লাইব্রেরি নাল মানগুলি হ্যান্ডেল করার একটি উপায় সরবরাহ করে

পদ্ধতি defaultIfNull ক্লাসে ObjectUtils ডিফল্ট মান আসতে হলে বস্তুর পাশ নাল করতে সক্ষম

— মাহমুদ হোসাম
সূত্র
0

  1. Trulyচ্ছিক প্রকারটি ব্যবহার করবেন না, যদি না এটি সত্যই optionচ্ছিক হয় তবে প্রায়শই প্রস্থানটি ব্যতিক্রম হিসাবে ভালভাবে পরিচালনা করা হয়, যদি না আপনি সত্যিকার অর্থে কোনও বিকল্প হিসাবে নালার প্রত্যাশা না করতেন, এবং আপনি নিয়মিত বগী কোডটি লেখেননি বলে নয়।

  2. গুগলের নিবন্ধটি দেখায় যে সমস্যাটি এর ব্যবহারগুলির মতো রয়েছে তেমন শূন্য নয়। সমস্যাটি হ'ল নালগুলি চেক করা উচিত এবং পরিচালনা করা উচিত, প্রায়শই তারা কৃপণভাবে বেরিয়ে আসতে পারে।

  3. প্রোগ্রামের রুটিন অপারেশনের বাইরের অঞ্চলে (অবৈধ ব্যবহারকারী ইনপুট, ডাটাবেস ইস্যু, নেটওয়ার্ক ব্যর্থতা, ফাইলগুলি হারিয়ে যাওয়া, দুর্নীতিগ্রস্ত ডেটা) অবৈধ অবস্থার প্রতিনিধিত্ব করে এমন অনেকগুলি নাল মামলা রয়েছে, যা চেক করা ব্যতিক্রমগুলি হ'ল তাদের পরিচালনা করার জন্যও, যদি এটি কেবল এটি লগ করা হয়।

  4. ব্যতিক্রম হ্যান্ডলিংকে JVM- এ বিভিন্ন অপারেশনাল অগ্রাধিকার এবং সুবিধাগুলির অনুমতি দেওয়া হয় যেমন aচ্ছিকর মতো, যা হ্যান্ডলারের মেমরির ক্ষেত্রে অগ্রাধিকারপ্রাপ্ত অলস লোডিংয়ের জন্য প্রাথমিক সমর্থন সহ তাদের উপস্থিতিগুলির ব্যতিক্রমী প্রকৃতির পক্ষে বোঝায় since এটি সর্বদা ঝুলন্ত প্রয়োজন।

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

সুতরাং আমি অনুমান করি যে আমার উত্তরটি এটি একটি চেক করা ব্যতিক্রমগুলিতে আবদ্ধ করবে এবং এটি পরিচালনা করবে, অথবা যদি এটি আপনার সামর্থ্যের মধ্যে থাকে তবে অবিশ্বস্ত কোডটি ঠিক করুন।

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