ফাংশনগুলি কি নাল বা কোনও খালি বস্তুতে ফিরে আসবে?

209

ফাংশন থেকে ডেটা ফেরানোর সময় সেরা অনুশীলনটি কী । কোনও নাল বা একটি খালি জিনিস ফেরত দেওয়া কি ভাল? এবং কেন একজনের একে অপরকে করা উচিত?

এই বিবেচনা:

public UserEntity GetUserById(Guid userId)
{
     //Imagine some code here to access database.....

     //Check if data was returned and return a null if none found
     if (!DataExists)
        return null; 
        //Should I be doing this here instead? 
        //return new UserEntity();  
     else
        return existingUserEntity;
}

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

c#  .net  function  return-value 
— 7wp
সূত্র
4
আমার মনে হয় তুমি বোঝাতে চাইছ if (!DataExists)।
— সারা ভেসেল
107
এটি একটি স্থাপত্য সংক্রান্ত প্রশ্ন এবং পুরোপুরি উপযুক্ত perfectly ব্যবসায়িক সমস্যার সমাধানের চেষ্টা না করেই ওপির প্রশ্নটি বৈধ।
— জোসেফ ফেরিস
2
এই প্রশ্নের ইতিমধ্যে যথেষ্ট উত্তর দেওয়া হয়েছে। আমি মনে করি এটি একটি খুব আকর্ষণীয় প্রশ্ন।
— জন স্কিপিয়ন
'getUser ()' র বাতিল হওয়া উচিত। 'getCurrentUserInfo ()' বা 'getCurrentPerifications ()', OTOH আরও উদ্ঘাটনকারী প্রশ্ন হবে - তারা / অথবা যে কেউ লগ ইন করেছে তা নির্বিশেষে তাদের একটি নন-উত্তর শুল্ক দেওয়া উচিত
— থমাস
2
@ বার্গির অন্য কোনওটি সদৃশ নয়। আমার প্রথম জিজ্ঞাসা করা হয়েছিল, অক্টোবরে, অন্যটিকে ডিসেম্বরে পরে 3 টি পতঙ্গ জিজ্ঞাসা করা হয়েছিল। প্লাস অন্যটি একটি সংগ্রহ সম্পর্কে কথা বলে যা কিছুটা আলাদা।
— 7wp

উত্তর:

207

নাল ফিরিয়ে দেওয়া সাধারণত সেরা ধারণা হয় যদি আপনি কোনও ডেটা উপলভ্য নয় এমন নির্দেশ করে থাকেন।

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

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

— ljs
সূত্র
21
আপনার কোনও ব্যতিক্রম ছোঁড়া উচিত, সমস্যাটি গিলতে না পেরে এবং শূন্য হয়ে ফিরে আসা উচিত। সর্বনিম্ন, আপনার এটি লগ করা উচিত এবং তারপরে চালিয়ে যাওয়া উচিত।
— ক্রিস ব্যাল্যান্স
130
@ ক্রিস: আমি একমত নই যদি কোডটি স্পষ্টভাবে ডকুমেন্ট করে যে রিটার্নের মানটি নাল, তবে যদি আপনার মানদণ্ডের সাথে কোনও ফলাফল না পাওয়া যায় তবে নাল ফিরে দেওয়া পুরোপুরি গ্রহণযোগ্য। ব্যতিক্রম ছুঁড়ে ফেলা আপনার প্রথম পছন্দ হওয়া উচিত, আপনার প্রথম পছন্দ নয়।
— মাইক হুফার
12
@ ক্রিস: কোন ভিত্তিতে আপনি এটি সিদ্ধান্ত নিচ্ছেন? সমীকরণে লগিং যুক্ত করা অবশ্যই অত্যধিক বলে মনে হচ্ছে। গ্রাহক কোডটি সিদ্ধান্ত নিতে দিন - কোনও ব্যবহারকারীর ক্ষেত্রে কী করা উচিত - যদি কিছু হয়। আমার আগের মতামতের মতো, এমন কোনও মান প্রত্যাবর্তনের সাথে একেবারেই কোনও সমস্যা নেই যা সর্বজনীনভাবে "কোনও ডেটা নয়" হিসাবে সংজ্ঞায়িত।
— অ্যাডাম রবিনসন
17
আমি কিছুটা বিস্মিত হয়েছি যে একজন মাইক্রোসফ্ট বিকাশকারী বিশ্বাস করেন যে "রিটার্নিং নাল" "সমস্যাটি গ্রাস করার" সমতুল্য। যদি মেমরিটি পরিবেশন করে, ফ্রেমওয়ার্কে টন পদ্ধতি রয়েছে যেখানে কলারের অনুরোধের সাথে মেলে এমন কোনও কিছুই নেই যদি পদ্ধতিগুলি নাল হয় is এটি কি "সমস্যাটি গ্রাস করছে?"
— মাইক হাফার
5
সর্বশেষে তবে অন্তত তা নয় bool GetUserById(Guid userId, out UserEntity result)- যা আমি "নাল" রিটার্ন-মানকে পছন্দ করব এবং এটি ব্যতিক্রম ছোঁড়ার মতো চরম নয়। এটি সুন্দর- nullবিনামূল্যে কোড পছন্দ করে if(GetUserById(x,u)) { ... }।
— মার্সেল জ্যাকওয়ার্থ
44

