আমার কাছে কোনও সম্পত্তির জন্য একটি সহজ সেটার পদ্ধতি রয়েছে এবং nullএই বিশেষ সম্পত্তিটির জন্য এটি উপযুক্ত নয়। আমি সবসময় এই পরিস্থিতিতে ছিঁড়েছি: আমি একটি নিক্ষেপ করা উচিত IllegalArgumentException, বা একটি NullPointerException? জাভাডোকগুলি থেকে উভয়ই উপযুক্ত বলে মনে হচ্ছে। কোন ধরণের বোঝা মান আছে? অথবা এই things জিনিসগুলির মধ্যে এটির একটি যা আপনার পছন্দমতো করা উচিত এবং উভয়ই সত্যই সঠিক?
উত্তর:
মনে হচ্ছে এটির IllegalArgumentExceptionজন্য আপনাকে বলা হয় যদি আপনি nullঅনুমোদিত মান হতে চান না , এবং NullPointerExceptionযদি আপনি কোনও পরিবর্তনশীল যেটি পরিবর্তিত হয় তা ব্যবহার করার চেষ্টা করছেন তবে নিক্ষেপ করা হবে null।
IllegalArgumentExceptionজাভা এর অবজেক্টস.প্রিয়রনননল (টি) এবং পেয়ারা এর পূর্বসূচি .চেকনোটনল (টি) এর সাথে বিপরীতে রয়েছে যা এটিকে ছুড়ে ফেলে NullPointerException। যাইহোক, জেসন কোহেনের দুর্দান্ত উত্তর এবং এর মন্তব্য বিভাগে সঠিক উত্তরটি যথাযথভাবেIllegalArgumentException ব্যাখ্যা করা হয়েছে ।
নিম্নলিখিত কারণে আপনার IllegalArgumentException(আইএই) ব্যবহার করা উচিত , (এনপিই) নয় NullPointerException:
প্রথমত, এনপিই জাভাডক স্পষ্টভাবে এনসিপি উপযুক্ত যেখানে মামলাগুলি তালিকাভুক্ত করে। লক্ষ করুন যে, তাদের সব নিক্ষিপ্ত হয় রানটাইম দ্বারা যখন nullঅযথাযথভাবে ব্যবহার করা হয়। বিপরীতে, আইএই জাভাডক আরও পরিষ্কার হতে পারে না: "কোনও পদ্ধতি অবৈধ বা অনুপযুক্ত যুক্তি পাস করেছে তা বোঝাতে ছুড়ে দেওয়া হয়েছিল" " হ্যাঁ, আপনি!
দ্বিতীয়ত, যখন আপনি একটি স্ট্যাক ট্রেসটিতে একটি এনপিই দেখেন, আপনি কী ধরে নেন? সম্ভবত যে কেউ dereferences করেছেন a null। আপনি যখন আইএই দেখেন, আপনি স্ট্যাকের শীর্ষে পদ্ধতিটির কলারকে একটি অবৈধ মান দিয়ে পাস করে ধরে নিয়েছেন। আবার, পরবর্তী ধারণাটি সত্য, পূর্ববর্তীটি বিভ্রান্তিকর।
তৃতীয়ত, যেহেতু আইএই স্পষ্টতই প্যারামিটারগুলি যাচাই করার জন্য তৈরি করা হয়েছে, আপনাকে এটিকে ব্যতিক্রমের ডিফল্ট পছন্দ হিসাবে ধরে নিতে হবে, তবে আপনি কেন তার পরিবর্তে এনপিই বেছে নেবেন? অবশ্যই আলাদা আচরণের জন্য নয় - আপনি কি কলিং কোডটি আশা করছেন যে এনপিই'র আইএই থেকে পৃথকভাবে ধরবে এবং ফলস্বরূপ কিছু আলাদা করবে? আপনি কি আরও একটি নির্দিষ্ট ত্রুটি বার্তা যোগাযোগ করার চেষ্টা করছেন? তবে আপনি অন্য যে কোনও ভুল পরামিতিগুলির জন্য যেমনটি করা উচিত ব্যতিক্রম বার্তা পাঠ্যে এটি করতে পারেন।
চতুর্থত, অন্য সমস্ত ভুল পরামিতি ডেটা আইএই হবে, তবে কেন ধারাবাহিক হবে না? কেন এটি অবৈধ nullএত বিশেষ যে এটি অন্য সমস্ত ধরণের অবৈধ যুক্তি থেকে পৃথক ব্যতিক্রম দাবি করে?
পরিশেষে, আমি অন্যান্য উত্তর দ্বারা প্রদত্ত যুক্তিটি মেনে নিয়েছি যে জাভা এপিআইয়ের অংশগুলি এই পদ্ধতিতে এনপিই ব্যবহার করে। তবে জাভা এপিআই ব্যতিক্রম প্রকার থেকে নামকরণের কনভেনশনের সমস্ত কিছুর সাথে সঙ্গতিপূর্ণ নয়, তাই আমি মনে করি কেবল অন্ধভাবে অনুলিপি করা (আপনার পছন্দের অংশ) জাভা এপিআই এই অন্যান্য বিবেচ্য বিষয়গুলির ট্রাম্প করার পক্ষে যথেষ্ট উপযুক্ত যুক্তি নয়।
Validate.notNull(কমন্স ল্যাং) এবং Preconditions.checkNotNull(পেয়ারা) উভয়ই
checkArgument(arg != null), কেবল এটির সুবিধামত আর্গ ফিরে না পেয়ে বা আপনি তৈরি করতে পারেন আপনার প্রকল্পের একটি স্থানীয় ইউটিলিটি " কোড.google.com/p/guava-libraries/wiki/IdeaGraveyard
মানটি নিক্ষেপ করা হয় NullPointerException। সাধারণত ত্রুটিযুক্ত "কার্যকর জাভা" আইটেম 42 (প্রথম সংস্করণ), আইটেম 60 (দ্বিতীয় সংস্করণ), বা আইটেম 72 (তৃতীয় সংস্করণ) "স্ট্যান্ডার্ড ব্যতিক্রমগুলির ব্যবহারের পক্ষে" এ সংক্ষেপে আলোচনা করে:
"যুক্তিযুক্তভাবে, সমস্ত ভ্রান্ত পদ্ধতিতে অনুরোধগুলি একটি অবৈধ যুক্তি বা অবৈধ রাষ্ট্রের দিকে ফোটে, তবে অন্যান্য ব্যতিক্রমগুলি কিছু ধরণের অবৈধ যুক্তি এবং রাজ্যের জন্য স্ট্যান্ডার্ডভাবে ব্যবহৃত হয় a অবৈধআর্গুমেন্টএক্সেপশনের চেয়ে নলপয়েন্টারএক্সেপশন নিক্ষেপ করা হবে।
আমি সকলেই IllegalArgumentExceptionনাল প্যারামিটারগুলি ছুঁড়ে ফেলার পক্ষে ছিলাম , আজ অবধি, আমি java.util.Objects.requireNonNullজাভা in-এর পদ্ধতিটি লক্ষ্য করেছি when সেই পদ্ধতিটি না করে বরং:
if (param == null) {
throw new IllegalArgumentException("param cannot be null.");
}আপনি করতে পারেন:
Objects.requireNonNull(param);এবং এটি একটি নিক্ষেপ করা হবে NullPointerExceptionযদি প্যারামিটার আপনি এটা পাস হয় null।
এই পদ্ধতির ঠিক মাঝখানে যে শব্দটি দেওয়া হয়েছে তা দিয়ে java.utilআমি তার অস্তিত্বটিকে একটি দুর্দান্ত দৃ ind় ইঙ্গিত হিসাবে গ্রহণ করছি যে নিক্ষেপ করা NullPointerExceptionহচ্ছে "কাজ করার জাভা উপায়"।
আমি মনে করি যে কোনও হারেই আমি সিদ্ধান্ত নিয়েছি।
দ্রষ্টব্য যে হার্ড ডিবাগিং সম্পর্কে যুক্তিগুলি বোগাস কারণ আপনি অবশ্যই NullPointerExceptionকোন নাল ছিল তা কেন এবং এটি কেন নালু হওয়া উচিত নয় তা জানাতে একটি বার্তা সরবরাহ করতে পারেন । শুধু মতো IllegalArgumentException।
এর আরও একটি সুবিধা NullPointerExceptionহ'ল, অত্যন্ত কার্য সম্পাদনের সমালোচনামূলক কোডে, আপনি নাল (এবং NullPointerExceptionএকটি বন্ধুত্বপূর্ণ ত্রুটি বার্তা সহ) এর জন্য একটি সুস্পষ্ট চেক সরবরাহ করতে পারেন , এবং NullPointerExceptionযখন আপনি শূন্যপদে কোনও পদ্ধতিতে কল করবেন তখন স্বয়ংক্রিয়ভাবে আপনি নির্ভর করতে পারবেন প্যারামিটার। আপনি যদি কোনও পদ্ধতির দ্রুত কল করেন (তবে দ্রুত ব্যর্থ হন), তবে আপনার মূলত একই প্রভাব রয়েছে, বিকাশকারীর পক্ষে ব্যবহারকারী হিসাবে উপযুক্ত নয়। বেশিরভাগ ক্ষেত্রে স্পষ্টভাবে পরীক্ষা করা এবং কোন পরামিতিটি শূন্য ছিল তা বোঝাতে একটি দরকারী বার্তা দিয়ে নিক্ষেপ করা ভাল, তবে পদ্ধতি / নির্মাতার প্রকাশিত চুক্তি না ভেঙে যদি পারফরম্যান্স নির্দেশ দেয় তবে পরিবর্তনের বিকল্পটি পাওয়া ভাল nice
Preconditions.checkNotNull(arg)এনপিইও ছুড়ে দেয়।
আমি জেডিকে গ্রন্থাগারগুলির নকশা অনুসরণ করতে ঝোঁক, বিশেষত সংগ্রহ এবং সমঝোতা (জোশুয়া ব্লচ, ডগ লি, এই ছেলেরা কীভাবে কঠিন এপিআইগুলি ডিজাইন করতে জানে)। যাইহোক, জেডিকে প্রো-সক্রিয়ভাবে অনেক এপিআই ছুড়ে দেয় NullPointerException।
উদাহরণস্বরূপ, জাভাদোক Map.containsKeyরাজ্যগুলির জন্য :
কী টি নাল থাকলে এবং এই মানচিত্রটি নাল কী (alচ্ছিক) অনুমতি দিচ্ছে না
এটি আপনার নিজের এনপিই নিক্ষেপ করার জন্য পুরোপুরি বৈধ। কনভেনশনটি হল প্যারামিটারের নামটি অন্তর্ভুক্ত করা যা ব্যতিক্রমের বার্তায় নাল ছিল।
প্যাটার্নটি যায়:
public void someMethod(Object mustNotBeNull) {
if (mustNotBeNull == null) {
throw new NullPointerException("mustNotBeNull must not be null");
}
}আপনি যা-ই করুন না কেন, অন্য কোডগুলি এটি ব্যবহারের চেষ্টা করার পরে কোনও খারাপ মান সেট হওয়ার অনুমতি দেয় না এবং পরে একটি ব্যতিক্রম ছুঁড়ে দেয়। এটি ডিবাগিংকে দুঃস্বপ্নে পরিণত করে। আপনার সর্বদা "ব্যর্থ-দ্রুত" নীতিটি অনুসরণ করা উচিত।
জেসন কোহেনের যুক্তিটি ভোট দিয়েছিল কারণ এটি ভালভাবে উপস্থাপিত হয়েছিল। আমাকে ধাপে ধাপে এটি ভাঙ্গতে দিন। ;-)
NPE JavaDoc স্পষ্টভাবে বলেছেন, "নাল বস্তুর অন্যান্য অবৈধ ব্যবহার করে" । যদি এটি কেবলমাত্র এমন পরিস্থিতিতে সীমাবদ্ধ ছিল যেখানে রানটাইমটি যখন শূন্যতার মুখোমুখি না হয় তখন তার মুখোমুখি হয় such
আপনি যদি ভুল জিনিসটি ধরে নেন তবে এটি সাহায্য করতে পারে না, তবে এনপ্যাপসুলেশনটি সঠিকভাবে প্রয়োগ করা হয়েছে বলে ধরে নেওয়া, আপনার সত্যিকারের যত্ন নেওয়া উচিত নয় বা লক্ষ্য করা উচিত নয় যে কোনও শূন্যটি অনুপযুক্তভাবে উপস্থাপিত হয়েছিল কিনা বনাম a
আমি বেছে নিতে চাই NPE উপর IAE একাধিক কারণে
প্রকৃতপক্ষে, অন্যান্য অবৈধ যুক্তিগুলির ফলে সমস্ত ধরণের অন্যান্য ব্যতিক্রম হতে পারে in অজানাহস্টএক্সেপশন , ফাইলনটফাউন্ডএক্সেপশন , বিভিন্ন সিনট্যাক্স ত্রুটি ব্যতিক্রম, ইনডেক্সআউট অফফাউন্ডস এক্সসেপশন , প্রমাণীকরণ ব্যর্থতা ইত্যাদি
সাধারণভাবে, আমি অনুভব করি যে এনপিই অনেকটাই ম্যালেন্ডেড কারণ traditionতিহ্যগতভাবে কোডের সাথে সম্পর্কিত যা ব্যর্থ দ্রুত নীতি অনুসরণ করতে ব্যর্থ হয় । যেটি, জেডিকে কোনও বার্তা স্ট্রিং দিয়ে এনপিই-র জনপ্রিয় করতে ব্যর্থতা সত্যই একটি দৃ negative় নেতিবাচক অনুভূতি তৈরি করেছে যা ভালভাবে প্রতিষ্ঠিত নয়। আসলে, রানটাইম দৃষ্টিকোণ থেকে এনপিই এবং আইএইয়ের মধ্যে পার্থক্যটি কঠোরভাবে নাম। সেই দৃষ্টিকোণ থেকে, আপনি নামটির সাথে আরও সুনির্দিষ্ট হন, আপনি কলারের কাছে আরও স্পষ্টতা দিন।
এটি একটি "হলি ওয়ার" শৈলীর প্রশ্ন। অন্য কথায়, উভয় বিকল্পই ভাল তবে লোকেরা তাদের পছন্দ পছন্দ করবে যা তারা মৃত্যুর পক্ষে রক্ষা করবে।
NullPointerExceptionএটিকে নিক্ষেপ করা উচিত: এটি জেনডিকে যে কনভেনশন ব্যবহার করে, এবং ইন্টারফেসের জন্য এটি প্রয়োজন, এটি আরও নির্দিষ্ট (ঠিক যেমন IndexOutOfBoundsException, ইত্যাদি) ইত্যাদি।
যদি এটি একটি setterপদ্ধতি এবং nullএটিতে পাস করা হয় তবে আমি মনে করি এটি নিক্ষেপ করা আরও বুদ্ধিমান হবে IllegalArgumentException। একটি NullPointerExceptionকেস যেখানে আপনি আসলে ব্যবহার করতে চেষ্টা করছেন আরও জানার জন্য বলে মনে হয় null।
সুতরাং, যদি আপনি এটি ব্যবহার করছেন এবং এটা null, NullPointer। এটা পাস হচ্ছে যদি এটা null, IllegalArgument।
অ্যাপাচি কমন্স ল্যাং-এর একটি নুলআরগমেন্টএক্সেপশন রয়েছে যা এখানে আলোচিত অনেকগুলি বিষয় রয়েছে: এটি অবৈধ অর্গগমেন্ট এক্সেপশন প্রসারিত করে এবং এর একমাত্র নির্মাতা যুক্তিটির নাম নেয় যা অকার্যকর হওয়া উচিত ছিল।
যদিও আমি অনুভব করি যে নুলআরগামেন্টএক্সেপশন বা অবৈধতা সংক্রান্ত ধারণা সম্পর্কে কিছু ছুঁড়ে দেওয়া ব্যতিক্রমী পরিস্থিতি আরও সঠিকভাবে বর্ণনা করে, আমার সহকর্মীরা এবং আমি এই বিষয়ে ব্লচের পরামর্শকে মেনে চলা বেছে নিয়েছি।
যা বলা হচ্ছে তার সাথে আরও একমত হতে পারিনি। তাড়াতাড়ি ব্যর্থ, দ্রুত ব্যর্থ। খুব ভাল ব্যতিক্রম মন্ত্র।
কোন প্রশ্নটি বাদ দেওয়া উচিত তা বেশিরভাগ ব্যক্তিগত স্বাদের বিষয়। আমার মনে ইলিজালআরগমেন্টমেন্ট ধারণাটি এনপিই ব্যবহার করার চেয়ে বেশি সুনির্দিষ্ট বলে মনে হচ্ছে যেহেতু এটি আমাকে বলছে যে সমস্যাটি আমি পদ্ধতিতে পাস করেছি এমন একটি যুক্তির সাথে ছিল যা পদ্ধতিটি সম্পাদন করার সময় উত্পন্ন হতে পারে with
আমার 2 সেন্ট
প্রকৃতপক্ষে, ইলিজালআরগামেন্টএক্সেপশন বা নলপয়েন্টারএক্সসেপশন নিক্ষেপের প্রশ্নটি জাভাতে ব্যতিক্রম হ্যান্ডলিংয়ের অসম্পূর্ণ বোঝার সাথে একটি সংখ্যালঘু মানুষের কাছে কেবল একটি "পবিত্র যুদ্ধ"। সাধারণভাবে, নিয়মগুলি সহজ এবং নীচে:
অবৈধ অরগিউমেন্টএক্সেপশনকে সব ধরণের যুক্তি সীমাবদ্ধতা লঙ্ঘনের ক্ষেত্রে ম্যাপিংয়ের বিরুদ্ধে কমপক্ষে তিনটি খুব ভাল কারণ রয়েছে যার মধ্যে তৃতীয়টি সম্ভবত অনুশীলনের খারাপ শৈলী চিহ্নিত করার জন্য ততটা গুরুতর:
(1) কোনও প্রোগ্রামার নিরাপদে ধরে নিতে পারে না যে যুক্তি সীমাবদ্ধতা লঙ্ঘনের সমস্ত ক্ষেত্রে অবৈধ অর্গানমেন্ট এক্সেক্সশন হয়, কারণ স্ট্যান্ডার্ড ক্লাসের সংখ্যাগরিষ্ঠ এই ব্যতিক্রমটিকে ব্যর্থতা বাদ্য হিসাবে ব্যবহার করে যদি আরও নির্দিষ্ট ধরণের ব্যতিক্রম না পাওয়া যায়। আপনার API এ IllegalArgumentException এর পক্ষে যুক্তি সীমাবদ্ধতা লঙ্ঘনের সমস্ত ক্ষেত্রে ম্যাপ করার চেষ্টা করা আপনার ক্লাসগুলি ব্যবহার করে কেবল প্রোগ্রামার হতাশার দিকে পরিচালিত করে, কারণ আদর্শ পাঠাগারগুলি বেশিরভাগই আপনার লঙ্ঘনকারী বিভিন্ন বিধি অনুসরণ করে এবং আপনার বেশিরভাগ এপিআই ব্যবহারকারী তাদেরও ব্যবহার করবে!
(২) ব্যতিক্রমগুলি ম্যাপিংয়ের ফলে একক উত্তরাধিকারের ফলে ঘটে বিভিন্ন ধরণের ব্যতিক্রমী পরিণতি: সমস্ত জাভা ব্যতিক্রম শ্রেণি, এবং তাই কেবল একক উত্তরাধিকারকে সমর্থন করে। অতএব, একটি ব্যতিক্রম তৈরি করার কোনও উপায় নেই যা সত্যই একটি নলপয়েন্টারএক্সসেপশন এবং একটি অবৈধআর্গুমেন্টএক্সসেপশন উভয়ই বলে, কারণ সাবক্লাসগুলি কেবলমাত্র এক বা অন্যের উত্তরাধিকারী হতে পারে। নাল আর্গুমেন্টের ক্ষেত্রে একটি অবৈধআর্গুমেন্টএক্সসেপশন নিক্ষেপ করা অতএব, যখনই কোনও প্রোগ্রাম প্রোগ্রামালিটিকভাবে সমস্যাটি সংশোধন করার চেষ্টা করে, ততক্ষণে এপিআই ব্যবহারকারীদের পক্ষে সমস্যার মধ্যে পার্থক্য করা শক্ত হয়ে যায়, উদাহরণস্বরূপ, কল রিপিটে ডিফল্ট মানগুলি খাওয়ানো!
(3) ম্যাপিং আসলে বাগ মাস্কিংয়ের বিপদ তৈরি করে: ইলিজালআরগামেন্টএক্সেপশনটিতে যুক্তি সীমাবদ্ধতা লঙ্ঘনের মানচিত্রের জন্য, আপনাকে যে কোনও বাধা যুক্তি রয়েছে তার প্রতিটি পদ্ধতির মধ্যে একটি বহিরাগত চেষ্টা-কোডের কোডিং করতে হবে। তবে এই ক্যাচ ব্লকে কেবল রানটাইমএক্সেপশন ধরা প্রশ্নটির বাইরে নয়, কারণ এটি আপনার মধ্যে ইলিজালআরগমেন্টএক্সেপশন হিসাবে ব্যবহৃত লাইবেরি পদ্ধতি দ্বারা নথিভুক্ত রানটাইম এক্সেক্সসেপসকে ম্যাপিংয়ের ঝুঁকিপূর্ণ, এমনকি যদি তারা যুক্তির সীমাবদ্ধতা লঙ্ঘনের কারণে না হয়। সুতরাং আপনাকে খুব সুনির্দিষ্ট হওয়া দরকার, তবে এমনকি সেই প্রচেষ্টা আপনাকে এমন ঘটনা থেকে রক্ষা করতে পারে না যে আপনি দুর্ঘটনাক্রমে অন্য একটি এআইপি (যেমন একটি বাগ) এর একটি অননুমোদিত রানটাইম ব্যতিক্রমকে আপনার এপিআই এর অবৈধঅর্গামেন্ট এক্সেকশন হিসাবে ম্যাপ করে।
অন্যদিকে স্ট্যান্ডার্ড অনুশীলনের সাথে, নিয়মগুলি সরল থাকে এবং ব্যতিক্রমগুলি অনাকাঙ্ক্ষিত এবং নির্দিষ্ট থাকার কারণ ঘটে। পদ্ধতি কলারের জন্য, নিয়মগুলি পাশাপাশি সহজ: - যদি আপনি কোনও অবৈধ মান পাস করার কারণে কোনও প্রকারের ডকুমেন্টেড রানটাইম ব্যতিক্রমের মুখোমুখি হন, হয় হয় ডিফল্ট দিয়ে কলটি পুনরাবৃত্তি করুন (এই নির্দিষ্ট ব্যতিক্রমগুলির জন্য প্রয়োজনীয়) তবে আপনার কোডটি সংশোধন করুন - অন্যদিকে যদি আপনি কোনও রানটাইম ব্যতিক্রমকে উত্সাহিত করেন যা প্রদত্ত আর্গুমেন্টগুলির সেট করার জন্য নথিভুক্ত নয়, তবে তাদের কোড বা তাদের ডকুমেন্টেশন ঠিক আছে কিনা তা নিশ্চিত করার জন্য পদ্ধতিটির নির্মাতাদের কাছে একটি বাগ রিপোর্ট দাখিল করুন।
যদি কোনও পরামিতি অবৈধ বলে ঘোষণা করার জন্য IllegalArgumentException (স্ট্রিং মেসেজ) ব্যবহার করা হয় তবে গ্রহণযোগ্য অনুশীলনটি, তাই বলার অপেক্ষা রাখে যে প্যারামিটারগুলি শূন্য অবস্থায় পাওয়া গেছে, ব্যতিক্রম অকারণে, আপনি কিছু করবেন এটার মত:
if( variable == null )
throw new IllegalArgumentException("The object 'variable' cannot be null");"নালপয়েন্টারএক্সসেপশন" স্পষ্টভাবে ব্যবহার করার কোনও কারণ আপনার কাছে নেই। নাল রেফারেন্সএক্সেপশন জাভা ভার্চুয়াল মেশিন দ্বারা নিক্ষিপ্ত একটি ব্যতিক্রম যখন আপনি নাল রেফারেন্সে কোড চালানোর চেষ্টা করেন (লাইক টু স্ট্রিং () )।
nullআর্গুমেন্টের সাথে একচেটিয়া ব্যতিক্রম ছুঁড়ে দেওয়া ( NullPointerExceptionযা কাস্টম টাইপ হোক না কেন ) স্বয়ংক্রিয় nullপরীক্ষাকে আরও নির্ভরযোগ্য করে তোলে । এই স্বয়ংক্রিয় টেস্টিং প্রতিফলন এবং ডিফল্ট মান একটি সেট সঙ্গে সম্পন্ন করা যেতে পারে, হিসাবে পেয়ারা এর NullPointerTester। উদাহরণস্বরূপ, NullPointerTesterনিম্নলিখিত পদ্ধতিটি কল করার চেষ্টা করবে ...
Foo(String string, List<?> list) {
checkArgument(string.length() > 0);
// missing null check for list!
this.string = string;
this.list = list;
}... যুক্তি দুটি তালিকা সহ: "", nullএবং null, ImmutableList.of()। এটি পরীক্ষা করবে যে এই প্রতিটি কল প্রত্যাশাকে ছুঁড়ে ফেলেছে NullPointerException। এই বাস্তবায়নের জন্য, একটি nullতালিকা পাস করা উত্পাদন করে নাNullPointerException । এটি একটি ডিফল্ট স্ট্রিং এর ব্যবহারের IllegalArgumentExceptionকারণ NullPointerTesterঘটায় তা ঘটায় ""। যদি NullPointerTesterকেবল মানগুলির NullPointerExceptionজন্য প্রত্যাশা করে nullতবে এটি বাগটি ধরে। যদি এটি প্রত্যাশা IllegalArgumentExceptionকরে তবে এটি এটিকে মিস করে।
কিছু সংকলন ধরে নিয়েছে যা পরিবর্তে nullব্যবহার করে প্রত্যাখ্যাত । উদাহরণস্বরূপ, আপনি যদি সেটটিকে প্রত্যাখ্যান করে এমন একটি সেটের তুলনা করেন তবে প্রথম সেটটি অন্যটিকে কল করে এবং এটি ধরবে - তবে তা নয় । (আমি বাস্তবায়নের দিকে তাকিয়ে আছি ।)NullPointerExceptionIllegalArgumentExceptionnullnullcontainsAllNullPointerExceptionIllegalArgumentExceptionAbstractSet.equals
আপনি যুক্তিযুক্তভাবে যুক্তি দিতে পারেন যে এইভাবে চেক করা ব্যতিক্রমগুলি ব্যবহার করা একটি অ্যান্টিপ্যাটার্ন, যে সংকলনগুলি ধারণ nullকরতে পারে না সেগুলির সাথে সংগ্রহগুলি তুলনা nullকরা একটি সম্ভাব্য বাগ যা সত্যই একটি ব্যতিক্রম ঘটানো উচিত , বা nullকোনও সংগ্রহ সংগ্রহ করা মোটেই খারাপ ধারণা bad । তা সত্ত্বেও, আপনি যদি equalsএইরকম ক্ষেত্রে ব্যতিক্রম ছুঁড়ে ফেলার কথা বলতে রাজি না হন তবে আপনি মনে রাখতে আটকে যাচ্ছেন যা NullPointerExceptionকিছু পরিস্থিতিতে প্রয়োজন তবে অন্যের ক্ষেত্রে নয়। ("সি সি 'বাদে এনপিইয়ের আগে আইএই ...")
new TreeSet<>().containsAll(Arrays.asList((Object) null));ছোঁড়ার NPEকারণ Listরয়েছে null।
বিষয়গত প্রশ্ন হিসাবে এটি বন্ধ করা উচিত, তবে এটি এখনও খোলা রয়েছে:
এটি আমার পূর্ববর্তী কর্মস্থলে ব্যবহৃত অভ্যন্তরীণ নীতির অংশ এবং এটি সত্যই ভাল কাজ করেছে। এটি সমস্তই মেমরি থেকে তাই সঠিক শব্দটি আমি মনে করতে পারি না। এটি লক্ষণীয় যে তারা চেক করা ব্যতিক্রমগুলি ব্যবহার করেনি, তবে এটি প্রশ্নের ক্ষেত্রের বাইরে। তারা যে চেক করা ব্যতিক্রমগুলি ব্যবহার করেছে তা 3 টি প্রধান বিভাগে পড়ে।
নালপয়েন্টার এক্সেপশন: ইচ্ছাকৃতভাবে ছুঁড়ে ফেলবেন না। কোনও শূন্য রেফারেন্সকে বিবেচনা করার সময় এনপিইগুলি কেবল ভিএম দ্বারা ছুঁড়ে ফেলা হয়। এগুলি যাতে কখনও নিক্ষেপ না করা হয় তার জন্য সর্বাত্মক প্রচেষ্টা করা দরকার। @ ত্রুটিযুক্ত এবং @ নটনুল এই ত্রুটিগুলি খুঁজে পেতে কোড বিশ্লেষণ সরঞ্জামগুলির সাথে একত্রে ব্যবহার করা উচিত।
অবৈধ অর্গমেন্ট এক্সেপশন: নিক্ষিপ্ত হয় যখন কোনও ফাংশনের যুক্তি জনসাধারণের দলিল অনুসারে মেনে না যায়, তেমনি ত্রুটিটি চিহ্নিত হয়ে তর্কিত শর্তাবলী বর্ণিত হতে পারে The
অবৈধ স্টেটএক্সেপশন: কোনও ফাংশন যখন বলা হয় তখন নিক্ষিপ্ত হয় এবং তার আর্গুমেন্টগুলি হয় পাশ করার সময় অপ্রত্যাশিত হয় বা পদটির সদস্যের সাথে মেলে না এমন অবস্থার সাথে সামঞ্জস্য হয় না।
উদাহরণস্বরূপ, দৈর্ঘ্যযুক্ত জিনিসগুলিতে সূচিপত্রের বাইরে দুটি অভ্যন্তরীণ সংস্করণ ব্যবহৃত হয়েছিল x সূচক দৈর্ঘ্যের চেয়ে বড় হলে ইলিজালস্টেটএক্সেপশন এর একটি উপ-শ্রেণীর ব্যবহৃত হয়। সূচকটি নেতিবাচক থাকলে ব্যবহার করা হত অবৈধআর্গুমেন্টএক্সসেপ্টের অন্য একটি সাবক্লাস। এটি হ'ল কারণ আপনি অবজেক্টে আরও আইটেম যুক্ত করতে পারেন এবং যুক্তিটি বৈধ হবে, তবে negativeণাত্মক সংখ্যাটি কখনই বৈধ হয় না।
যেমনটি আমি বলেছি, এই সিস্টেমটি সত্যই কার্যকরভাবে কাজ করে, এবং এটির কারণটি এখানে রয়েছে তা বোঝাতে কারও কাছে এটি নেওয়া হয়েছিল: "ত্রুটিটির ধরণের উপর নির্ভর করে আপনার কী করা উচিত তা নির্ধারণ করা সহজ সরল। কী ভুল হয়েছে তা খুঁজে বের করতে পারেন কোথায় এই ত্রুটিটি ধরা পড়ে এবং অতিরিক্ত ডিবাগিং তথ্য তৈরি করতে পারে। "
নালপয়েন্টারএক্সেপশন: নুল কেসটি হ্যান্ডেল করুন বা একটি জোর দেওয়া যাতে এনপিই ছুঁড়ে না যায়। যদি আপনি একটি দৃser়তা রাখেন তবে অন্য দুটি ধরণের মধ্যে একটি। যদি সম্ভব হয় তবে ডিবাগিংটি চালিয়ে যান যেন এই দৃ as়তা প্রথম স্থানে ছিল।
অবৈধআর্গুমেন্ট এক্সেপশন: আপনার কল সাইটে আপনার কিছু ভুল আছে। যদি মানগুলি পাস করা হচ্ছে তবে অন্য কোনও ফাংশন থেকে আসে, তবে আপনি কেন একটি ভুল মান পাচ্ছেন তা খুঁজে বের করুন। যদি আপনি আপনার যুক্তিগুলির একটির মধ্যে দিয়ে যাচ্ছেন তবে কল স্ট্যাক ত্রুটিটি প্রচার করে ততক্ষণ আপনি ফাংশনটি খুঁজে না পেয়েছেন যা আপনি প্রত্যাশা করছেন না।
অবৈধ স্টেট এক্সেপশন: আপনি আপনার ক্রিয়াকে সঠিক ক্রমে কল করেননি। আপনি যদি আপনার একটি যুক্তি ব্যবহার করে থাকেন তবে সেগুলি পরীক্ষা করে দেখুন এবং সমস্যাটি বর্ণনা করে একটি অবৈধআর্গুমেন্ট এক্সেকশন ফেলে দিন। আপনি সমস্যাটি খুঁজে না পাওয়া পর্যন্ত আপনি স্ট্যাকের বিরুদ্ধে গালাগুলি প্রচার করতে পারেন।
যাইহোক, তাঁর বক্তব্যটি হ'ল আপনি কেবল অবৈধআর্গুমেন্টসেসরেশনগুলি স্ট্যাকের অনুলিপি করতে পারবেন। স্ট্যাকটিকে অবৈধভাবে স্টল আপ করার বা নালপয়েন্টারএকসেপ্টগুলি প্রচার করার কোনও উপায় নেই কারণ তাদের আপনার ফাংশনের সাথে কিছু করার ছিল।
সাধারণভাবে, বিকাশকারীকে কখনই নালপয়েন্টার এক্সসেপশন নিক্ষেপ করা উচিত নয় । এই ব্যতিক্রমটি রানটাইম দ্বারা ছুঁড়ে ফেলা হয় যখন কোডটি কোনও ভেরিয়েবলের মূল্য হ্রাস করার চেষ্টা করে re সুতরাং, যদি আপনার পদ্ধতিটি নাল মানটিকে একটি নালপয়েন্টার এক্সসেপশন উত্থাপনের বিপরীতে কেবল স্পষ্টভাবে নালকে অস্বীকার করতে চায় তবে আপনার একটি অবৈধআর্গুমেন্টেক্সপশন নিক্ষেপ করা উচিত।
আমি অন্য অবৈধ যুক্তিগুলি থেকে নুল আর্গুমেন্টগুলি একাকী করতে চেয়েছিলাম, তাই আমি আইএই থেকে নুলআরগমেন্টএক্সেপশন নামে একটি ব্যতিক্রম পেয়েছি। এমনকি ব্যতিক্রম বার্তাটি পড়ার প্রয়োজন ছাড়াই আমি জানি যে একটি নাল যুক্তি একটি পদ্ধতিতে পাস করা হয়েছিল এবং বার্তাটি পড়ে আমি জানতে পারি কোন যুক্তিটি শূন্য ছিল। আমি এখনও আইএই হ্যান্ডলারের সাহায্যে নুলআরগিউমেন্টএক্সেপশন ধরি, তবে আমার লগগুলিতে আমি কোথায় পার্থক্যটি দ্রুত দেখতে পাচ্ছি।
দ্বিধাবিজ্ঞান ... এগুলি কি ওভারল্যাপিং করছে? একটি সম্পূর্ণরূপে কেবল অ-ওভারল্যাপিং অংশগুলি দ্বৈতত্ত্ব তৈরি করতে পারে। আমি এটি দেখতে হিসাবে:
throw new IllegalArgumentException(new NullPointerException(NULL_ARGUMENT_IN_METHOD_BAD_BOY_BAD));NullPointerExceptionকিছুই করতে পারে না। একমাত্র জিনিস যা সাহায্য করতে পারে তা হ'ল IllegalNullPointerArgumentException extends IllegalArgumentException, NullPointerExceptionতবে আমাদের একাধিক উত্তরাধিকার নেই।
NullPointerException একটি রেফারেন্স ভেরিয়েবল যার বর্তমান মান হ'ল কোনও বস্তু অ্যাক্সেস করার চেষ্টা করার সময় নিক্ষেপ করা হয় null ।
IllegalArgumentException যখন কোনও পদ্ধতিটি প্রত্যাশার চেয়ে আলাদাভাবে ফর্ম্যাট করা একটি আর্গুমেন্ট গ্রহণ করে তখন ফেলে দেওয়া হয়।
আদর্শভাবে রানটাইম ব্যতিক্রম নিক্ষেপ করা উচিত নয়। আপনার দৃশ্যের জন্য একটি চেক করা ব্যতিক্রম (ব্যবসায় ব্যতিক্রম) তৈরি করা উচিত। কারণ এই ব্যতিক্রমগুলির কোনও একটি যদি ছুঁড়ে ফেলা হয় এবং লগ করা হয় তবে এটি লগগুলির মধ্য দিয়ে যাওয়ার সময় বিকাশকারীকে বিভ্রান্ত করে। পরিবর্তে ব্যবসায়ের ব্যতিক্রমগুলি সেই আতঙ্ক তৈরি করে না এবং লগগুলি সমস্যার সমাধানের সময় সাধারণত উপেক্ষা করা হয়।
উপরোক্ত দুটি ব্যাতিক্রমের লিঙ্কগুলি থেকে সংজ্ঞাগুলি হ'ল ইলিজালআরগামেন্টএক্সেপশন: কোনও পদ্ধতিতে একটি অবৈধ বা অনুপযুক্ত যুক্তি পাস করা হয়েছে তা বোঝাতে ছুড়ে দেওয়া হয়েছিল। নালপয়েন্টারএক্সেপশন: কোনও অ্যাপ্লিকেশন কোনও ক্ষেত্রে প্রয়োজনীয় কোনও ক্ষেত্রে নাল ব্যবহার করার চেষ্টা করলে নিক্ষেপ করা হয়।
এখানে বড় পার্থক্য হ'ল ইলিজালআরগমেন্টএক্সেপশনটি কোনও পদ্ধতির সাথে যুক্তি বৈধ কিনা তা পরীক্ষা করার সময় ব্যবহার করার কথা। নালপয়েন্টার এক্সসেপশনটি যখনই কোনও বস্তুটি "নাল" হয় তখন এটি "ব্যবহৃত" হচ্ছে ব্যবহার করার কথা।
আমি আশা করি যে এই দুটি দৃষ্টিভঙ্গি স্থাপন করতে সহায়তা করে।
যদি এটি "সেটার" হয়, বা অন্য কোথাও আমি পরে ব্যবহার করার জন্য সদস্য পাচ্ছি তবে আমি IllegalArgumentException ব্যবহার করতে চাই।
যদি এখনই পদ্ধতিটিতে আমি এটি ব্যবহার করতে যাচ্ছি (ডিরিফারেন্স), আমি একটি নলপয়েন্টার এক্সেকশনটি সক্রিয়ভাবে ছুঁড়ে ফেলি। রানটাইমটি এটি করার চেয়ে আমার এটি আরও ভাল লাগে, কারণ আমি একটি সহায়ক বার্তা সরবরাহ করতে পারি (মনে হয় রানটাইমটি এটিও করতে পারে তবে এটি অন্য দিনের জন্য ছড়িয়ে পড়ে)।
আমি যদি কোনও পদ্ধতিকে ওভাররাইড করছি তবে ওভাররাইড পদ্ধতি যেটি ব্যবহার করে তা আমি ব্যবহার করি।
আপনার একটি অবৈধআর্গুমেন্টএক্সেপশন নিক্ষেপ করা উচিত, কারণ এটি প্রোগ্রামারের কাছে এটি স্পষ্ট করে দেবে যে সে কিছু অবৈধ কাজ করেছে। বিকাশকারীরা ভিএম দ্বারা নিক্ষিপ্ত এনপিই দেখতে এতটাই অভ্যস্ত যে কোনও প্রোগ্রামার তাত্ক্ষণিকভাবে তার ত্রুটিটি বুঝতে পারে না এবং এলোমেলোভাবে ঘুরে দেখা শুরু করবে বা আরও খারাপ, আপনার কোডটিকে 'বগি' বলে দোষ দেবে।
এই ক্ষেত্রে, অবৈধ অরগমেন্ট এক্সেপশনটি আপনার এপিআই ব্যবহার করে ব্যবহারকারীর কাছে পরিষ্কার তথ্য জানায় যে "" বাতিল হওয়া উচিত নয় "। অন্য ফোরামের ব্যবহারকারীরা যেমন উল্লেখ করেছেন যে আপনি যদি আপনার এপিআই ব্যবহার করে ব্যবহারকারীর কাছে সঠিক তথ্য পৌঁছে দিতে চান তবে আপনি এনপিই ব্যবহার করতে পারবেন।
গ্যারিএফ এবং টুইট "ফলপ্রসূ জাভা" (যার শপথ নিয়ে আমি) রেফারেন্সগুলি এনপিই ব্যবহারের প্রস্তাব দেয় dropped এবং অন্যান্য ভাল এপিআইগুলি কীভাবে নির্মিত হয় তা সন্ধান করা আপনার এপিআই কীভাবে তৈরি করবেন তা দেখার সেরা উপায়।
আরেকটি ভাল উদাহরণ হ'ল স্প্রিং এপিআইগুলি দেখুন। উদাহরণস্বরূপ, org.springframework.beans.BeanUtils.instantiateClass (কনস্ট্রাক্টর কর্টর, অবজেক্ট [] আর্টস) এর একটি Assert.notNull (ctor, "কনস্ট্রাক্টর অবশ্যই নাল হবে না") লাইন রয়েছে। org.springframework.util.Assert.notNull (অবজেক্ট অবজেক্ট, স্ট্রিং মেসেজ) পদ্ধতিটি আর্গুমেন্ট (অবজেক্ট) পাস হয়েছে কিনা তা পরীক্ষা করে এটি যদি একটি নতুন IllegalArgumentException (বার্তা) ছুঁড়ে দেয় যা তখন org এ ধরা পড়ে। স্প্রিংফ্রেমওয়ার্ক.বেইনস.বিয়ান ইউটিলেস.ইনস্ট্যানিয়েট ক্লাস (...) পদ্ধতি।
আপনি যদি কোনও এনপিই নিক্ষেপ করতে পছন্দ করেন এবং আপনি আপনার পদ্ধতিতে যুক্তিটি ব্যবহার করছেন তবে স্পষ্টভাবে শূন্যতার জন্য এটি পরীক্ষা করা নিরর্থক এবং ব্যয়বহুল হতে পারে। আমি মনে করি ভিএম ইতিমধ্যে আপনার জন্য এটি করে।
NPEতবুও প্রোগ্রামাররা IAEচাইলে ভিএম এর আগে কথা বলতে পারে।