আমার পদ্ধতিগুলিতে খালি সংগ্রহগুলি গ্রহণ করা উচিত যা এগুলি পুনরাবৃত্তি করে?

40

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

public IEnumerable<TransformedNode> TransformNodes(IEnumerable<Node> nodes)
{
    foreach(var node in nodes)
    {
        // yadda yadda yadda
        yield return transformedNode;
    }
}

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

এখানে আমার যুক্তিটি হ'ল যদি কেউ এই পদ্ধতিটি কল করে থাকেন তবে তারা ডেটা প্রবেশের ইচ্ছা করে এবং ভুল পরিস্থিতিতে আমার পদ্ধতিতে কেবল একটি ফাঁকা সংগ্রহ করে দেয়।

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

c# exceptions collections parameters

— নিক উডেল
সূত্র

43

আপনি কি নিশ্চিতভাবেই অনুমান করেন যে "যদি কেউ এই পদ্ধতিটি কল করে তবে তারা ডেটা পাস করার মনস্থ করে" সঠিক? সম্ভবত তারা ফলাফলটি নিয়ে কাজ করার জন্য যা পেয়েছে কেবল তা পার করছে।

— স্পেসট্রকার

7

বিটিডাব্লু: আপনার "রূপান্তর" পদ্ধতিকে সাধারণত "মানচিত্র" বলা হয়, যদিও। নেট (এবং এসকিউএল, যেখানে নেট। নাম পেয়েছে) এটিকে সাধারণত "নির্বাচন" বলা হয়। "ট্রান্সফর্ম" হ'ল সি ++ এটিকে বলে, তবে এটি সাধারণ নাম নয় যা কেউ চিনতে পারে।

— জার্গ ডব্লু মিট্টাগ

25

সংগ্রহটি যদি হয় তবে আমি নিক্ষেপ করব nullযদি এটি খালি না থাকে।

— কোডসইনচাউস

21

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

— দ্য মায়ার

7

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

— মিথ্যা রায়ান

175

ইউটিলিটি পদ্ধতিতে খালি সংগ্রহ করা উচিত নয়। আপনার API ক্লায়েন্টরা এর জন্য আপনাকে ঘৃণা করবে।

একটি সংগ্রহ খালি থাকতে পারে; একটি "সংগ্রহ-যা-অবশ্যই-খালি নেই" খালি ধারণাটি কাজ করা আরও অনেক কঠিন কাজ।

একটি খালি সংগ্রহের রূপান্তরকরণের একটি সুস্পষ্ট ফলাফল রয়েছে: খালি সংগ্রহ। (এমনকি আপনি প্যারামিটার নিজেই ফিরে কিছু জঞ্জাল সংরক্ষণ করতে পারেন))

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

ইউটিলিটি পদ্ধতিগুলি সর্বদা তাদের ইনপুটগুলিতে উদার এবং তাদের ফলাফলগুলিতে রক্ষণশীল হতে চেষ্টা করতে হবে stri

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

— কিলিয়ান ফথ
সূত্র

14

+1 - (আমি পারলে আরও বেশি)। আমি এমনকি এতদূর যেতে পারে nullখালি সংগ্রহের মধ্যেও একত্রিত হতে। অন্তর্নিহিত সীমাবদ্ধতা সহ কাজগুলি একটি ব্যথা।

— টেলাস্টিন

6

"না আপনার উচিত নয়" ... সেগুলি গ্রহণ করা উচিত নয় বা একটি ব্যতিক্রম ছুঁড়ে দেওয়া উচিত নয়?

— বেন অ্যারসন

16

@ অ্যান্ডি - যদিও এটি ইউটিলিটি পদ্ধতিতে হবে না । তারা ব্যবসায়ের পদ্ধতি বা কিছু অনুরূপ কংক্রিট আচরণ হবে।

— টেলাস্টিন

38