এটি আপনার ক্ষেত্রে সবচেয়ে সার্থক করে তোলে তার উপর নির্ভর করে।

নাল ফিরতে কি বোঝা যায় না, যেমন "এই জাতীয় ব্যবহারকারীর উপস্থিতি নেই"?

বা কোনও ডিফল্ট ব্যবহারকারী তৈরি করার অর্থ কি? এটি সর্বাধিক অর্থপূর্ণ হয় যখন আপনি নিরাপদে ধরে নিতে পারেন যে কোনও ব্যবহারকারী যদি উপস্থিত থাকেন না, কলিং কোডটি যখন এটির জন্য জিজ্ঞাসা করে তখন একটি উপস্থিত থাকার ইচ্ছা করে।

অথবা যদি কলিং কোডটি কোনও অবৈধ আইডি সহ কোনও ব্যবহারকারীকে দাবী করে তবে একটি ব্যতিক্রম (একটি লা "ফাইলনটফাউন্ড") ছুঁড়ে ফেলা কি বোঝায়?

তবে - উদ্বেগ / এসআরপি দৃষ্টিভঙ্গির পৃথকীকরণ থেকে, প্রথম দুটি আরও সঠিক। এবং প্রযুক্তিগতভাবে প্রথমটি সবচেয়ে সঠিক (তবে কেবল একটি চুলের সাহায্যে) - গেট ইউজারবিআইআইডি কেবলমাত্র একটি জিনিসের জন্য ব্যবহারকারী হওয়া উচিত - ব্যবহারকারীকে পাওয়া। অন্য কিছু ফিরিয়ে দিয়ে তার নিজস্ব "ব্যবহারকারীর অস্তিত্ব নেই" কেস হ্যান্ডল করা এসআরপি লঙ্ঘন হতে পারে। একটি পৃথক চেকের পৃথকীকরণ - bool DoesUserExist(id)আপনি যদি কোনও ব্যতিক্রম ছুঁড়ে বেছে বেছে বেছে নেন তবে উপযুক্ত হবে would

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

সমস্ত পন্থাগুলি গ্রহণযোগ্য - এটি API / অ্যাপ্লিকেশনটির বৃহত্তর প্রসঙ্গের ভিত্তিতে কেবল নির্ভর করে।

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

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

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

যদি আপনার রিটার্নের ধরণটি একটি অ্যারে হয় তবে খালি অ্যারেটি ফিরুন নইলে ফিরে আসুন।

— দারিন দিমিত্রভ
সূত্র
একটি তালিকাতে 0 টি আইটেম কি এই মুহুর্তে নিযুক্ত করা তালিকার মতো?
— অ্যান্থনিডব্লু জোন্স
3
তালিকার 0 টি আইটেম একই রকম নয় null। এটি আপনাকে foreachউদ্বিগ্ন না করে স্টেটমেন্ট এবং লিনিক ক্যোয়ারিতে এটি ব্যবহার করতে দেয় NullReferenceException।
— দারিন দিমিত্রভ
5
আমি আশ্চর্য হয়েছি যে এটি আরও বেশি উত্সাহিত হয়নি। এটি আমার কাছে বেশ যুক্তিসঙ্গত গাইডলাইন বলে মনে হচ্ছে।
— শশী
ঠিক আছে, খালি পাত্রে নাল বস্তুর প্যাটার্নের একটি নির্দিষ্ট উদাহরণ। যা উপযুক্ত হতে পারে, আমরা তা বলতে পারি না।
— Deduplicator
একটি খালি অ্যারে ডেটা উপলব্ধ নয় রিটার্নিং সহজভাবে হয় ভুল । ডেটা উপলভ্য হওয়া এবং কোনও আইটেম থাকা এবং ডেটা উপলভ্য না হওয়া মধ্যে পার্থক্য রয়েছে। উভয় ক্ষেত্রে একটি খালি অ্যারে ফিরিয়ে দেওয়া কেসের ক্ষেত্রে তা জানা অসম্ভব করে তোলে। কেবল এটি করা যাতে আপনি ডেটা এমনকি উপস্থিত রয়েছে তা নির্বোধের বাইরে যাচাই না করেই পূর্বসূত্র ব্যবহার করতে পারেন - কলকারীকে ডেটা উপস্থিত রয়েছে কিনা তা পরীক্ষা করে দেখা উচিত এবং যদি কলারটি পরীক্ষা করে না পরীক্ষা করে ভাল হয় তবে এটি একটি বাগ উন্মোচিত করে ..
— মনিকা
12

নির্দিষ্ট চুক্তিটি ভেঙে গেলে আপনাকে একটি ব্যতিক্রম (কেবলমাত্র) নিক্ষেপ করা উচিত।
আপনার নির্দিষ্ট উদাহরণে, একটি পরিচিত আইডির উপর ভিত্তি করে ইউজারইটিটির জন্য জিজ্ঞাসা করা, এটি নিখোঁজ (মুছে ফেলা) ব্যবহারকারীরা যদি প্রত্যাশিত কেস হয় তবে এটি নির্ভর করবে। যদি তা হয় তবে ফিরে nullআসুন তবে এটি যদি প্রত্যাশিত কেস না হয় তবে একটি ব্যতিক্রম নিক্ষেপ করুন।
নোট করুন যে ফাংশনটি বলা UserEntity GetUserByName(string name)হলে এটি সম্ভবত নিক্ষেপ করবে না তবে নাল ফিরে আসবে। উভয় ক্ষেত্রে একটি খালি ইউজারএন্টি প্রত্যাবর্তন করা অসফল হবে।

