যদি নাল আশা না করে তবে কি নাল পরীক্ষা করা উচিত?


113

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

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

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

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

আপনি কোন অনুশীলনটি অনুসরণ করেন এবং উভয় পদ্ধতির পক্ষে বা বিপক্ষে আপনার যুক্তিগুলি কী?

হালনাগাদ:

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

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

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


62
ফক্স মুলদার নীতি: কেউ বিশ্বাস করবেন না।
ইন্নিস

14
@ ইয়ানিসরিজোস: নীতিটি একটি ভাল - এটি এতটা ভাল যে জাভা এবং সি # এর স্রষ্টারা ভাষা চলমান সময়ের পরিবেশটিকে স্বয়ংক্রিয়ভাবে এটি করতে দেয়। সুতরাং সাধারণত সেই ভাষাগুলিতে আপনার কোডের সর্বত্র নাল জন্য স্পষ্ট চেক করার প্রয়োজন নেই ।
ডক ব্রাউন


আমি tmadmers উত্তর সাথে একমত। আমি বিশ্বাস করি নাল পরীক্ষা করা ঠিক ভুল কারণ আপনার এটিকে পরিচালনা করার কোনও যুক্তিসঙ্গত উপায় নেই। তবে আপনার দৃশ্যে আপনি ব্যর্থ কোনও বিভাগ পরিচালনা করতে পারবেন যেমন কোনও ব্যবহারকারীকে বৈধতা দেওয়া (বা মন্তব্য করা বা এটি যাই হোক না কেন) এবং "ওহ কোনও ত্রুটি ঘটেনি" বাক্সটি থাকা। আমি ব্যক্তিগতভাবে আমার অ্যাপ্লিকেশনটিতে সমস্ত ব্যতিক্রম লগইন করেছি এবং 404s এবং সংযোগ অপ্রত্যাশিতভাবে বন্ধ হিসাবে কিছু ব্যতিক্রম ফিল্টার আউট

2
assert(foo != null, "foo is web control within the repeater, there's no reason to expect it to be null, etc, etc...");
zzzzBov

উত্তর:


105

nullআপনার রানটাইমটি ব্যতিক্রমী হওয়া উচিত কিনা তা পরীক্ষা করা উচিত কিনা প্রশ্নটি এতটা নয় ; এটি আপনার যেমন অপ্রত্যাশিত পরিস্থিতিতে প্রতিক্রিয়া জানানো উচিত।

আপনার বিকল্পগুলি হ'ল:

  • একটি জেনেরিক ব্যতিক্রম নিক্ষেপ করুন ( NullReferenceException) এবং এটি বুদবুদ হতে দিন; যদি আপনি nullনিজে চেক না করেন তবে স্বয়ংক্রিয়ভাবে এটি ঘটে।
  • একটি কাস্টম ব্যতিক্রম ছুঁড়ে যা সমস্যার উচ্চ স্তরে বর্ণনা করে; এটি nullচেকের মধ্যে নিক্ষেপ করে বা একটি ধরা পড়ে NullReferenceExceptionএবং আরও নির্দিষ্ট ব্যতিক্রম ছুঁড়ে ফেলে অর্জন করা যেতে পারে ।
  • উপযুক্ত ডিফল্ট মান স্থির করে পুনরুদ্ধার করুন।

কোন সাধারণ নিয়ম নেই যেটি সবচেয়ে ভাল সমাধান। ব্যক্তিগতভাবে, আমি বলব:

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

1
@ স্টিলগার এন্ডুয়েসারের জন্য কোনও পার্থক্য নেই। developper মত কোনো নির্দিষ্ট ব্যতিক্রম "ডাটাবেসের-সার্ভার যোগাযোগ করা সম্ভব নয়" জন্য যে, "নাল পয়েন্টার excepteion" আরো স্বজ্ঞাত
k3b

