যখন কোনও আইটেম মোছার জন্য নির্দিষ্ট করা হয়নি তখন পরিষেবাটি ব্যতিক্রম ছুঁড়ে ফেলা উচিত বা ফিরে আসা উচিত


12

আমার কাছে কোডের একটি অংশ রয়েছে যা প্রতিনিধিত্ব করতে পারে:

public class ItemService {

    public void DeleteItems(IEnumerable<Item> items)
    {
        // Save us from possible NullReferenceException below.
        if(items == null)
            return;

        foreach(var item in items)
        {
            // For the purpose of this example, lets say I have to iterate over them.
            // Go to database and delete them.
        }
    }
}

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

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


2
এটি কেবল আমার ব্যক্তির মতামত, তবে আমি সর্বদা এটি সর্বাধিক বোধ করার জন্য খুঁজে পেয়েছি যে কোনও পদ্ধতি যখন অযৌক্তিক (ব্যতিক্রমী) কিছু করে তখন একটি ব্যতিক্রম ছুঁড়ে ফেলা উচিত। আপনার ক্ষেত্রে, যদি কেউ নাল / 0 টি আইটেম মুছতে চেষ্টা করে তবে আমি একটি অবৈধপ্রকাশের অভিজ্ঞতাটি নিক্ষেপ করব।
ফালাগান্টিল


1
@ জাগান আমার প্রশ্নটি পরিষেবাগুলি বিশেষত সেগুলি কীভাবে ব্যবহৃত হয় এবং তাদের উদ্দেশ্য সম্পর্কে। এই "সদৃশ" কেবলমাত্র সাধারণ কেস সম্পর্কে আলোচনা করে এবং মূল উত্তরটি এমনকি আমার সঠিক পদ্ধতির প্রসঙ্গে নিজেই স্ববিরোধিতা করে।
এফসিন

2
গণ্যমান্যদের পক্ষে কি নালার পরিবর্তে খালি থাকা সম্ভব? আপনি কি অন্যভাবে পরিচালনা করতে হবে?
জেএডি

13
@ ফালগান্টিল আমি দেখতে পাচ্ছি যে নাল একটি ব্যতিক্রমের যোগ্য, তবে আমি মনে করি যে একটি ব্যতিক্রম খালি তালিকায় ফেলে দেওয়া অবাস্তব।
কেভিন

উত্তর:


58

এই দুটি ভিন্ন প্রশ্ন।

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

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


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

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

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

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

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

9

নাল মান

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

nullমানগুলির বিষয়ে আপনার যদি ধারাবাহিক নীতি না থাকে তবে আমি নিম্নলিখিতটি সুপারিশ করব:

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

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

খালি তালিকা

একটি DeleteItems()পদ্ধতির জন্য, খালি তালিকা কার্যকরভাবে কার্যকর করার অর্থ কিছুই না করা। আমি এটিকে যুক্তি হিসাবে অনুমতি দেব, ব্যতিক্রম ছুঁড়ে না ফেলে, দ্রুত ফিরে আসছি।

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


1

কলিং কোডে একটি ব্যতিক্রম ছুঁড়ে ফেলুন এবং নালগুলি হ্যান্ডেল করুন।

একটি নকশার নিয়ম হিসাবে প্যারামিটার মান হিসাবে নাল এড়াতে চেষ্টা করুন। এটি সাধারণভাবে নালপয়েন্টার এক্সসেপশনগুলি হ্রাস করবে, কারণ নালগুলি সত্যই একটি ব্যতিক্রম হবে।

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


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

0

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

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

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


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

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

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

0

এই প্রশ্নটি ব্যতিক্রম সম্পর্কিত নয়, তবে nullএকটি বৈধ যুক্তি হিসাবে হবে বলে মনে হচ্ছে।

সুতরাং, প্রথম এবং সর্বাগ্রে আপনাকে সিদ্ধান্ত নিতে হবে nullযে সেই পদ্ধতির আপনার যুক্তির জন্য অনুমোদিত মান কিনা । যদি এটি হয় তবে আপনার ব্যতিক্রমের দরকার নেই। যদি এটি না হয় তবে আপনার ব্যতিক্রম দরকার।

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

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

সুতরাং আপনাকে সিদ্ধান্ত নিতে হবে: nullহ্যান্ডলিংয়ের মতো বৃহত্তর নীতি প্রয়োগ করা কি কোনও লাইব্রেরি পদ্ধতির কাজ ? বিশেষত যদি আপনার গ্রন্থাগারটি অন্য ব্যক্তিরাও ব্যবহার করেন তবে (যাদের বিভিন্ন নীতি থাকতে পারে)।

আমি সম্ভবত nullমূল্যবোধকে তাদের শব্দার্থবিজ্ঞানের সংজ্ঞা প্রদান ও ডকুমেন্টিংয়ের দিক দিয়ে ভুল করব (যেমন null = empty arrayএই ক্ষেত্রে) এবং যদি আপনার অন্যান্য অনুরূপ কোডের ("লাইব্রেরি" শৈলীর কোড) এর 99% অন্যভাবে না করে তবে ব্যতিক্রম না 'বৃত্তাকার।


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

@ স্টিভ জেসোপ, আমি সত্যিই জানি না আপনি আমার উত্তরটির চেতনার বিরুদ্ধে তর্ক করছেন বা আপনি এর ধারাবাহিকতায় চালিয়ে যাচ্ছেন কিনা। এটি বলেছিল, আমি কেবল গ্রাস করার পরামর্শ দিচ্ছি না null, তবে পদ্ধতির চুক্তিতে এটি খোলামেলাভাবে ঘোষণা করার জন্য এটি গ্রহণযোগ্য (বা নাও, ওপিতে যে কোনও সমাধান আসে তার উপর নির্ভর করে), এবং তারপরে কোনও ব্যতিক্রম নিক্ষেপ করা হবে কিনা এমন প্রশ্ন (বা না) নিজেই সমাধান করে।
এএনওই
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.