স্ট্রিং, অ্যারে এবং সংগ্রহের জন্য পরিস্থিতি সাধারণত আলাদা হয়। আমি কিছু গাইডলাইন ফর্ম মনে করি যা এমএসের পদ্ধতিগুলিকে null'খালি' তালিকা হিসাবে গ্রহণ করা উচিত তবে শূন্য-দৈর্ঘ্যের পরিবর্তে সংগ্রহগুলি প্রদান করা উচিত null। স্ট্রিং জন্য একই। আপনি খালি অ্যারে ঘোষণা করতে পারেন তা নোট করুন:int[] arr = new int[0];

— হেনক হলটারম্যান
সূত্র
খুশি হয়ে আপনি উল্লেখ করেছেন যে স্ট্রিংগুলি আলাদা, যেহেতু আমি যখন খালি স্ট্রিং ফিরিয়ে আনব কিনা তা সিদ্ধান্ত নেওয়ার সময় গুগল আমাকে এটি দেখিয়েছিল।
— নওম্যানন
স্ট্রিং, সংগ্রহ এবং অ্যারে আলাদা নয় । এমএস যদি তাই বলে তবে এমএস ভুল। একটি খালি স্ট্রিং এবং নাল মধ্যে এবং একটি খালি সংগ্রহ এবং নাল মধ্যে পার্থক্য রয়েছে। উভয় ক্ষেত্রে প্রাক্তন বিদ্যমান ডেটা (আকার 0 এর) উপস্থাপন করে এবং পরবর্তীকালে তথ্যের অভাব উপস্থাপন করে। কিছু ক্ষেত্রে পার্থক্য খুব গুরুত্বপূর্ণ। উদাহরণস্বরূপ, যদি আপনি কোনও ক্যাশে কোনও এন্ট্রি সন্ধান করেন, আপনি ডেটা ক্যাশ করা হচ্ছে কিন্তু ফাঁকা থাকা এবং ডেটা ক্যাশে হচ্ছে না তার মধ্যে পার্থক্য জানতে চান যাতে আপনাকে অবশ্যই এটি অন্তর্নিহিত ডেটা উত্স থেকে আনতে হবে, যেখানে এটি নাও হতে পারে খালি।
— মনিকা
1
আপনি বিন্দু এবং প্রসঙ্গ মিস করবেন বলে মনে হচ্ছে। .Wher(p => p.Lastname == "qwerty")একটি খালি সংগ্রহ ফেরত দেওয়া উচিত, না null।
— হেন্ক হলটারম্যান
@ হেনকহোল্টারম্যান আপনি যদি পুরো সংগ্রহে অ্যাক্সেস করতে এবং কোনও ফিল্টার প্রয়োগ করতে সক্ষম হন যা সংগ্রহে কোনও আইটেম গ্রহণ করে না, একটি খালি সংগ্রহ সঠিক ফলাফল। তবে যদি পুরো সংগ্রহটি বিদ্যমান না থাকে তবে একটি খালি সংগ্রহ অত্যন্ত বিভ্রান্তিকর - নাল বা নিক্ষেপ করা পরিস্থিতি স্বাভাবিক বা ব্যতিক্রমী কিনা তার উপর নির্ভর করে সঠিক হবে। আপনি যে পরিস্থিতির বিষয়ে কথা বলছিলেন তা আপনার পোস্টে যোগ্যতা অর্জন করতে পারেনি (এবং এখন আপনি পূর্বের পরিস্থিতি সম্পর্কে কথা বলছেন) এবং ওপি যেহেতু পরবর্তী পরিস্থিতি সম্পর্কে কথা বলছিল, তাই আপনার সাথে আমার একমত হতে হবে না।
— ইনস্টল করুন মনিকা
11

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

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

যদি কোনও অনুপস্থিত ব্যবহারকারী ঠিক থাকে, (এই ফাংশনটি কল করার সম্ভাব্য স্বাভাবিক ফলাফলগুলির মধ্যে একটি) তারপরে একটি নাল ফেরান ...

সম্পাদনা: (অন্য উত্তরে অ্যাডামের মন্তব্যকে সম্বোধন করতে)

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

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

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

আমি ব্যক্তিগতভাবে শূন্য ফিরে আসব, কারণ আমি ডাল / রেপোজিটরি স্তরটি এইভাবে কাজ করব বলে আশা করব।

যদি এটি বিদ্যমান না থাকে, তবে কোনও জিনিস সফলভাবে কোনও জিনিস আনার জন্য নির্ধারিত হতে পারে এমন কোনও কিছু ফিরিয়ে দেবেন না, nullএখানে সুন্দরভাবে কাজ করে।

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

— অ্যালেক্স মুর
সূত্র
7

আমি ঝোঁক

  • return nullযদি অবজেক্ট আইডি উপস্থিত না থাকে তবে এটি উপস্থিত থাকা উচিত কিনা তা আগে জানা যায় না।
  • throwঅস্তিত্ব নেই যদি বস্তুর আইডি আছে যখন এটি করা উচিত বিদ্যমান।

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