32
কঠোর এবং তাড়াতাড়ি ব্যর্থ হওয়ার অর্থ হ'ল লাইনটি আরও সূক্ষ্মভাবে ভুল হওয়ার ঝুঁকির কম ঝুঁকি রয়েছে, ভুল প্রমাণীকরণ, দূষিত ডেটা যেমন স্টোরেজ, তথ্য ফাঁস এবং অন্যান্য মজাদার বিষয়গুলিতে স্থির থাকে।
লার্স ভিক্লুন্ড

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

3
tmadmers ঠিক ঠিক। "অবজেক্টের কোনও উল্লেখের জন্য সেট করা হয়নি" অবজেক্টের রেফারেন্স "সবচেয়ে ফ্রিকোয়েন্সি সহ আমি দেখতে পাই সবচেয়ে বিরক্তিকর ব্যতিক্রম। আমি এটির পরিবর্তে প্যারামিটারের নাম সহ একটি আর্গুমেন্টনাল এক্সসেপশন বা একটি কাস্টম ব্যতিক্রম কিনা তা একটি নির্দিষ্ট ব্যতিক্রম দেখতে পাচ্ছি "ব্যবহারকারীর TK421 এর জন্য কোনও পোস্ট রেকর্ড বিদ্যমান নেই" "
শন চেজ

1
@ k3b শেষ ব্যবহারকারীর জন্যও, "ডাটাবেস-সার্ভার পৌঁছনীয় নয়" খুব সহায়ক। কমপক্ষে, যে কোনও প্রান্ত-ব্যবহারকারীর পক্ষে সাধারণ সমস্যা সম্পর্কে কিছুটা ধারণা রয়েছে - এটি বগি সফ্টওয়্যার সম্পর্কে রাগ না করে রাউটারটিকে পুনরায় চালু করার প্রয়োজন খুঁজে পেতে পারে a
জুলিয়া হ্যাওয়ার্ড

58

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


পরিবর্তে ArgumentNullException, এক কোড চুক্তি ব্যবহার করা উচিত, (যদি না এটি 2010-পূর্বের উত্স কোড যা কোড চুক্তিগুলিকে সমর্থন করে না)।
আর্সেনি মরজেনকো

আমি আপনার সাথে একমত. নালটি যদি প্রত্যাশিত না হয় তবে এটি অদ্ভুত উপায়ে পরিচালনা করা উচিত নয় তবে কেবল রিপোর্ট করা হয়েছে।
জর্জিও

9
যদি আমি প্রশ্নটি সঠিকভাবে পড়ে, ArgumentNullExceptionনাল মানটিকে "হ্যান্ডলিং" হিসাবে গণনা নিক্ষেপ করে : এটি পরে নাল রেফারেন্স ব্যতিক্রমকে বাধা দেয়
কুতুলু মাইক 21

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

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

35

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

অবশ্যই, এই নিয়ম থেকে কিছু ব্যতিক্রম রয়েছে, আমি এখানে ভাবতে পারি সেগুলি এখানে:

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

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

  • আপনি পরবর্তী ত্রুটিগুলির ঝুঁকি ছাড়াই এবং একটি গুরুতর ত্রুটি না ছাপিয়ে নিরাপদে নাল রেফারের পরিস্থিতি মোকাবেলা করতে পারেন।

  • আপনি আপনার বর্তমান প্রসঙ্গে একটি সম্পূর্ণ ভিন্ন ধরণের ত্রুটি সংকেত চান (উদাহরণস্বরূপ, একটি ত্রুটি কোড ফিরিয়ে দেওয়া)


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

@ পিডিআর: চেক করার আরেকটি কারণ হ'ল এটি সর্বদা সনাক্ত করা হয়েছে তা নিশ্চিত করা।
জর্জিও

