কেন প্রাকৃতিকভাবে এটি স্বাভাবিকভাবে ঘটতে দেওয়া থেকে নুলপয়েন্টারএক্সসেপশন স্পষ্টভাবে ছুঁড়ে ফেলা হয়?

Question

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

public V computeIfPresent(K key,
                          BiFunction<? super K, ? super V, ? extends V> remappingFunction) {
    if (remappingFunction == null)
        throw new NullPointerException();
    Node<K,V> e; V oldValue;
    int hash = hash(key);
    if ((e = getNode(hash, key)) != null &&
        (oldValue = e.value) != null) {
        V v = remappingFunction.apply(key, oldValue);
        if (v != null) {
            e.value = v;
            afterNodeAccess(e);
            return v;
        }
        else
            removeNode(hash, key, null, false, true);
    }
    return null;
}

Comments

কোডিংয়ের মূল পয়েন্টটি হ'ল উদ্দেশ্য

— ভয়েরি ওয়াম্ব্যাট

এটি আপনার প্রথম প্রশ্নের জন্য খুব ভাল প্রশ্ন! আমি কিছু ছোটখাটো সম্পাদনা করেছি; আমি আশা করি আপনি কিছু মনে করবেন না। আমি আপনাকে ধন্যবাদ এবং এটির প্রথম প্রশ্ন হিসাবে এটি সম্পর্কে নোটটি সরিয়েছি কারণ সাধারণত এই ধরণের জিনিসটি এসও প্রশ্নের অংশ নয়।

— ডেভিড কনরাড

আমি সি # কনভেনশন হ'ল ArgumentNullException(এর পরিবর্তে NullReferenceException) এরকম ক্ষেত্রে উত্থাপন করা - আপনি NullPointerExceptionএখানে কেন স্পষ্টত উত্থাপন করবেন (এটি ভিন্ন ভিন্ন নয় ) এটি আসলেই একটি ভাল প্রশ্ন ।

— ইজোশুয়াস - মনিকা

@ ইজুশুয়া নিক্ষেপ করবেন বা নালার পক্ষে যুক্তি দেওয়া এটি একটি পুরানো বিতর্ক । জেডিকে সম্মেলনটি পরেরটি। IllegalArgumentExceptionNullPointerException

— shmosel

বাস্তব সমস্যাটি হ'ল তারা একটি ত্রুটি ফেলে এবং সমস্ত ত্রুটি ফেলে দেয় যা এই ত্রুটির দিকে পরিচালিত করে । এই মনে হয় IS প্রকৃত সোর্স কোড। একটি সাধারণ রক্তাক্ত স্ট্রিং বার্তাও নয়। দু: খিত।

— মার্টিন বা

Answer 1

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

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

অভিপ্রায়: ব্যতিক্রম স্পষ্টভাবে ছুঁড়ে ফেলা এটি রক্ষণাবেক্ষণকারীদের কাছে পরিষ্কার করে দেয় যে ত্রুটিটি উদ্দেশ্যমূলকভাবে রয়েছে এবং এর পরিণতি সম্পর্কে লেখক সচেতন ছিলেন।

ধারাবাহিকতা: যদি ত্রুটিটি স্বাভাবিকভাবেই ঘটতে দেওয়া হয়, তবে এটি প্রতিটি দৃশ্যে না ঘটে। যদি কোনও ম্যাপিং পাওয়া যায় না, উদাহরণস্বরূপ, remappingFunctionকখনই ব্যবহৃত হবে না এবং ব্যতিক্রম নিক্ষেপ করা হবে না। আগাম ইনপুট বৈধকরণ আরও নির্বিচার আচরণ এবং পরিষ্কার ডকুমেন্টেশন জন্য অনুমতি দেয় ।

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

Comments

এছাড়াও: এই জায়গা থেকে ব্যতিক্রমটি ছুঁড়ে ফেলা হয় ঠিক একই স্থানে যা পরীক্ষা করা হয় তার সাথে বেঁধে দেওয়া হয়। এটি ব্যতীত, ব্যতিক্রমগুলি একাধিক ভেরিয়েবলের নাল হওয়ার কারণে হতে পারে।

— জেনস স্কাউডার 12'17

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

— টমাস