Boolean TryGetSomeObjectById(Int32 id, out SomeObject o)
{
    if (InternalIdExists(id))
    {
        o = InternalGetSomeObject(id);

        return true;
    }
    else
    {
        return false;
    }
}

দ্বিতীয়ত:

SomeObject FindSomeObjectById(Int32 id)
{
    SomeObject o;

    return TryGetObjectById(id, out o) ? o : null;
}

তৃতীয়:

SomeObject GetSomeObjectById(Int32 id)
{
    SomeObject o;

    if (!TryGetObjectById(id, out o))
    {
        throw new SomeAppropriateException();
    }

    return o;
}
— জোহান জেরেল
সূত্র
আপনার অর্থ outনয়ref
— ম্যাট এলেন
@ ম্যাট: হ্যাঁ স্যার, আমি অবশ্যই করি! সংশোধন করা হয়েছে।
— জোহান জেরেল
2
সত্যই, এটি কেবলমাত্র এক-আকারের-ফিট সমস্ত উত্তর, এবং অতএব সম্পূর্ণ এবং একমাত্র সত্য! :) হ্যাঁ, এটি অনুমানগুলির উপর নির্ভর করে যার ভিত্তিতে পদ্ধতিটি চাওয়া হয়েছে ... সুতরাং প্রথমে এই অনুমানগুলি সাফ করুন এবং তারপরে উপরের ডান সংমিশ্রণটি চয়ন করুন। এখানে যাওয়ার জন্য খুব নীচে স্ক্রোল করতে হয়েছিল :) +100
— ইয়ার
এটি ব্যবহারের প্যাটার্ন বলে মনে হচ্ছে এটি বাদে এটি অ্যাসিঙ্ক পদ্ধতিগুলি সমর্থন করে না। আমি এই উত্তর রেফারেন্সড এবং Tuple লিটারেল সঙ্গে একটি ASYNC সমাধান যোগ -> এখানে
— ttugates
6

তবুও অন্য পদ্ধতির মধ্যে একটি কলব্যাক অবজেক্ট বা ডেলিগেট পাস করা জড়িত যা মানটির উপর কাজ করবে। যদি কোনও মান খুঁজে পাওয়া যায় না, কলব্যাক কল করা হয় না।

public void GetUserById(Guid id, UserCallback callback)
{
    // Lookup user
    if (userFound)
        callback(userEntity);  // or callback.Call(userEntity);
}

আপনি যখন আপনার সমস্ত কোডে নাল চেকগুলি এড়াতে চান এবং যখন কোনও মান খুঁজে পাওয়া যায় না তখন এটি ত্রুটি নয় This আপনার যদি কোনও বিশেষ প্রসেসিংয়ের প্রয়োজন হয় তবে যখন কোনও জিনিস পাওয়া না যায় তার জন্য আপনি কলব্যাক সরবরাহ করতে পারেন।

public void GetUserById(Guid id, UserCallback callback, NotFoundCallback notFound)
{
    // Lookup user
    if (userFound)
        callback(userEntity);  // or callback.Call(userEntity);
    else
        notFound(); // or notFound.Call();
}

একটি একক অবজেক্ট ব্যবহার করে একই পদ্ধতির মতো দেখতে পাওয়া যেতে পারে:

public void GetUserById(Guid id, UserCallback callback)
{
    // Lookup user
    if (userFound)
        callback.Found(userEntity);
    else
        callback.NotFound();
}

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

— আঙ্গুরের ছিরড়া
সূত্র
মজাদার. আপনি যখন প্রতিনিধিদের সম্পর্কে কথা বলতে শুরু করলেন, আমি ততক্ষনে ভাবতে শুরু করি যে ল্যাম্বডা ভাবটি এখানে ব্যবহার করা যেতে পারে।
— 7wp
হা! আমি এটি বুঝতে পারছি, সি # 3.0 এবং আপের ল্যাম্বদা সিনট্যাক্সটি মূলত বেনাম প্রতিনিধিদের জন্য সিনট্যাকটিক চিনি। একইভাবে জাভাতে, দুর্দান্ত ল্যাম্বদা বা বেনামে প্রতিনিধি সিনট্যাক্স ব্যতীত আপনি কেবল একটি বেনাম শ্রেণি তৈরি করতে পারেন। এটি কিছুটা কুরুচিপূর্ণ তবে সত্যই কার্যকর হতে পারে। আমি এই দিন অনুমান, আমার C # এর উদাহরণ Func <UserEntity> ব্যবহৃত পারে করে থাকেন বা এটি ভালো কিছু একটি নামাঙ্কিত প্রতিনিধি পরিবর্তে, কিন্তু শেষ C # এর প্রকল্প আমি ছিল এখনও সংস্করণ 2. ব্যবহার করছিলেন
— মার্ক
+1 আমি এই পদ্ধতির পছন্দ করি। যদিও একটি সমস্যা হ'ল এটি প্রচলিত নয় এবং কোডবেসের জন্য প্রবেশের ক্ষেত্রে বাধা সামান্য বাড়িয়ে তোলে।
— টিমক্সলে
4

