ত্রুটিগুলি "ধরা" দেওয়ার জন্য কি ব্যতিক্রমগুলি সরঞ্জাম হিসাবে ব্যবহার করা ঠিক আছে?

Question

আমি তাড়াতাড়ি সমস্যাগুলি ধরতে ব্যতিক্রমগুলি ব্যবহার করি। উদাহরণ স্বরূপ:

public int getAverageAge(Person p1, Person p2){
    if(p1 == null || p2 == null)
        throw new IllegalArgumentException("One or more of input persons is null").
    return (p1.getAge() + p2.getAge()) / 2;
}

আমার প্রোগ্রামটি nullএই ফাংশনে কখনই পাস করা উচিত নয় । আমি কখনই এর উদ্দেশ্য করি না। তবে আমরা সবাই জানি, প্রোগ্রামিংয়ে অযৌক্তিক স্টাফ হয়।

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

এখন, আপনি ঠিক বলেছেন, এক্ষেত্রে nullএটি কেবলমাত্র NullPointerExceptionঠিক তখনই ঘটায় , তাই এটি সর্বোত্তম উদাহরণ নাও হতে পারে।

তবে উদাহরণ হিসাবে উদাহরণস্বরূপ এমন একটি পদ্ধতি বিবেচনা করুন:

public void registerPerson(Person person){
    persons.add(person);
    notifyRegisterObservers(person); // sends the person object to all kinds of objects.
}

এই ক্ষেত্রে, nullপরামিতি হিসাবে একটি প্রোগ্রামের চারপাশে পাস করা হবে এবং অনেক পরে ত্রুটি হতে পারে, যা তাদের উত্সটিতে ফিরে পাওয়া শক্ত হবে।

ফাংশনটি এর মতো পরিবর্তন করা:

public void registerPerson(Person person){
    if(person == null) throw new IllegalArgumentException("Input person is null.");
    persons.add(person);
    notifyRegisterObservers(person); // sends the person object to all kinds of objects.
}

সমস্যাটি অন্যান্য জায়গায় অদ্ভুত ত্রুটির কারণ হওয়ার আগে আমাকে অনেক বেশি সমস্যা চিহ্নিত করার অনুমতি দেয়।

এছাড়াও, nullপ্যারামিটার হিসাবে একটি রেফারেন্স কেবল একটি উদাহরণ। এটি বিভিন্ন ধরণের সমস্যা হতে পারে, অবৈধ যুক্তি থেকে শুরু করে অন্য যে কোনও কিছুতে। তাদের তাড়াতাড়ি স্পষ্ট করা ভাল better

---

সুতরাং আমার প্রশ্নটি সহজভাবে: এটি কি ভাল অনুশীলন? সমস্যা-প্রতিরোধকারী সরঞ্জাম হিসাবে আমার ব্যতিক্রমগুলি কী ভাল? এটি কি ব্যতিক্রমগুলির বৈধ প্রয়োগ বা সমস্যাযুক্ত?

Comments

ডাউনওয়টার এই প্রশ্নটির মধ্যে কী ভুল তা ব্যাখ্যা করতে পারে?

— জর্জিও

"তাড়াতাড়ি ক্রাশ, প্রায়শই ক্রাশ"

— ব্রায়ান চেন

আক্ষরিকভাবেই এর ব্যতিক্রমগুলি রয়েছে।

— raptortech97

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

— ব্রায়ান 21

যেহেতু আপনি অবৈধ অরগমেন্ট এক্সেপশন নিক্ষেপ করছেন, তাই " ইনপুট ব্যক্তি" বলা বাড়াবাড়ি ।

— কেভিন

Answer 1

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

Comments

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

— মাইকেল শপসিন

এটি "ব্যর্থ দ্রুত" হিসাবেও পরিচিত

— কেউলজেপ

Answer 2

হ্যাঁ, ব্যতিক্রম ছোঁড়া একটি ভাল ধারণা। এগুলি তাড়াতাড়ি নিক্ষেপ করুন, প্রায়শই নিক্ষেপ করুন, উত্সাহ সহকারে নিক্ষেপ করুন।

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

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

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

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

public class PersonArgumentException extends IllegalArgumentException {
    public MyException(String message) {
        super(message);
    }
}

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

Comments

I've never actually met an application codebase for which I'd want (most) checks removed at runtime. তারপরে আপনি এমন কোডটি করেন নি যা কার্য সম্পাদন-সমালোচনা করে। আমি এখনই এমন কিছু নিয়ে কাজ করছি যা প্রতি সেকেন্ডে 37M অপ্স করে এবং সেগুলি ছাড়াই 42 এম এম সংকলন করে does জবাবগুলি বাইরের ইনপুটকে বৈধতা দেয় না, কোডটি সঠিক কিনা তা নিশ্চিত করার জন্য তারা সেখানে রয়েছে। আমার গ্রাহকরা আমার জিনিসগুলি ভাঙ্গা হয়নি বলে সন্তুষ্ট হয়ে একবার 13% বৃদ্ধি গ্রহণে বেশি খুশি।

— blrfl

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

— সেলালি অ্যাডোবর

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

— সেলালি অ্যাডোবর

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

— জোনাথন ইউনিস

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

— জোনাথন ইউনিস

Answer 3

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