আমি মনে করি না যে কোনও ফেরতের জন্য খালি সংগ্রহটি পুনর্ব্যবহার করা ভাল ধারণা। আপনি কেবলমাত্র একটি ক্ষুদ্র স্মৃতি সংরক্ষণ করছেন; এবং এর ফলে কলারের মধ্যে অপ্রত্যাশিত আচরণ হতে পারে। সামান্য সংক্ষেপিত উদাহরণ: Populate1(input); output1 = TransformNodes(input); Populate2(input); output2 = TransformNodes(input); যদি পপুলেট 1 সংগ্রহটি খালি ছেড়ে দেয় এবং আপনি এটি প্রথম ট্রান্সফর্ম নোড কলের জন্য ফিরিয়ে দেন, আউটপুট 1 এবং ইনপুট একই সংগ্রহ হবে এবং যখন পপুলটেন 2 কল করা হয়েছিল যদি এটি সংগ্রহে নোড রাখে না তবে আপনি নিজের দ্বিতীয়টি দিয়ে শেষ করবেন you' আউটপুট 2 ইনপুট সেট।

— ড্যান নীলি

6

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

— আন্দ্রেজ ডয়েল

26

আমি দুটি গুরুত্বপূর্ণ প্রশ্ন দেখছি যা এর উত্তর নির্ধারণ করে:

আপনার ফাংশন কোনও শূন্য সংগ্রহ ( নাল সহ ) পাস করার সময় অর্থবহ এবং যৌক্তিক কিছু ফিরিয়ে দিতে পারে ?
এই অ্যাপ্লিকেশন / গ্রন্থাগার / দলে সাধারণ প্রোগ্রামিং শৈলীটি কী? (বিশেষত, আপনি এফপি কেমন আছেন?)

1. অর্থপূর্ণ প্রত্যাবর্তন

মূলত, আপনি যদি অর্থবহ কিছু ফিরিয়ে দিতে পারেন তবে ব্যতিক্রম ছুঁড়বেন না। কলকারী ফলাফলটি মোকাবেলা করুন। সুতরাং যদি আপনার ফাংশন ...

সংগ্রহের উপাদানগুলির সংখ্যা গণনা করে, 0 ফেরান That এটি সহজ ছিল।
নির্দিষ্ট মানদণ্ডের সাথে মেলে এমন উপাদানগুলির অনুসন্ধান, একটি খালি সংগ্রহ ফিরিয়ে দেয়। কিছু ফেলবেন না দয়া করে। কলারের কাছে প্রচুর সংগ্রহের সংগ্রহ থাকতে পারে, যার কয়েকটি খালি, কিছু না। কলার যেকোন সংগ্রহে যে কোনও মিলের উপাদান চায়। ব্যতিক্রম কেবলমাত্র কলারের জীবনকে আরও শক্ত করে তোলে।
তালিকার সবচেয়ে বড় / ক্ষুদ্রতম / সেরা-ফিট-থেকে-মাপদণ্ডের সন্ধান করছে। উফ। শৈলীর প্রশ্নের উপর নির্ভর করে আপনি এখানে একটি ব্যতিক্রম ছুঁড়ে ফেলতে পারেন বা আপনি শূন্য হয়ে যেতে পারেন । আমি নালকে ঘৃণা করি (খুব এফপি ব্যক্তি) তবে এটি এখানে যুক্তিযুক্তভাবে আরও অর্থবহ এবং এটি আপনাকে নিজের কোডের মধ্যে অপ্রত্যাশিত ত্রুটির জন্য ব্যতিক্রমগুলি সংরক্ষণ করতে দেয়। যদি কলার নাল পরীক্ষা করে না, তবে মোটামুটি পরিষ্কার ব্যতিক্রম যাইহোক ফলাফল হতে পারে result তবে আপনি এটি তাদের কাছে ছেড়ে দিন।
সংগ্রহের নবম আইটেম বা প্রথম / শেষ এন আইটেমের জন্য জিজ্ঞাসা করুন। এটি এখনও ব্যতিক্রমের পক্ষে সেরা কেস এবং কলরটির পক্ষে বিভ্রান্তি ও অসুবিধার কারণ হতে পারে। একটি ক্ষেত্রে এখনো জন্য তৈরি করা যেতে পারে নাল যদি আপনি এবং আপনার দলের যে জন্য পরীক্ষণ, সমস্ত পূর্ববর্তী বিন্দু দেওয়া কারণের জন্য ব্যবহার করা হয়, কিন্তু এই একটি নিক্ষেপ জন্য এখনও সবচেয়ে বৈধ ক্ষেত্রে দেখা যায় DudeYou জানা YouShouldCheckTheSizeFirst ব্যতিক্রম। যদি আপনার স্টাইলটি আরও কার্যকরী হয়, তবে হয় আমার শৈলীর উত্তরটি বাতিল বা পড়ুন or

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