আমরা CSLA.NET ব্যবহার করি এবং এটি এমন দৃষ্টিভঙ্গি নেয় যে একটি ব্যর্থ ডেটা আনতে কোনও "খালি" বস্তুটি ফিরিয়ে দেওয়া উচিত। এটি আসলে বেশ বিরক্তিকর, কারণ এটি obj.IsNewচেয়ে বরং পরীক্ষা করার কনভেনশন দাবি করে obj == null।

পূর্ববর্তী পোস্টার হিসাবে উল্লিখিত হয়েছে, নাল রিটার্ন মানগুলি সরাসরি কোডটি ব্যর্থ করে দেবে, খালি বস্তুগুলির কারণে স্টিলথ সমস্যার সম্ভাবনা হ্রাস করবে।

ব্যক্তিগতভাবে, আমি nullআরও মার্জিত বলে মনে করি ।

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

আপনি এটি দ্বারা পরিচালনা করতে পারেন:

যদি (User.Exists (id)) {
  this.User = User.Fetch (id);
} অন্য {
  Response.Redirect ( "~ / notfound.aspx");
}

... তবে এটি প্রতিবার ডাটাবেসে একটি অতিরিক্ত কল যা উচ্চ ট্র্যাফিক পৃষ্ঠাগুলিতে কোনও সমস্যা হতে পারে। যেখানে:

this.User = User.Fetch (id);

যদি (this.User == নাল) {
  Response.Redirect ( "~ / notfound.aspx");
}

... শুধুমাত্র একটি কল প্রয়োজন।

— কিথ উইলিয়ামস
সূত্র
4

আমি পছন্দ করি null, যেহেতু এটি নাল-কোয়েলসিং অপারেটর ( ??) এর সাথে সামঞ্জস্যপূর্ণ ।

— কেউ কিছু
সূত্র
4

আমি একটি ফাঁকা অবজেক্টের পরিবর্তে নাল ফিরে বলব।

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

এটি আমি নিয়ম অনুসরণ করি:

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

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

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

— জ্যাকব ম্যাটিসন
সূত্র
আপনি এখানে যে যুক্তি দিচ্ছেন তা +1 আমি জিজ্ঞাসা করছিলাম, এ কারণেই এই বিষয়ে অন্যদের মতামত কী হবে তা দেখার জন্য আমি প্রশ্ন পোস্ট করেছি
— 7wp
3

এই ক্ষেত্রে সেরাটি "নাল" প্রত্যাবর্তন করে এমন ক্ষেত্রে এরকম কোনও ব্যবহারকারী নেই। আপনার পদ্ধতিটি স্থিরও করুন।

সম্পাদনা:

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

— Kamarey
সূত্র
আমি জিজ্ঞাসা করতে পারি কেন আমি আমার পদ্ধতিটি স্থির করতে চাই? আমি যদি নির্ভরতা ইনজেকশন ব্যবহার করতে চাই?
— 7
ঠিক আছে এখন আমি আপনার যুক্তি পেতে। তবে আমি সংগ্রহস্থলের প্যাটার্নটির সাথে লেগে আছি এবং আমি আমার সংগ্রহস্থলগুলির জন্য নির্ভরতা ইনজেকশন ব্যবহার করতে পছন্দ করি তাই আমি স্থির পদ্ধতি ব্যবহার করতে পারি না। তবে নাল
— ফেরানোর
3

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

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

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

আমাদের ব্যবসায়িক বিষয়গুলিতে আমাদের কাছে 2 টি প্রধান পদ্ধতি রয়েছে:

প্রসঙ্গে জিনিসগুলিকে সহজ রাখতে বা আপনি প্রশ্ন করেন যে তারা হবেন:

// Returns null if user does not exist
public UserEntity GetUserById(Guid userId)
{
}

// Returns a New User if user does not exist
public UserEntity GetNewOrExistingUserById(Guid userId)
{
}

সুনির্দিষ্ট সত্তা পাওয়ার সময় প্রথম পদ্ধতিটি ব্যবহৃত হয়, দ্বিতীয় পৃষ্ঠাগুলি বিশেষত ওয়েব পৃষ্ঠাগুলিতে সত্তা যুক্ত বা সম্পাদনার সময় ব্যবহৃত হয়।

এটি আমাদের ব্যবহৃত হয়েছে যেখানে তারা ব্যবহৃত হয় সেই প্রসঙ্গে উভয় বিশ্বের সেরা থাকতে সক্ষম করে।

— মার্ক রেডম্যান
সূত্র
3

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

জাভা ব্যবহার করে, আমাদেরকে assert exists(object) : "You shouldn't try to access an object that doesn't exist";"পূর্বশর্ত" প্রকাশ করার জন্য যে কোনও পদ্ধতির শূন্যতা ফিরে আসতে পারে তার শুরুতে একটি যুক্ত করতে বলা হয় (ইংরেজিতে শব্দটি কী তা আমি জানি না)।

আইএমও এটি ব্যবহার করা সত্যই সহজ নয় তবে এটিই আমি ব্যবহার করছি, আরও ভালর জন্য অপেক্ষা করছি।