সুতরাং হ্যাঁ, ডিফেন্সিভ প্রোগ্রামিং হ'ল বাগগুলি সনাক্ত এবং দ্রুত সমাধানের জন্য কার্যকর কার্যকর পদ্ধতি approach অন্যদিকে, এটি ওভারডোন করা যেতে পারে, বিশেষত নাল রেফারেন্স সহ।

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

আরও বাস্তব উদাহরণের জন্য, আপনি assertবিবৃতি ব্যবহার করতে পারেন , যা:

1. লিখতে এবং পড়ার জন্য সংক্ষিপ্ত:

       assert p1 : "p1 is null";
       assert p2 : "p2 is null";
   

2. আপনার পদ্ধতির জন্য বিশেষভাবে ডিজাইন করা হয়েছে। এমন একটি পৃথিবীতে যেখানে আপনার দাবি এবং ব্যতিক্রম উভয়ই রয়েছে, আপনি সেগুলি নিম্নলিখিত হিসাবে আলাদা করতে পারেন:

   • গবেষকেরা জন্য ত্রুটি প্রোগ্রামিং ( "/ * এই ঘটতে কখনও উচিত * /"),
   • ব্যতিক্রমসমূহ জন্য কোণ ক্ষেত্রে (ব্যতিক্রমী কিন্তু সম্ভাব্য পরিস্থিতিতে)

সুতরাং, আপনার অ্যাপ্লিকেশনগুলির ইনপুট এবং / অথবা আপনার অ্যাপ্লিকেশনটির অবস্থান সম্পর্কে দৃump়তা সহ আপনার অনুমানগুলি প্রকাশ করে পরবর্তী বিকাশকারীকে আপনার কোডের উদ্দেশ্যটি আরও কিছুটা বুঝতে দিন।

একটি স্ট্যাটিক বিশ্লেষক (যেমন সংকলক) খুব সুখী হতে পারে।

অবশেষে, একক স্যুইচ ব্যবহার করে মোতায়েন করা অ্যাপ্লিকেশন থেকে দাবিগুলি সরানো যেতে পারে। তবে সাধারণত বললে, এর সাথে দক্ষতার উন্নতি করার প্রত্যাশা করবেন না: রানটাইমের সময় দৃser় চেকগুলি নগন্য।

Answer 4

যতদূর আমি জানি বিভিন্ন প্রোগ্রামাররা একটি সমাধান বা অন্যটিকে পছন্দ করেন।

প্রথম সমাধানটি সাধারণত বেশি পছন্দ করা হয় কারণ এটি আরও সংক্ষিপ্ত, বিশেষত, আপনাকে বিভিন্ন কার্যক্রমে বার বার একই অবস্থা পরীক্ষা করতে হবে না।

আমি দ্বিতীয় সমাধানটি খুঁজে পাই, যেমন

public void registerPerson(Person person){
    if(person == null) throw new IllegalArgumentException("Input person is null.");
    persons.add(person);
    notifyRegisterObservers(person); // sends the person object to all kinds of objects.
}

আরও শক্ত, কারণ

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

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

Comments

কারণ প্রদান করা ("ইনপুট ব্যক্তি নাল।") সমস্যাটি বুঝতে সহায়তা করে, যখন কোনও লাইব্রেরির কিছু অস্পষ্ট পদ্ধতি ব্যর্থ হয় তখন এর বিপরীতে।

— ফ্লোরিয়ান এফ

Answer 5

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

তবে কিছুটা আলাদা উদাহরণ দেখা যাক।

class PersonCalculator {
    PersonCalculator(Person p) {
        if (p == null) throw new ArgumentNullException("p");
        _p = p;
    }

    void Calculate() {
        // Do something to p
    }
}

কনস্ট্রাক্টারে যদি কোনও যুক্তি যাচাই না করা হয়, NullReferenceExceptionকল করার সময় আপনি একটি পেয়েছিলেন Calculate।

কিন্তু কোডের ভাঙা অংশটি না ছিল Calculateফাংশন, না ফাংশনের গ্রাহক Calculate। কোডের ভাঙা অংশটি হ'ল এমন কোড যা PersonCalculatorনাল দিয়ে নির্মাণের চেষ্টা করে Person- তাই আমরা এখানে ব্যতিক্রম ঘটতে চাই।

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

Answer 6

আপনার দেওয়া উদাহরণগুলিতে নয়।

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

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

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

Answer 7

আপনার উদাহরণ ফাংশনে, আমি আপনাকে কোনও চেক না করে পছন্দ করব এবং কেবল এটি হওয়ার অনুমতি দেব NullReferenceException।

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

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

আপনার কার্যক্রমে ডিজাইন-সময় ত্রুটির পরিস্থিতিটি সহায়তা করতে আপনি যা করতে পারেন তা আসলে কিছুই নেই, সুতরাং ব্যর্থতাটি এটি পরিবর্তন না করেই ঘটুক।

Comments

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

— জর্জিও

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

— জর্জিও

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

— জর্জিও

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

— ফ্লোরিয়ান এফ

প্রশ্নটি কোনও ভাষা নির্দিষ্ট করে না, সুতরাং উদাহরণস্বরূপ নির্ভর করা RuntimeExceptionকোনও বৈধ অনুমান নয়।