2. স্টাইল

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

এফ # এটি যেখানে সমস্ত দুর্দান্ত the নতুন বাচ্চারা এই জাতীয় জিনিসটি করে তবে সি # এই শৈলীতে সমর্থন করে না ।

TL; ড

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

— itsbruce
সূত্র

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

— gnasher729

1

না, সে কারণেই আমি বললাম 'সেরা ফিট' এবং 'ম্যাচস' নয়; শব্দগুচ্ছটি সর্বাধিক নিকটতম অনুমানকে বোঝায়, একটি সঠিক মিল নয়। বৃহত্তম / ক্ষুদ্রতম বিকল্পগুলির একটি ক্লু হওয়া উচিত। যদি কেবলমাত্র 'বেস্ট ফিট'-এর জন্য জিজ্ঞাসা করা হয়, তবে 1 বা ততোধিক সদস্য সহ যে কোনও সংগ্রহই কোনও সদস্যকে ফিরিয়ে দিতে সক্ষম হবে। যদি কেবলমাত্র একজন সদস্য থাকে তবে এটি সেরা ফিট।

— ব্রুস

1

বেশিরভাগ ক্ষেত্রে "নাল" ফেরান তারপরে ব্যতিক্রম ছুঁড়ে ফেলা আরও খারাপ। তবে খালি সংগ্রহ ফিরিয়ে দেওয়া অর্থপূর্ণ is

— ইয়ান

1

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

— itbruce

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

— djechlin

18

সর্বদা হিসাবে, এটি নির্ভর করে।

এটা আছে কোন ব্যাপার যে সংগ্রহটি ফাঁকা রয়েছে?
বেশিরভাগ সংগ্রহ-পরিচালনার কোড সম্ভবত "না" বলবে; সংগ্রহে শূন্য সহ যে কোনও আইটেম থাকতে পারে ।

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

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

— ফিল ডব্লু।
সূত্র

এবং যদি এটি সংগ্রহে কোনও আইটেম না থাকা অবৈধ হয়, তবে আদর্শিকভাবে যুক্তিটি একটি নয় java.util.Collection, তবে একটি কাস্টম com.foo.util.NonEmptyCollectionশ্রেণি হবে যা ধারাবাহিকভাবে এই আক্রমণকারীকে রক্ষা করতে পারে এবং আপনাকে শুরু করতে কোনও অবৈধ অবস্থায় প্রবেশ থেকে বিরত রাখতে পারে।

— আন্দ্রেজেজ ডয়েল

3

এই প্রশ্নটি ট্যাগ করা হয়েছে [সি #]

— নিক উডেল

@ নিকউডেল সি # কি অবজেক্ট ওরিয়েন্টেড প্রোগ্রামিং বা নেস্টেড নেমস্পেসের ধারণাকে সমর্থন করে না? তিল।

— জন ডিভোরাক

2

এটা করে. আমার মন্তব্যটি একটি স্পষ্টতা ছিল কারণ আন্ড্রেজ নিশ্চয়ই বিভ্রান্ত হয়ে পড়েছিলেন (অন্যথায় তারা কেন এই প্রশ্নটির উল্লেখ না করে এমন একটি ভাষার জন্য নাম স্পেস নির্দিষ্ট করার প্রয়াসে যাবে?)।

— নিক উডেল

"এটি নির্ভর করে" জোর দেওয়ার জন্য -1 "প্রায় অবশ্যই হ্যাঁ" এর চেয়ে বেশি। কোন রসিকতা নয় - ভুল জিনিসটি যোগাযোগ করা এখানে ক্ষতি করে।

— djechlin

11

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

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

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

— theMayer
সূত্র

আপনার সাহসী বক্তব্য সম্পূর্ণ সাধারণতার জন্য অত্যন্ত খারাপ পরামর্শ। আমি মনে করি এটি এখানে সত্য তবে আপনার এই পরিস্থিতি সম্পর্কে বিশেষ কী তা ব্যাখ্যা করতে হবে। (এটি সাধারণভাবে খারাপ পরামর্শ কারণ এটি নিঃশব্দ ব্যর্থতার প্রচার করে))

— ডিজেলিন

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

— দ্য মায়ার

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

— বিষয়টিতে যথার্থতা হারাতে