— Saend
সূত্র
1
আপনার উত্তরের জন্য আপনাকে ধন্যবাদ। তবে এটি উপস্থিত থাকলে প্রথমে যাচাই করার ধারণাটি আমি অপছন্দ করি। কারণটি হ'ল ডেটাবেজে একটি অতিরিক্ত ক্যোয়ারী উত্পন্ন করে। একটি অ্যাপ্লিকেশনটিতে যা লক্ষ লক্ষ লোক একদিনে অ্যাক্সেস করে তা নাটকীয় পারফরম্যান্স হারাতে পারে।
— 7wp
1
একটি সুবিধা হ'ল অস্তিত্বের জন্য চেকটি যথাযথভাবে বিমূর্ত: যদি (ইউজারএক্সবাদীরা) সমস্যা ডোমেনের নিকটে কিছুটা বেশি পঠনযোগ্য, কম 'কম্পিউটারি' হয় তবে: (ইউজার == নাল)
— টিমক্সলে
এবং আমি যুক্তি দিয়ে বলব যে 'যদি (x == নাল)' দশকের পুরানো প্যাটার্ন এটি যদি আপনি এটি আগে না দেখে থাকেন তবে আপনি খুব দীর্ঘ সময় ধরে কোডটি লিখে থাকেন নি (এবং এটি যেমন আছে তেমন অভ্যস্ত হওয়া উচিত) লক্ষ লক্ষ লাইন কোড)। "Computery"? আমরা ডাটাবেস অ্যাক্সেস সম্পর্কে কথা বলছি ...
— লয়েড সারজেন্ট
3

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

public Option<UserEntity> GetUserById(Guid userId)
{
 //Imagine some code here to access database.....

 //Check if data was returned and return a null if none found
 if (!DataExists)
    return Option<UserEntity>.Nothing; 
 else
    return Option.Just(existingUserEntity);
}

এবং এটি ব্যবহার করা হবে:

Option<UserEntity> result = GetUserById(...);
if (result.IsNothing()) {
    // deal with it
} else {
    UserEntity value = result.GetValue();
}

দুর্ভাগ্যক্রমে, প্রত্যেকে নিজের মতো করে এই ধরণের রোল দেয় বলে মনে হয়।

— yatima2975
সূত্র
2

আমি সাধারণত নাল ফিরে। এটি ব্যাতিক্রম ছুঁড়ে না ফেলে এবং পুরো জায়গা জুড়ে প্রচুর চেষ্টা / ধরা ব্যবহার না করে কিছু স্ক্রু হয়েছে কিনা তা সনাক্ত করার জন্য এটি একটি দ্রুত এবং সহজ ব্যবস্থা সরবরাহ করে।

— নাম কি
সূত্র
2

সংগ্রহের ধরণের জন্য আমি একটি খালি সংগ্রহ ফিরিয়ে আনব, অন্য সমস্ত প্রকারের জন্য আমি নলঅবজেক্ট নিদর্শনগুলি ব্যবহার করতে পছন্দ করি যা প্রত্যাবর্তন টাইপের মতো একই ইন্টারফেস প্রয়োগ করে object নিদর্শন চেক আউট লিঙ্ক পাঠ্য সম্পর্কে বিশদ জন্য

নুলবজেক্ট প্যাটার্নটি ব্যবহার করে এটি হবে: -

public UserEntity GetUserById(Guid userId)

{// ডাটাবেস অ্যাক্সেস করতে এখানে কিছু কোড কল্পনা করুন .....

 //Check if data was returned and return a null if none found
 if (!DataExists)
    return new NullUserEntity(); //Should I be doing this here instead? return new UserEntity();  
 else
    return existingUserEntity;

}

class NullUserEntity: IUserEntity { public string getFirstName(){ return ""; } ...}
— বিক্রম নায়ক
সূত্র
2

অন্যরা যা বলেছে তা করণীয়কে ...

ব্যতিক্রম ব্যতিক্রমী পরিস্থিতিতে

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

অন্যদিকে, যদি আমি প্রত্যাশা করি যে আমার প্যারামিটারটি একটি প্রাথমিক কীটি প্রতিবিম্বিত করবে এবং আমার কেবল এক সারি ফিরে পাওয়া উচিত , যদি আমি একাধিক পিছনে পাই তবে আমি একটি ব্যতিক্রম ছুঁড়ে ফেলি। 0 নাল ফিরে ফেরা ঠিক আছে, 2 হয় না।

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

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

— জিম এল
সূত্র
2

আমার সিউডো-পিএইচপি / কোডটি ক্ষমা করুন।

আমি মনে করি এটি সত্যই ফলাফলের ব্যবহারের উপর নির্ভর করে।

যদি আপনি রিটার্ন মানটি সম্পাদনা / পরিবর্তন করতে চান এবং এটি সংরক্ষণ করেন, তবে একটি খালি বস্তুটি ফিরিয়ে দিন। এইভাবে, আপনি নতুন বা বিদ্যমান অবজেক্টে ডেটা পপুলেটে একই ফাংশনটি ব্যবহার করতে পারেন।

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

উদাহরণ:

function saveTheRow($prim_key, $data) {
    $row = getRowByPrimKey($prim_key);

    // Populate the data here

    $row->save();
}

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

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

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

উদাহরণ:

function displayData($row_id) {
    // Logging of the error would happen in this function
    $row = getRow($row_id);
    if($row === null) {
        // Handle the error here
    }

    // Do stuff here with data
}