13
"প্রাক্তন সি বিকাশকারী", সম্ভবত। "প্রাক্তন সি ++ বিকাশকারীরা" কেবল যদি তারা নিজেরাই সি বিকাশকারীদের পুনরুদ্ধার করে। একটি আধুনিক সি ++ বিকাশকারী হিসাবে, আমি এমন কোড সম্পর্কে খুব সন্দেহজনক যে নগ্ন পয়েন্টার বা বেপরোয়া গতিশীল বরাদ্দ ব্যবহার করে about আসলে, আমি যুক্তিটি ঘুরিয়ে দিয়ে প্ররোচিত করব এবং বলব যে সিপি ++ ওপি বর্ণিত সমস্যাটি ভোগ করে না কারণ এর ভেরিয়েবলগুলিতে জাভা এবং সি # এর অতিরিক্ত বিশেষ নাল-নেসের সম্পত্তি নেই।
কেরেক এসবি 6'12

7
আপনার প্রথম অনুচ্ছেদটি গল্পের অর্ধেক মাত্র: হ্যাঁ, আপনি যদি সি # তে নাল রেফারেন্স ব্যবহার করেন তবে আপনি একটি ব্যতিক্রম পাবেন, অন্যদিকে সি ++ এ আপনি অপরিজ্ঞাত আচরণ পাবেন। তবে সু-লিখিত সি # তে, আপনি লিখিত সি ++ এর চেয়ে অনেক বেশি যুক্তিযুক্ত রেফারেন্সের সাথে আটকে আছেন ।
জেমস ম্যাকনেলিস

এনক্যাপসুলেশন যত ভাল হবে তত উত্তম এই উত্তরটি প্রযোজ্য।
রাডারবব

15

ব্যবহারের দাবি পরীক্ষা এবং ইঙ্গিত প্রাক / postconditions এবং আপনার কোড invariants করতে।

কোডটি কী প্রত্যাশা করে এবং কী পরিচালনা করতে পারে বলে আশা করা যায় তা বোঝা এটি এত সহজ করে তোলে।

একটি প্রতিপত্তি, আইএমও, একটি উপযুক্ত চেক কারণ এটি হ'ল:

  • দক্ষ (সাধারণত প্রকাশে ব্যবহৃত হয় না),
  • সংক্ষিপ্ত (সাধারণত একক লাইন) এবং
  • সাফ (পূর্ব শর্ত লঙ্ঘন, এটি একটি প্রোগ্রামিং ত্রুটি)।

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

হালনাগাদ

আপনার বিবরণ লিখেছিলেন। সাধারণত ব্যবহারকারীকে এমন একটি অ্যাপ্লিকেশন দেওয়া ভাল যা বাগের অধীনে ভাল কাজ করে, যথা সম্ভব সম্ভব দেখায়। দৃust়তা ভাল, কারণ স্বর্গই জানে যে একটি জটিল মুহুর্তে কী ভাঙবে।

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


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

1
ঠিক আছে, নিঃসন্দেহে নিঃসরণ করুন ^ এইচ ^ এইচ ond এইচেন্ডিশনাল থ্রো ফাংশন যা আপনার যদি প্রয়োজন হয় তবে মুক্তির জন্য সক্রিয় রয়েছে। আমি আমার নিজের প্রায়শই ঘুরিয়েছি।
ম্যাক

7

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


28
আমি আশা করি আপনি বোঝাতে চেয়েছিলেন: তাড়াতাড়ি ব্যর্থ হয়, দ্রুত ব্যর্থ হয়, প্রায়শই নয় ...
এমপি

12
সমস্যাটি হ'ল সুস্পষ্ট চেক ব্যতীত একটি নাল মান কখনও কখনও ব্যতিক্রম হওয়ার আগে অনেক আগে প্রচার করতে পারে এবং তার উত্পন্ন স্থানটি খুঁজে পাওয়া খুব কঠিন।
মাইকেল বর্গওয়ার্ট

@ মিশেলবার্গওয়ার্ড্ট স্ট্যাকের চিহ্নগুলি কি এটি নয়?
R0MANARMY