যদিও এই স্নিপেট এটি না করে আপনি new NullPointerException(message)কন্সট্রাক্টরটি কী নাল তা স্পষ্ট করতে ব্যবহার করতে পারেন । আপনার উত্স কোডটিতে অ্যাক্সেস নেই এমন লোকদের পক্ষে ভাল। এমনকি তারা Objects.requireNonNull(object, message)ইউটিলিটি পদ্ধতিতে জেডিকে 8 এ এটি একটি ওয়ান-লাইনার তৈরি করেছে ।

— রবিন

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

— নোহ স্পুরিয়ার

@ থমাস ভাল পয়েন্ট। শমোসেল: থমাসের বক্তব্য ব্যর্থ-দ্রুত বিন্দুতে আবদ্ধ হতে পারে তবে এটি এক ধরণের সমাহিত। এটি একটি গুরুত্বপূর্ণ যথেষ্ট ধারণা যা এর নিজস্ব নাম: ব্যর্থতা পারমাণবিকতা । ব্লাচ, কার্যকর জাভা , আইটেম 46 দেখুন It এটির ব্যর্থগতির চেয়ে দৃ stronger় শব্দার্থক শব্দ রয়েছে। আমি এটিকে আলাদা বিন্দুতে ডাকার পরামর্শ দেব। সামগ্রিকভাবে দুর্দান্ত উত্তর, বিটিডাব্লু। +1

— স্টুয়ার্ট

Answer 2

এটি স্পষ্টতা, ধারাবাহিকতা এবং অতিরিক্ত, অপ্রয়োজনীয় কাজ সম্পাদিত হওয়া থেকে রোধ করার জন্য।

পদ্ধতির শীর্ষে কোনও প্রহরী ধারা না থাকলে কী হবে তা বিবেচনা করুন। এটি সর্বদা কল করত hash(key)এবং এনপিই নিক্ষেপের আগে পাস করার getNode(hash, key)সময়ও ।nullremappingFunction

আরও খারাপ, যদি ifশর্তটি হয় falseতবে আমরা elseশাখাটি গ্রহণ করি , যা মোটেও ব্যবহার করে না remappingFunction, যার অর্থ একটি nullপাস করার পরে পদ্ধতিটি সর্বদা এনপিই নিক্ষেপ করে না ; এটি মানচিত্রের রাজ্যের উপর নির্ভর করে কিনা।

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

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

Answer 3

@ Shmosel এর দুর্দান্ত উত্তর দ্বারা তালিকাভুক্ত কারণগুলি ছাড়াও ...

পারফরম্যান্স: জেভিএমকে তা না করার পরিবর্তে এনপিই স্পষ্টভাবে ছোঁড়াতে পারফরম্যান্স সুবিধা (কিছু জেভিএম) থাকতে পারে / থাকতে পারে।

এটি জাভা ইন্টারপ্রেটার এবং জেআইটি সংকলক নাল পয়েন্টারগুলির অধিবেশন সনাক্ত করতে যে কৌশল গ্রহণ করে তার উপর নির্ভর করে। একটি কৌশল হ'ল নাল পরীক্ষা না করা, বরং পরিবর্তে সিএসএসইজিভিতে ফাঁদে ফেলা উচিত যখন কোনও নির্দেশ ঠিকানা 0. অ্যাক্সেস করার চেষ্টা করে তখন রেফারেন্সটি সর্বদা বৈধ থাকে তবে এই ক্ষেত্রে এটি সবচেয়ে দ্রুত পদ্ধতি, তবে এনপিই ক্ষেত্রে এটি ব্যয়বহুল ।

nullকোডের জন্য একটি স্পষ্ট পরীক্ষা এনজিইগুলি ঘন ঘন এমন দৃশ্যে সিগসাইজিভি পারফরম্যান্স হিট এড়াতে পারে।

(আমি সন্দেহ করি যে এটি একটি আধুনিক জেভিএম-এর একটি উপযুক্ত মাইক্রো-অপ্টিমাইজেশন হতে পারে তবে এটি অতীতেও হতে পারে))

---

সামঞ্জস্যতা: ব্যতিক্রমটিতে কোনও বার্তা না থাকার সম্ভবত কারণটি নিজেই JVM দ্বারা নিক্ষিপ্ত এনপিইগুলির সাথে সামঞ্জস্যতার জন্য। সম্মতিযুক্ত জাভা প্রয়োগে, জেভিএম দ্বারা নিক্ষিপ্ত একটি এনপিইতে একটি nullবার্তা রয়েছে। (অ্যান্ড্রয়েড জাভা আলাদা)