10

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

input.split("\\D")
.filterNot (_.isEmpty)
.map (_.toInt)
.filter (x => x >= 1000 && x <= 9999)

প্রথমে আপনি স্ট্রিংটিকে অ-অঙ্ক দ্বারা বিভক্ত করবেন, খালি স্ট্রিংগুলি ফিল্টার করুন, স্ট্রিংকে পূর্ণসংখ্যায় রূপান্তর করুন, তারপরে কেবল চার-অঙ্কের সংখ্যা রাখার জন্য ফিল্টার করুন। আপনার ফাংশনটি map (_.toInt)পাইপলাইনে থাকতে পারে ।

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

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

— কার্ল বিলেফেল্ট
সূত্র

অত্যন্ত কার্যকর উদাহরণের জন্য +1 (অন্যান্য ভাল উত্তরগুলির অভাব) cking

— djechlin

2

এই প্রশ্নটি আসলে ব্যতিক্রম সম্পর্কে। আপনি যদি সেভাবে দেখে থাকেন এবং খালি সংগ্রহটিকে বাস্তবায়নের বিশদ হিসাবে উপেক্ষা করেন তবে উত্তরটি সোজা ward

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

2) কোনও পদ্ধতি ব্যর্থতা সত্ত্বেও এগিয়ে যেতে সক্ষম হলে তার ব্যতিক্রম ধরা উচিত।

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

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

— jmoreno
সূত্র

1

পদ্ধতিটির নামকরণ করা হয়েছে TransformNodes। ইনপুট হিসাবে খালি সংগ্রহের ক্ষেত্রে, খালি সংগ্রহটি ফিরে পাওয়া প্রাকৃতিক এবং স্বজ্ঞাত এবং এটি গাণিতিক বোধকে প্রিফেক্ট করে তোলে।

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

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

— মনিকার চলমান ক্ষতি বন্ধ করুন
সূত্র

Maxকিছুই না প্রায়শই নেতিবাচক অসীম হয়।

— djechlin

0

আসুন পিছনে ফিরে আসি এবং একটি আলাদা উদাহরণ ব্যবহার করি যা মানগুলির অ্যারেটির গাণিতিক গড়কে গণনা করে।

যদি ইনপুট অ্যারেটি খালি (বা নাল) থাকে তবে আপনি কি কলারের অনুরোধটি যুক্তিসঙ্গতভাবে পূরণ করতে পারবেন? না, আপনার বিকল্পগুলি কি? ভাল, আপনি করতে পারেন:

উপস্থিত / প্রত্যাবর্তন / একটি ত্রুটি নিক্ষেপ এই শ্রেণীর ত্রুটির জন্য আপনার কোডবেসের কনভেনশনটি ব্যবহার করছেন।
নথি যে শূন্য হিসাবে একটি মান ফিরে আসবে
দস্তাবেজ যে একটি মনোনীত অবৈধ মান ফিরে আসবে (যেমন NaN)
দস্তাবেজ যে একটি যাদু মান ফিরে আসবে (যেমন টাইপের জন্য একটি মিনিট বা সর্বোচ্চ বা কিছু আশাবাদী-নির্দেশক মান)
ফলাফল অনির্ধারিত ঘোষণা
কর্মটি অপরিজ্ঞাপিত ঘোষণা করুন
প্রভৃতি

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

সুতরাং এটি আপনার লাইব্রেরিটি কীভাবে ত্রুটিযুক্ত অনুরোধগুলি এবং ব্যর্থতাগুলির অনুরোধগুলি পরিচালনা করে তা সংজ্ঞায়িত করতে পারে।

আপনার কোডটির জন্য এই শ্রেণীর ত্রুটিগুলি কীভাবে পরিচালনা করে তা সামঞ্জস্যপূর্ণ হওয়া খুব গুরুত্বপূর্ণ।