6
@ R0MANARMY: কোনও শূন্য মান যখন কোনও ক্ষেত্রের মধ্যে সংরক্ষণ হয় এবং নলপয়েন্টার এক্সেপশনটি অনেক পরে নিক্ষেপ করা হয় তখন স্ট্যাকের চিহ্নগুলি সহায়তা করে না।
মাইকেল বর্গওয়ার্ট

@ R0MANARMY এমনকি যদি আপনি স্ট্যাক ট্রেসটিতে লাইন নম্বরটিতে বিশ্বাস করতে সক্ষম হন (অনেক ক্ষেত্রে আপনি পারেন না) কিছু লাইনে একাধিক ভেরিয়েবল রয়েছে যা নাল হতে পারে।
ওহাদ স্নাইডার

6
  • নাল পরীক্ষা করা আপনার দ্বিতীয় স্বভাব হওয়া উচিত be

  • আপনার এপিআই অন্যান্য লোকেরা ব্যবহার করবে এবং তাদের প্রত্যাশা আপনার থেকে আলাদা হতে পারে

  • পুরো ইউনিট পরীক্ষাগুলি সাধারণত নাল রেফারেন্স চেকের প্রয়োজনকে হাইলাইট করে

  • নালগুলির জন্য চেক করা শর্তাধীন বিবৃতি বোঝায় না। আপনি যদি উদ্বিগ্ন হন যে নাল চেকিং আপনার কোডটি কম পাঠযোগ্য করে তোলে তবে আপনি নেট নেটওয়ার্ক চুক্তিগুলি বিবেচনা করতে পারেন।

  • নাল রেফারেন্স চেকগুলি হারিয়ে যাওয়ার জন্য আপনার কোডটি অনুসন্ধান করতে পুনঃশ্যাপার (বা অনুরূপ) ইনস্টল করার বিষয়টি বিবেচনা করুন


পূর্ব শর্তগুলির জন্য কোড চুক্তি ব্যবহার করা শর্তাধীন বিবৃতি কেবল প্রশংসিত।
একটি সিভিএন

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

4

আমি শব্দার্থবিজ্ঞানের দৃষ্টিকোণ থেকে প্রশ্নটি বিবেচনা করব, অর্থাত নিজেকে জিজ্ঞাসা করুন কোন NULL পয়েন্টার বা নাল রেফারেন্স যুক্তিটি কী উপস্থাপন করে।

যদি কোনও ফাংশন বা পদ্ধতি foo () টিতে টি টাইপের আর্গুমেন্ট থাকে, এক্স হয় বাধ্যতামূলক বা al চ্ছিক হতে পারে ।

সি ++ এ আপনি একটি বাধ্যতামূলক যুক্তি পাস করতে পারেন

  • একটি মান, যেমন শূন্য ফু (টি এক্স)
  • একটি রেফারেন্স, যেমন শূন্য ফু (টি ও এক্স)।

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

যদি আপনি একটি alচ্ছিক আর্গুমেন্টটি পাস করে থাকেন তবে আপনি একটি পয়েন্টার ব্যবহার করতে পারেন এবং NULL মানটি ব্যবহার করে নির্দেশ করতে পারেন যে কোনও মান দেওয়া হয়নি:

void foo(T* x)

একটি বিকল্প হ'ল স্মার্ট পয়েন্টার ব্যবহার করা

void foo(shared_ptr<T> x)

এই ক্ষেত্রে, আপনি সম্ভবত কোডের পয়েন্টারটি পরীক্ষা করতে চান, কারণ এটি পদ্ধতি foo () এর ক্ষেত্রে একটি পার্থক্য তৈরি করে যে x এর কোনও মান আছে বা নাও আছে।

তৃতীয় এবং শেষ কেসটি আপনি বাধ্যতামূলক যুক্তির জন্য পয়েন্টার ব্যবহার করেন । এই ক্ষেত্রে, x == NULL দিয়ে foo (x) কে কল করা একটি ত্রুটি এবং এটি কীভাবে পরিচালনা করতে হবে তা আপনাকে সিদ্ধান্ত নিতে হবে (কোনও সীমানা সূচক বা কোনও অবৈধ ইনপুট সহ):

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

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

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