Answer 4

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

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

ঘটনাক্রমে, আপনি যদি এমন কিছু উত্থাপন করেন ArgumentNullExceptionবা IllegalArgumentException, যা চেক করার পয়েন্টের অংশ: আপনি "স্বাভাবিকভাবে" পাওয়ার চেয়ে আলাদা ব্যতিক্রম চান।

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

Comments

মাঝের অনুচ্ছেদের জন্য +1। আমি যুক্তি দিয়ে বলব যে প্রশ্নের মধ্যে থাকা কোডটি 'নতুন অবৈধআর্গুমেন্টএক্সেপশন ("রিম্যাপিং ফাংশন নਾਲ হতে পারে না") নিক্ষেপ করা উচিত;' ভুলটি কী ছিল তা অবিলম্বে এটি স্পষ্ট। দেখানো এনপিই কিছুটা অস্পষ্ট।

— ক্রিস পার্কার

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

— ভিজিআর

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

— যোশুয়াস - মনিকা

আমি এটি অনেকটাই বলব, আমি বর্ণিত হিসাবে সবসময় একটি অবৈধআর্গুমেন্টেক্সপশন নিক্ষেপ করব। আমি যখন অনুভব করি যে কনভেনশনটি বোবা always

— ক্রিস পার্কার

@ পিটারজির্কেন্স - হ্যাঁ, কারণ নলপয়েন্টারএক্সেপশন লাইন 35 ইলিজালআরগমেন্টএক্সেপশন ("ফাংশন নাল হতে পারে না") লাইন 35 এর চেয়ে অনেক বেশি ভাল? সিরিয়াসলি?

— ক্রিস পার্কার

Answer 5

এটি তাই আপনি যখন মানচিত্রটি ব্যবহার করছেন তখন তার চেয়ে বরং ত্রুটি ঘটানোর সাথে সাথেই আপনি ব্যতিক্রমটি পেয়ে যাবেন এবং কেন এটি ঘটেছে তা বুঝতে পারবেন না।

Answer 6

এটি একটি আপাতদৃষ্টিতে ত্রুটিযুক্ত ত্রুটি শর্তটিকে একটি পরিষ্কার চুক্তি লঙ্ঘনে রূপান্তরিত করে: ফাংশনটির সঠিকভাবে কাজ করার জন্য কিছু পূর্বশর্ত রয়েছে, সুতরাং এটি পূর্বে তাদের পরীক্ষা করে, তাদের পূরণের জন্য জোর করে।

এর প্রভাবটি হ'ল, আপনি computeIfPresent()যখন এটির ব্যতিক্রমটি পান তখন আপনাকে ডিবাগ করতে হবে না । একবার আপনি যখন দেখেন যে ব্যতিক্রম পূর্বশর্ত চেক থেকে আসে, আপনি জানেন যে আপনি ফাংশনটিকে একটি অবৈধ যুক্তি দিয়ে ডেকেছিলেন। যদি চেকটি না থাকে তবে আপনার computeIfPresent()নিজের মধ্যে এমন কিছু বাগ রয়েছে যা ব্যতিক্রম ছুঁড়ে ফেলার সম্ভাবনাটি বাদ দিতে হবে exc

স্পষ্টতই, জেনেরিক নিক্ষেপ NullPointerExceptionকরা একটি সত্যই খারাপ পছন্দ, কারণ এটি কোনও চুক্তি লঙ্ঘন এবং নিজেই সংকেত দেয় না। IllegalArgumentExceptionএকটি ভাল পছন্দ হবে।

---

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

void MyClass_foo(MyClass* me, int (*someFunction)(int)) {
    assert(me);
    assert(someFunction);

    ...
}

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

Comments

assert something != null;তবে -assertionsঅ্যাপ্লিকেশন চালানোর সময় এর জন্য পতাকাটির প্রয়োজন । তাহলে -assertionsপতাকা সেখানে নেই জাহির শব্দ একটি AssertionException নিক্ষেপ করা হবে না

— Zoe

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

— ইজোশুয়াস - মনিকা

Answer 7