function getRow($row_id) {
 $row = null;
 try{
     if(!$db->connected()) {
   throw excpetion("Couldn't Connect");
  }

  $result = $db->query($some_query_using_row_id);

  if(count($result) == 0 ) {
   throw new exception("Couldn't find a record!");
  }

  $row = $db->nextRow();

 } catch (db_exception) {
  //Log db conn error, alert admin, etc...
  return null; // This way I know that null means an error occurred
 }
 return $row;
}

এটাই আমার সাধারণ নিয়ম। এটি এ পর্যন্ত ভাল কাজ করেছে।

2

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

নাল-ফিরিয়ে দেওয়ার পদ্ধতিগুলি থেকে নিক্ষেপ করার পদ্ধতিগুলির মধ্যে পার্থক্য করার জন্য একটি ভাল পদ্ধতি হ'ল আপনার দলে একটি কনভেনশন সন্ধান করা: যেগুলি পাওয়ার মতো কিছু না থাকলে তারা "কিছু পেয়ে যায়" বলে এমন পদ্ধতিগুলি একটি ব্যতিক্রম ছুঁড়ে ফেলা উচিত। নাল ফিরে আসতে পারে এমন পদ্ধতিগুলির নাম আলাদাভাবে দেওয়া যেতে পারে, পরিবর্তে সম্ভবত "সন্ধান করুন ..."।

— মার্ক উইটকে
সূত্র
+1 আমি প্রোগ্রামারকে সিগন্যাল করার জন্য একটি অভিন্ন নামকরণ কনভেনশন ব্যবহার করার ধারণাটি পছন্দ করি যাতে সেই ফাংশনটি কীভাবে গ্রাস করতে হয়।
— 7wp
1
হঠাৎ আমি বুঝতে পারি যে এটি লিনিক্যু কি করে: ফার্স্ট (...) বনাম ফার্স্টআরডিফল্ট (...) বিবেচনা করুন
— মার্ক উইটকে
2

যদি প্রত্যাশিত জিনিসটি এমন কিছু হয় যা পুনরাবৃত্তি হতে পারে তবে আমি একটি খালি বস্তুটি ফিরিয়ে দেব, যাতে আমাকে প্রথমে শূন্যতার জন্য পরীক্ষা করতে হবে না।

উদাহরণ:

bool IsAdministrator(User user)
{
    var groupsOfUser = GetGroupsOfUser(user);

    // This foreach would cause a run time exception if groupsOfUser is null.
    foreach (var groupOfUser in groupsOfUser) 
    {
        if (groupOfUser.Name == "Administrators")
        {
            return true;
        }
    }

    return false;
}
— জান আগারার্ড
সূত্র
2

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

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

এটি কলারকে ফলাফলটি সংগ্রহের পাইপলাইনের মতো মার্টিন ফাউলারের সংগ্রহ পাইপলাইনের মতো বিভিন্ন কৌশল প্রয়োগ করতে দেয় ।

এখানে অন্য উদাহরণ যেখানে নুলের পরিবর্তে বিকল্পটি কোডের জটিলতা হ্রাস করতে ব্যবহৃত হয়: সাইক্লোমেটিক জটিলতা কীভাবে হ্রাস করবেন: বিকল্প কার্যকারিতা প্রকার

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

আরও কষানোর জন্য মাংস: আসুন বলি যে আমার ডাল কিছু লোকের পরামর্শ অনুসারে গেটপারসনবাইআইডি-র জন্য একটি ন্যূন ফিরিয়ে দেয়। আমার (বরং পাতলা) বিএলএল কী করবে যদি এটি একটি NUL পায়? সেই নুলটি পাস করুন এবং শেষ ভোক্তাকে এটি সম্পর্কে উদ্বিগ্ন হতে দিন (এই ক্ষেত্রে, একটি এএসপি.নেট পৃষ্ঠা)? কীভাবে বিএলএল ব্যতিক্রম নিক্ষেপ করবেন?

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

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

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

আমি এই পোস্টটি উপভোগ করছি, "এটি নির্ভর করে" পরিস্থিতিগুলির জন্য প্রচুর ভাল পরামর্শ :-)

— মাইক কিংসকোট
সূত্র
এবং অবশ্যই, আজ আমি এমন একটি দৃশ্যের মুখোমুখি হয়েছি যেখানে আমি আমার বিএলএল থেকে নুল ফেরত যাব ;-) যে বলেছিল, আমি এখনও একটি ব্যতিক্রম ছুঁড়ে ফেলতে পারি এবং আমার গ্রাসকারী ক্লাসে চেষ্টা / ধরতে পারি তবে আমার এখনও সমস্যা আছে : আমার গ্রাহক শ্রেণি কীভাবে চেষ্টা / ধরা ব্যবহার করতে জানে, অনুরূপ তারা কীভাবে NULL পরীক্ষা করতে জানে?
— মাইক কিংসকোট
আপনি ডকুমেন্ট করতে পারেন যে একটি পদ্ধতি @ থ্রো ডকটাগের মাধ্যমে একটি ব্যতিক্রম ছুঁড়েছে এবং আপনি এই সত্যটি নথিবদ্ধ করেছেন যে এটি @ রিটার্ন ডক্ট্যাজে নালাগুলি ফিরে আসতে পারে।
— টিমোকসলে
1

আমি মনে করি আপনার কোড-বেসের স্বাস্থ্যের জন্য ফাংশনগুলি বাতিল হওয়া উচিত নয়। আমি কয়েকটি কারণ সম্পর্কে চিন্তা করতে পারি:

নাল রেফারেন্সের সাথে চিকিত্সার জন্য প্রচুর পরিমাণে ক্লজ থাকবে if (f() != null)।

কী null, এটি একটি গৃহীত উত্তর বা সমস্যা? নাল একটি নির্দিষ্ট অবজেক্টের জন্য একটি বৈধ রাষ্ট্র? (কল্পনা করুন যে আপনি কোডের ক্লায়েন্ট)। মানে সমস্ত রেফারেন্সের ধরণগুলি নাল হতে পারে, তবে সেগুলি করা উচিত?

রয়ে nullঝুলন্ত কাছাকাছি প্রায় সবসময় যেমন আপনার কোড-বেস বৃদ্ধি সময়ে সময়ে কয়েক অপ্রত্যাশিত NullRef ব্যতিক্রম দেব।

ফাংশনাল প্রোগ্রামিং থেকে কিছু সমাধান রয়েছে tester-doer patternবা বাস্তবায়ন হচ্ছে option type।

— গ্যাব্রিয়েল পি।
সূত্র
0

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

যদি (নাল! = (পরিবর্তনশীল = ফাংশন (যুক্তি ...))) {

সুতরাং আপনি একটি ভেরিয়েবলের মান (বা নাল) পাবেন এবং ফলাফল একবারে। এই প্রবাদটি কি ভুলে গেছে? কেন?

— কোন বোধগম্য
সূত্র
0

আমি এখানে বেশিরভাগ পোস্টের সাথে একমত, যা ঝোঁক null।

আমার যুক্তিটি হ'ল নন-নোলযোগ্য বৈশিষ্ট্য সহ একটি খালি বস্তু উত্পন্ন করার ফলে বাগগুলি হতে পারে। উদাহরণস্বরূপ, কোনও int IDসম্পত্তি সহ কোনও সত্তার প্রাথমিক মান থাকবে ID = 0যা সম্পূর্ণ বৈধ মান। সেই অবজেক্টটি যদি কোনও কোনও পরিস্থিতিতে ডাটাবেসে সংরক্ষণ করা হয় তবে এটি খারাপ জিনিস হবে।

পুনরাবৃত্তকারী সহ যে কোনও কিছুর জন্য আমি সর্বদা খালি সংগ্রহটি ব্যবহার করতাম । কিছুটা এইরকম

foreach (var eachValue in collection ?? new List<Type>(0))

আমার মতে কোড গন্ধ হয়। সংগ্রহের বৈশিষ্ট্যগুলি কখনই শূন্য হওয়া উচিত নয়।

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

ব্যতিক্রম এবং কার্যকারিতা সম্পর্কিত আপনার প্রশ্ন সম্পর্কিত: আপনি যদি কোনও ব্যতিক্রম যা আপনার প্রোগ্রামের যুক্তিতে সম্পূর্ণরূপে পরিচালনা করতে না পারেন তা ছুঁড়ে ফেললে আপনার প্রোগ্রামটি যা কিছু করছে তা আপনাকে কিছুটা হলেও বাতিল করতে হবে, এবং ব্যবহারকারীকে তার যা করা হয়েছে তা পুনরায় করতে বলবেন। সেক্ষেত্রে একজনের পারফরম্যান্স পেনাল্টি catchহ'ল আপনার উদ্বেগের মধ্যে সবচেয়ে কম - ব্যবহারকারীর কাছে জিজ্ঞাসা করা হ'ল ঘরের হাতি (যার অর্থ পুরো ইউআইকে পুনরায় উপস্থাপন করা, বা ইন্টারনেটের মাধ্যমে কিছু HTML পাঠানো) sending সুতরাং যদি আপনি " ব্যতিক্রমগুলির সাথে প্রোগ্রাম ফ্লো " এর অ্যান্টি-প্যাটার্নটি অনুসরণ না করেন তবে বিরক্ত করবেন না, যদি তা বোঝা যায় তবে কেবল একটি নিক্ষেপ করুন। এমনকি "বৈধকরণ ব্যতিক্রম" এর মতো সীমান্তরেখার ক্ষেত্রেও পারফরম্যান্স আসলেই কোনও সমস্যা নয়, যেহেতু আপনাকে কোনও ক্ষেত্রেই ব্যবহারকারীকে আবার জিজ্ঞাসা করতে হবে।

— অলিভার শিমার
সূত্র
0

একটি অ্যাসিনক্রোনাস ট্রাইগেট প্যাটার্ন:

সমলয় পদ্ধতি জন্য, আমি বিশ্বাস করি @Johann Gerell এর উত্তর হল প্যাটার্ন সব ক্ষেত্রেই ব্যবহার করতে।

তবে outপ্যারামিটার সহ ট্রাইগেট প্যাটার্ন অ্যাসিঙ্ক পদ্ধতিগুলির সাথে কাজ করে না।

সি # 7 এর টিপল লিটারালসের সাহায্যে আপনি এখন এটি করতে পারেন:

async Task<(bool success, SomeObject o)> TryGetSomeObjectByIdAsync(Int32 id)
{
    if (InternalIdExists(id))
    {
        o = await InternalGetSomeObjectAsync(id);

        return (true, o);
    }
    else
    {
        return (false, default(SomeObject));
    }
}
— ttugates
সূত্র
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.