যদি নালটি একটি অবৈধ ইনপুট হয়, তবে আপনার ত্রুটি রয়েছে এবং আমি সি ++ পয়েন্টারগুলির ক্ষেত্রে একই জাতীয় বিবেচনা প্রয়োগ করব। যেহেতু জাভাতে আপনি নাল পয়েন্টার ব্যতিক্রমগুলি ধরতে পারেন, উপরোক্ত পদ্ধতির 1 টি পদ্ধতির 2 এর সমতুল্য যদি পদ্ধতি foo () সমস্ত কার্যকরকরণের পথে সমস্ত ইনপুট আর্গুমেন্টকে (যা সম্ভবত ছোট পদ্ধতির জন্য খুব ঘন ঘন দেখা যায়) অবলম্বন করে।

সারমর্ম

  • সি ++ এবং জাভা উভয় ক্ষেত্রেই, al চ্ছিক আর্গুমেন্টগুলি বাতিল কিনা তা পরীক্ষা করা প্রোগ্রামের যুক্তির অংশ।
  • সি ++ এ, আমি যথাযথ ব্যতিক্রম ছুঁড়ে ফেলা হয় যাতে প্রোগ্রামটি শক্তিশালী উপায়ে পরিচালনা করতে পারে তা নিশ্চিত করার জন্য আমি সর্বদা বাধ্যতামূলক যুক্তিগুলি পরীক্ষা করব ।
  • জাভাতে (বা সি #), আমি বাধ্যতামূলক আর্গুমেন্টগুলি পরীক্ষা করে দেখি যদি সেখানে কার্যকর করার পথগুলি থাকে যা "শীঘ্রই ব্যর্থ হয়" এর শক্তিশালী ফর্মটি পেতে ছুঁড়ে না ফেলে won't

সম্পাদনা

আরও তথ্যের জন্য স্টিলগারকে ধন্যবাদ।

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

সুতরাং, আপনার কাছে পদ্ধতি এম 1 () কলিং পদ্ধতি এম 2 () এবং এম 2 () কোনও বস্তুর কাছে একটি রেফারেন্স (জাভাতে) বা একটি পয়েন্টার (সি ++ এ) প্রদান করে।

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

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


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

সুতরাং কোনও পদ্ধতির দ্বারা প্রাপ্ত ফলাফলটি কোনও জিনিসের জন্য একটি রেফারেন্স ছিল এবং ফলাফলটি উপস্থাপনের জন্য নাল মান হিসাবে ব্যবহৃত হত: না পাওয়া। আমি কি সঠিকভাবে বুঝতে পারি?
জর্জিও

আমি অতিরিক্ত বিবরণ দিয়ে প্রশ্ন আপডেট করেছি।
স্টিলগার

3

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

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

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

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


অবশ্যই চেইন আপ সাধারণ ত্রুটি হ্যান্ডলার আছে। লগগুলির সাথে সমস্যাটি হ'ল খুব দীর্ঘ সময় ধরে তাদের পরীক্ষা করার জন্য কেউ নাও থাকতে পারে।
স্টিলগার 16

@ স্টিলগার, লগগুলি পরীক্ষা করার জন্য যদি কেউ না থাকে, তবে নাল চেকগুলির অস্তিত্ব বা অনুপস্থিতিতে এটি কোনও সমস্যা নয়।
একটি সিভিএন

2
একটি সমস্যা আছে. শেষ ব্যবহারকারীরা খেয়াল করতে পারে না যে সিস্টেমটি দীর্ঘ সময়ের জন্য সঠিকভাবে কাজ করে না যদি নাল চেক থাকে যা কেবল ত্রুটিটি আড়াল করে এবং লগগুলিতে এটি লেখায়।
স্টিলগার

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

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

2

নিশ্চিত আশাNULL করা যায় না , তবে সবসময় বাগ রয়েছে!

আমি বিশ্বাস করি আপনি উচিত জন্য চেক NULLহোক বা না হোক আপনি এটা আশা করবেন না। আমাকে উদাহরণ দিন (যদিও তারা জাভাতে নেই)।

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

    এটি এমন একটি উদাহরণ যেখানে এনইউএল এর জন্য চেক করা কোনও ক্র্যাশকে রোধ করেছিল এবং কেসটি নীরবে পরিচালনা করা হয়েছিল।

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

    "একটি সমস্যা" দ্বারা আমি ক্র্যাশকে বোঝায় ( ক্র্যাশ ক্র্যাশের মতো (প্রোগ্রামটি সি ++ তে লেখা আছে), কোনও নাল পয়েন্টার ব্যতিক্রম নয়)। এই ক্ষেত্রে, NUL এর সম্মুখীন হলে লেনদেনটি আবার রোল করা দরকার (আপনি যদি NUL এর বিপরীতে ভেরিয়েবলগুলি পরীক্ষা না করেন তবে অবশ্যই কোনটি সম্ভব হবে না!)

আমি নিশ্চিত আপনি ধারণা পাবেন।

আপনার ফাংশনগুলিতে আর্গুমেন্টের বৈধতা যাচাই করা আপনার কোডটিকে বিশৃঙ্খলা করে না, কারণ এটি আপনার ফাংশনের শীর্ষে কয়েকটি চেক হয় (মাঝখানে ছড়িয়ে পড়ে না) এবং দৃ rob়তা বৃদ্ধি করে।

যদি আপনাকে "প্রোগ্রামটি ব্যবহারকারীকে বলে যে এটি ব্যর্থ হয়েছে এবং কৌতূহলবশত বন্ধ হয়ে গেছে বা একটি তাত্পর্যপূর্ণ অবস্থানে ফিরে যেতে সম্ভবত সম্ভবত একটি ত্রুটি লগ তৈরি করছে" এবং "অ্যাক্সেস লঙ্ঘন", আপনি কি প্রথমটি বেছে নেবেন না? এর অর্থ প্রতিটি বাগ সঠিকভাবে প্রত্যাশার চেয়ে বগি কোড দিয়ে ডাকার জন্য প্রস্তুত করা উচিত , কারণ সবসময় বাগগুলি বিদ্যমান থাকে।


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

@ স্টিলগার, বিপরীত! NULL অনুসন্ধান করা বার্তা সহ বাতিল করা হবে। NULL জন্য অনুসন্ধান না করা ক্রাশ হবে । এখন লেনদেনের শুরুতে ক্রাশ খারাপ নাও হতে পারে তবে মাঝখানে বিপর্যয়কর হতে পারে। (আমি বলিনি যে ব্যাঙ্ক ট্রান্সফারটি গেমের মতো ত্রুটিটি পরিচালনা করা উচিত! এটি ঠিক এটি পরিচালনা করা উচিত )
শাহবাজ

2
একটি "লেনদেন" এর সম্পূর্ণ পয়েন্টটি এটি অর্ধেকটি সম্পন্ন করা যায় না :) যদি কোনও ত্রুটি থাকে তবে এটি আবার ঘুরিয়ে দেওয়া হয়।
স্টিলগার 16

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