পরবর্তী বিভাগটি হল আপনার লাইব্রেরি কীভাবে বাজে অনুরোধগুলি পরিচালনা করে তা স্থির করা। পুলিশের অনুরূপ একটি উদাহরণ এ ফেরা - এর একটি ফাংশন যা নির্ধারণ করে একটি ফাইল একটি পাথ এ বিদ্যমান কিনা ব্যবহার যাক: bool FileExistsAtPath(String)। যদি ক্লায়েন্ট একটি খালি স্ট্রিং পাস করে তবে আপনি এই দৃশ্যটি কীভাবে পরিচালনা করবেন? কিভাবে একটি খালি বা নাল অ্যারে পাস void SaveDocuments(Array<Document>)? আপনার লাইব্রেরি / কোডবেসের জন্য সিদ্ধান্ত নিন এবং সামঞ্জস্য বজায় রাখুন। আমি এই কেসগুলির ত্রুটি বিবেচনা করতে এবং ক্লায়েন্টদের ত্রুটি হিসাবে পতাকাঙ্কিত করে বাজে অনুরোধগুলি করা থেকে বিরত রাখতে পারি (দৃ as়তার মাধ্যমে)। কিছু লোক দৃ idea়ভাবে সেই ধারণা / ক্রিয়াটির বিরুদ্ধে প্রতিরোধ করবে। আমি এই ত্রুটি সনাক্তকরণটি খুব সহায়ক বলে মনে করি। আপত্তিজনক প্রোগ্রামটির ভাল লোকেশন সহ - প্রোগ্রামগুলিতে সমস্যাগুলি সনাক্ত করার জন্য এটি খুব ভাল। প্রোগ্রামগুলি আরও পরিষ্কার এবং সঠিক (আপনার কোডবেসের বিবর্তন বিবেচনা করুন), এবং কিছু না করে এমন ক্রিয়াকলাপগুলির মধ্যে চক্র পোড়াবেন না। কোডটি এর চেয়ে ছোট / পরিষ্কারতর হয় এবং চেকগুলি সাধারণত সেই জায়গাগুলিতে ধাক্কা দেয় যেখানে সমস্যাটি প্রবর্তিত হতে পারে।

— জাস্টিন
সূত্র

6

আপনার শেষ উদাহরণের জন্য, বাজে কথা কী তা নির্ধারণ করা ফাংশনের কাজ নয়। সুতরাং, একটি খালি স্ট্রিং মিথ্যা ফিরে উচিত। প্রকৃতপক্ষে, যে সঠিক পন্থা File.Exists লাগে।

— দ্য মায়ার

@ rmayer06 এটি কাজ। রেফারেন্সড ফাংশনটি নাল, ফাঁকা স্ট্রিং, স্ট্রিংয়ে অবৈধ অক্ষরের জন্য চেকগুলি, স্ট্রিং ট্রানকেশন সম্পাদন করে, ফাইল সিস্টেম কল করার প্রয়োজন হতে পারে, এনভায়রনমেন্ট সম্পর্কে জিজ্ঞাসা করার প্রয়োজন হতে পারে ইত্যাদি those উচ্চ ব্যয়, এবং তারা অবশ্যই নির্ভুলতার লাইনগুলি ঝাপসা করে (আইএমও)। আমি প্রচুর if (!FileExists(path)) { ...create it!!!... }বাগ দেখেছি - যার মধ্যে অনেকগুলি কমিট করার আগেই ধরা পড়ত, যদি সঠিকতার লাইনগুলি অস্পষ্ট করা না হত।

— জাস্টিন

2

আমি কি আপনার সাথে একমত হব, যদি ফাংশনটির নাম ফাইল.ThrowExceptionIfPathIsInમાન્ય ছিল তবে তাদের ডান মনের মধ্যে কে এই জাতীয় ফাংশন বলবে?

— দ্য মায়ার

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

— সিএইচও

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

— সিএইচও

-3

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

— ক্লিমেন্ট মার্ক-আবা
সূত্র

ডিজাইনারের পক্ষে ধরে নেওয়া একেবারেই ভুল যে কোনও সংগ্রহ সবসময়ই পাস হয়ে যাবে এবং উল্লিখিত সংগ্রহের উপরে সরাসরি পুনরাবৃত্তি হবে, প্রাপ্ত

— তর্কটি

3

"ইনপুট প্রকারের বিস্তৃত পরিসর" এখানে অপ্রাসঙ্গিক দেখাচ্ছে। প্রশ্ন ট্যাগ করা হয় # , একটি দৃ strongly়ভাবে টাইপ করা ভাষা। অর্থাৎ কম্পাইলার গ্যারান্টী যে ইনপুট একটি সংগ্রহ

— মশা

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

— ক্লিমেন্ট মার্ক-আবা

1

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

— djechlin