কারণ এটি প্রাকৃতিকভাবে না ঘটানো সম্ভব । এর মতো কোডের অংশটি দেখুন:

bool isUserAMoron(User user) {
    Connection c = UnstableDatabase.getConnection();
    if (user.name == "Moron") { 
      // In this case we don't need to connect to DB
      return true;
    } else {
      return c.makeMoronishCheck(user.id);
    }
}

(অবশ্যই কোডের মান সম্পর্কে এই নমুনায় অসংখ্য সমস্যা রয়েছে perfect নিখুঁত নমুনাটি কল্পনা করতে অলসতায় দুঃখিত)

পরিস্থিতি কখন cব্যবহার করা NullPointerExceptionহবে না এবং c == nullসম্ভব হলেও নিক্ষেপ করা হবে না ।

আরও জটিল পরিস্থিতিতে এ জাতীয় কেসগুলি খুঁজে পাওয়া খুব সহজ নয়। এ কারণেই সাধারণ চেক if (c == null) throw new NullPointerException()করা ভাল।

Comments

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

— দিমিত্রি গ্রিগরিয়েভ

Answer 8

আরও ক্ষতি রক্ষা করা, বা বেমানান অবস্থায় যেতে ইচ্ছাকৃত।

Answer 9

এখানে অন্যান্য দুর্দান্ত উত্তরগুলি ছাড়াও আমি কয়েকটি কেস যুক্ত করতে চাই।

আপনি যদি নিজের ব্যতিক্রম তৈরি করেন তবে আপনি একটি বার্তা যুক্ত করতে পারেন

আপনি নিজের ছুঁড়ে ফেললে NullPointerExceptionআপনি একটি বার্তা যুক্ত করতে পারেন (যা আপনার অবশ্যই হওয়া উচিত!)

ডিফল্ট বার্তাটি একটি হল nullথেকে new NullPointerException()এবং সমস্ত পদ্ধতি এটি ব্যবহার, উদাহরণস্বরূপ Objects.requireNonNull। আপনি যদি সেই নালটি মুদ্রণ করেন তবে এটি খালি স্ট্রিংয়ে অনুবাদও করতে পারে ...

কিছুটা সংক্ষিপ্ত এবং তথ্যহীন ...

স্ট্যাক ট্রেস প্রচুর তথ্য দেবে, তবে ব্যবহারকারীর জানার জন্য তাদের কোডটি খনন করতে হবে এবং সঠিক সারিটি দেখতে হবে ull

এখন কল্পনা করুন যে এনপিই জাল করে নেট থেকে প্রেরণ করা হচ্ছে, যেমন একটি ওয়েব সার্ভিস ত্রুটিতে একটি বার্তা হিসাবে, সম্ভবত বিভিন্ন বিভাগ বা এমনকি সংস্থার মধ্যে। সবচেয়ে খারাপ পরিস্থিতি, কেউ কী বুঝতে পারে তা বুঝতে পারে না null...

চেইনযুক্ত পদ্ধতি কলগুলি আপনার অনুমান করতে থাকবে

একটি ব্যতিক্রম কেবলমাত্র ব্যতিক্রমটি ঘটেছিল তা আপনাকে জানায়। নিম্নলিখিত সারিটি বিবেচনা করুন:

repository.getService(someObject.someMethod());

আপনি একটি NPE এবং এ, যার মধ্যে এক এই সারিতে পয়েন্ট যদি repositoryএবং someObjectছিল নাল?

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

প্রচুর ইনপুট প্রক্রিয়া করার সময় ত্রুটিগুলি সনাক্তকারী তথ্য দিতে হবে

ভাবুন যে আপনার প্রোগ্রামটি কয়েক হাজার সারি দিয়ে একটি ইনপুট ফাইল প্রক্রিয়া করছে এবং হঠাৎ একটি নালপয়েন্টার এক্সসেপশন রয়েছে। আপনি জায়গাটি দেখুন এবং বুঝতে পারেন যে কিছু ইনপুট ভুল ছিল ... কী ইনপুট? এই ফাইলটিতে কোন সারিটি ঠিক করতে হবে তা বোঝার জন্য আপনার সারি নম্বর, সম্ভবত কলাম বা পুরো সারি পাঠ্য সম্পর্কে আরও তথ্য প্রয়োজন।