1
@ মের্লিনমর্গান-গ্রাহাম, আমি তাই করেছি। আশা করি এই বিভ্রান্তি দূর হবে।
শাহবাজ

2

অন্যান্য উত্তরগুলি নির্দেশ করে যেমন আপনি প্রত্যাশা NULLনা করেন তবে তা ছুঁড়ে দিয়ে পরিষ্কার করুন ArgumentNullException। আমার দৃষ্টিতে, আপনি যখন প্রকল্পটি ডিবাগ করছেন তখন এটি আপনাকে আপনার প্রোগ্রামের যুক্তিতে ত্রুটিগুলি দ্রুত আবিষ্কার করতে সহায়তা করে।

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

আরেকটি বিষয় হ'ল যদি NULLকোনও ফাংশনের প্যারামিটারগুলিতে চেকিং করা থাকে, তবে আপনি সিদ্ধান্ত নিতে পারেন যে ফাংশনটি করার সঠিক জায়গা কিনা তা না; যদি তা না হয় তবে ফাংশনটির সমস্ত রেফারেন্সগুলি খুঁজে বের করুন এবং তারপরে ফাংশন পর্যালোচনার সম্ভাব্য পরিস্থিতিগুলির কোনও পরামিতি পাস করার আগে যা কোনও নাল রেফারেন্সের দিকে নিয়ে যেতে পারে।


1

nullআপনার সিস্টেমে প্রত্যেকটি আবিষ্কারের জন্য অপেক্ষা করা টিকটিক টাইম বোমা। চেক nullসীমানা যেখানে আপনার কোড কোড আপনি নিয়ন্ত্রণ না সাথে মিথস্ক্রিয়া, এবং নিষেধ nullআপনার নিজের কোড মধ্যে। নিরীহভাবে বিদেশী কোড বিশ্বাস না করেই এটি আপনাকে সমস্যা থেকে মুক্তি দেয়। পরিবর্তে ব্যতিক্রম বা কিছু ধরণের Maybe/ Nothingটাইপ ব্যবহার করুন।


0

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

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


-1

যেহেতু Fail early, fail fast@ ডেডজিএম (@ এমপিআই) দ্বারা বলা হয়েছে ততটা সহজ নয় কারণ ওয়েব-অ্যাপ্লিকেশনটি বাগের অধীনে ভালভাবে কাজ করতে হবে আপনার নিয়মটি প্রয়োগ করা উচিত

লগিং ছাড়া ধরা ব্যতিক্রম

সুতরাং আপনি বিকাশকারী হিসাবে লগগুলি পরীক্ষা করে সম্ভাব্য সমস্যাগুলি সম্পর্কে সচেতন হন are

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

[হালনাগাদ]

যদি পৃষ্ঠার এন্ডুয়েসারটি ত্রুটি সম্পর্কে সচেতন না থাকে তবে আপনি কোনও অ্যাপেন্ডর সেটআপ করতে পারেন যা আপনাকে ত্রুটি এবং মাপের বিষয়ে অবগত থাকা ফ্যাটালারিগুলি মেল করে।

যদি এটি ঠিক থাকে যে পৃষ্ঠার অন্তরীক্ষক ক্রিপ্টিক ত্রুটিযুক্ত বার্তাগুলি দেখতে পান আপনি কোনও অ্যাপেন্ডার সেটআপ করতে পারেন যা পৃষ্ঠার শেষে পৃষ্ঠার প্রসেসিংয়ের জন্য ত্রুটিমুক্ত রাখে।

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


1
প্রশ্ন হ'ল পেইজে কি হয়?
স্টিলগার

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

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

-1

এই প্রশ্নের উত্তর ইতিমধ্যে আছে, তাদের মধ্যে একটি সংযোজন হতে পারে: আমি আমার কোডটিতে দৃser়তা পছন্দ করি না। যদি আপনার কোডটি কেবল বৈধ অবজেক্টের সাথে কাজ করতে পারে তবে নাল দিয়ে বাদাম, আপনার নাল মানটি দেওয়া উচিত।

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

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


আপনি দয়া করে ডাউন-ভোটের জন্য কিছু লিখতে পারেন? আমি একটি আলোচনা প্রশংসা করব। ধন্যবাদ
GET

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

-1

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

সম্পাদনা: আপনি যখন কোনও কিছু ভুল বলে আশা করেন না তখন আপনি যদি শূন্য হয়ে যান - প্রোগ্রামটি মারা যাবে।


-1

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

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

এই শেষ অনুচ্ছেদে আপনার প্রশ্নের উত্তর দেওয়ার সাথে সামান্য কিছু ছিল। আমি শুধু জাভা ঘৃণা করি।

- নোহ


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