ত্রুটি দমন বিরুদ্ধে তর্ক

Question

আমি আমাদের একটি প্রকল্পে এর মতো কোডের একটি অংশ পেয়েছি:

    SomeClass QueryServer(string args)
    {
        try
        {
            return SomeClass.Parse(_server.Query(args));
        }
        catch (Exception)
        {
            return null;
        }
    }

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

এই জাতীয় ত্রুটিগুলি সম্পূর্ণরূপে দমন করা কখন উপযুক্ত?

Comments

এরিক লিপার্ট ভেক্সিং ব্যতিক্রম বলে একটি দুর্দান্ত ব্লগ পোস্ট লিখেছেন যেখানে তিনি ব্যতিক্রমকে ৪ টি বিভিন্ন বিভাগে শ্রেণিবদ্ধ করেছেন এবং প্রত্যেকটির জন্য সঠিক পন্থাটি কী তা বোঝায়। সি # দৃষ্টিকোণ থেকে রচিত তবে ভাষাগুলিতে প্রযোজ্য, আমি বিশ্বাস করি।

— ড্যামিয়েন_এ_বিশ্বাসীরা

আমি বিশ্বাস করি যে কোড "ব্যর্থ-দ্রুত" নীতি লঙ্ঘন করে। উচ্চ সম্ভাবনা রয়েছে যে এতে প্রকৃত বাগ লুকিয়ে রয়েছে।

— ইউফোরিক

thecodelesscode.com/case/224

— ড্যান

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

— usr ডিরেক্টরির

আপনার প্রোগ্রামটিকে খাড়া অবস্থানে পেরেক করবেন না

— কেভিন - মনিকা পুনরায়

Answer 1

একগুচ্ছ লাইব্রেরি ব্যবহার করে হাজার হাজার ফাইলের সাথে কোডটি কল্পনা করুন। কল্পনা করুন যে তাদের সকলকে এভাবে কোড করা হয়েছে।

কল্পনা করুন, উদাহরণস্বরূপ, আপনার সার্ভারের আপডেটের কারণে একটি কনফিগারেশন ফাইল অদৃশ্য হয়ে যায়; এবং এখন আপনি সমস্ত স্ট্যাক ট্রেস হ'ল একটি নাল পয়েন্টার ব্যতিক্রম যখন আপনি এই শ্রেণিটি ব্যবহার করার চেষ্টা করেন: আপনি কীভাবে এটি সমাধান করবেন? এটি কয়েক ঘন্টা সময় নিতে পারে, যেখানে অন্তত কেবলমাত্র ফাইলের কাঁচা স্ট্যাক ট্রেস লগইন করা হয়নি [ফাইলের পথ] আপনাকে মুহুর্তের মধ্যে সমাধান করতে সক্ষম করতে পারে।

বা আরও খারাপ: আপনি যে লাইব্রেরিগুলি আপডেটের পরে ব্যবহার করেন সেগুলির মধ্যে একটি ব্যর্থতা যা পরে আপনার কোড ক্রাশ করে। আপনি কীভাবে এটি লাইব্রেরিতে ফিরে যেতে পারেন?

এমনকি দৃ rob় ত্রুটি না করে কেবল পরিচালনা করছেন just

throw new IllegalStateException("THIS SHOULD NOT HAPPENING")

অথবা

LOGGER.error("[method name]/[arguments] should not be there")

আপনার কয়েক ঘন্টা সময় বাঁচাতে পারে।

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

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

সেরা অভ্যাসগুলি বেশিরভাগ ক্ষেত্রে অনুসরণ করা জিনিস, সম্ভবত 80%, হতে পারে 99%, তবে আপনি সর্বদা একটি প্রান্ত ক্ষেত্রে পাবেন যেখানে সেগুলি প্রয়োগ হয় না। সেক্ষেত্রে আপনি অন্যদের (বা এমনকি নিজেরাই) যারা এই কোডগুলি কয়েক মাস পরে পড়বেন তার জন্য কেন অনুশীলনটি অনুসরণ করছেন না বলে একটি মন্তব্য করুন।

Comments

আপনাকে কেন একটি মন্তব্যে এটি করা দরকার বলে ব্যাখ্যা করার জন্য +1। কোনও ব্যাখ্যা ছাড়াই ব্যতিক্রম গিলে ফেললে আমার মাথায় সর্বদা অ্যালার্মের ঘণ্টা বাড়ে।

— jpmc26

তার সাথে আমার সমস্যাটি হ'ল মন্তব্যটি সেই কোডটির অভ্যন্তরে আটকে আছে। ফাংশনের ভোক্তা হিসাবে, আমি কখনও এই মন্তব্যটি দেখতে পাব না।

— কর্সিকা

@ jpmc26 যদি ব্যতিক্রমটি পরিচালনা করা হয় (উদাহরণস্বরূপ একটি বিশেষ মান ফেরত দিয়ে), এটি ব্যতিক্রম-গিলে একেবারেই নয়।

— উত্সাহক

ক্রিসিকা একজন গ্রাহক যদি ফাংশনটি সঠিকভাবে তার কাজ করে তবে প্রয়োগের বিস্তারিত জানার প্রয়োজন নেই to হতে পারে এপাচি লাইব্রেরিতে বা বসন্তে তারা এর মধ্যে কিছু রয়েছে এবং আপনি এটি জানেন না।

— ওয়ালফ্র্যাট

@ ডেডুপ্লিকেটর হ্যাঁ তবে আপনার অ্যালগরিদমের অংশ হিসাবে ক্যাচ ব্যবহার করা খুব ভাল

— অভ্যাস

Answer 2

এই প্যাটার্নটি দরকারী এমন কিছু ক্ষেত্রে রয়েছে - তবে এগুলি সাধারণত তখন ব্যবহৃত হয় যখন উত্পন্ন ব্যতিক্রম কখনই হওয়া উচিত ছিল না (যেমন যখন ব্যতিক্রমগুলি স্বাভাবিক আচরণের জন্য ব্যবহৃত হয়)।

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

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

Comments

"ব্যবহৃত ব্যতিক্রম কখনই হওয়া উচিত ছিল না" ব্যবহৃত হয় "এরকম কোনও জিনিস নেই। ব্যতিক্রমের পয়েন্টটি হ'ল কোনও কিছু মারাত্মক ভুল হয়েছে signal

— ইউফোরিক

@ ইউফোরিক তবে কখনও কখনও কোনও গ্রন্থাগারের লেখক সেই লাইব্রেরির শেষ ব্যবহারকারীর উদ্দেশ্য জানেন না। একজন ব্যক্তির "ভয়াবহ ভুল" অন্য কারও সহজেই পুনরুদ্ধারযোগ্য অবস্থা হতে পারে।

— সাইমন বি

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

— ম্যাট ক্রাউস

@ ইউফোরিক, "ফাইলটি পাওয়া যায় না, এটি কোনও সাধারণ ব্যতিক্রম নয় file ফাইলটি উপস্থিত না থাকলে সম্ভাবনা আছে কিনা আপনার প্রথমে পরীক্ষা করা উচিত" " না! না! না! না! এটি পারমাণবিক অপারেশনগুলির সম্পর্কে ক্লাসিক ভুল চিন্তাভাবনা। ফাইলটি উপস্থিত রয়েছে কিনা এবং এটি অ্যাক্সেস করছে কিনা তা যাচাই করার মধ্যে আপনার মধ্যে মুছে ফেলা হতে পারে। এই ধরনের পরিস্থিতিগুলি পরিচালনা করার একমাত্র সঠিক উপায় হ'ল এটি অ্যাক্সেস করা এবং ব্যতিক্রমগুলি ঘটলে তাদের পরিচালনা করা, উদাহরণস্বরূপ nullযদি আপনার পছন্দের ভাষাটি সেরা প্রস্তাব দিতে পারে তবে ফিরে এসে returning

— ডেভিড আরনো

@ ইউফোরিক: সুতরাং, ফাইলটি কমপক্ষে দু'বার অ্যাক্সেস করতে না পারা হ্যান্ডেল করার জন্য কোডটি লিখুন? এটি ডিআরওয়াই লঙ্ঘন করে এবং অমীমাংসিত কোডটি ভঙ্গ কোড is

— উত্সাহক

Answer 3

এটি 100% প্রসঙ্গ নির্ভর। যদি এই জাতীয় ফাংশনটির কলারের কোথাও কোথাও ত্রুটি প্রদর্শন বা লগ করার প্রয়োজনীয়তা থাকে তবে তা অবশ্যই বোকামি non যদি কলকারী সমস্ত ত্রুটি বা ব্যতিক্রম বার্তাগুলি উপেক্ষা করে থাকে তবে ব্যতিক্রম বা এর বার্তাটি ফেরত দেওয়ার পক্ষে খুব বেশি অর্থ হবে না। যখন প্রয়োজন হয় কোনও কারণ প্রদর্শন না করেই কেবল কোডটি সমাপ্ত করা যায়, তারপরে একটি কল

   if(QueryServer(args)==null)
      TerminateProgram();

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

  result = QueryServer(args);
  if(result!=null)
      DoSomethingMeaningful(result);
  // else ??? Mask the error and let the user run into trouble later

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

Answer 4

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

দুটি পরিস্থিতি নিম্নলিখিত:

1. যখন ব্যতিক্রমটিকে ব্যতিক্রমী রাষ্ট্র হিসাবে বিবেচনা করা হত না

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

শ্রেণীর কিছু alচ্ছিক গুণাবলী মনে আসতে পারে।

২. আপনি যখন কোনও অ্যাপ্লিকেশনটিতে ইতিমধ্যে ব্যবহৃত ইন্টারফেস ব্যবহার করে একটি লাইব্রেরি একটি নতুন (আরও ভাল, দ্রুত?) সরবরাহ করছেন তখন

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

লাইব্রেরির একটি নতুন সংস্করণ আসে, বা সম্ভবত সম্পূর্ণ ভিন্ন লাইব্রেরি একই কার্যকারিতা সরবরাহ করে, যা nullএস ফেরানোর পরিবর্তে ব্যতিক্রম ছুঁড়েছে এবং আপনি এটি ব্যবহার করতে চান।

আপনি আপনার মূল অ্যাপ্লিকেশনটিতে ব্যতিক্রমগুলি ফাঁস করতে চান না, সুতরাং আপনি এই নতুন নির্ভরতা মোড়ানোর জন্য আপনি তৈরি অ্যাডাপ্টারে সুপারস করে লগ ইন করুন।

---

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

আমি ব্যক্তিগতভাবে কেবল প্রথম ক্ষেত্রে ব্যতিক্রমী দমন ব্যবহার করি। আমি কেবলমাত্র এটি দ্বিতীয় ক্ষেত্রে ব্যবহার করেছি, যখন আমাদের কাছে বাজেট না থাকলে বাকী প্রয়োগগুলি ব্যতিরেকে বাদ দিয়ে কাজ করতে হবে null।

Answer 5

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

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

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

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

Comments

এটি প্রশ্নের উত্তর দিতে ব্যর্থ হয়েছে কারণ ব্যতিক্রমের বিবরণ না জেনে একটি ব্যতিক্রম পরিচালনা করা! = নিঃশব্দে একটি (জেনেরিক) ব্যতিক্রম গ্রহণ করা।

— তাইমির

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

— সুপারক্যাট

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

— জোমরনো

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

— সুপারক্যাট

Answer 6

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

তাহলে তারা কী করবে? তারা কী ব্যতিক্রমের স্বাদ ফিরে পাচ্ছে তা দেখার জন্য তারা ব্যতিক্রমটি পরিচালনা করতে কোড যুক্ত করবে। গ্রেট। তবে যদি ব্যতিক্রম হ্যান্ডলারটি বাকি থাকে তবে মূল কলার আর পিছনে ফিরে আসে না এবং অন্য কোথাও কিছু ভেঙে যায়।

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

Comments

"সিরিয়াসলি জড়" - আপনি সম্ভবত "গুরুতর অক্ষম" বলতে চাইছেন?

— এসোটেরিক পর্দার নাম

@ এসোটেরিকস্ক্রিনাম নামটি বেছে নিন ... ;-)

— রবি ডি

Answer 7

আমি উদাহরণগুলি দেখেছি যেখানে তৃতীয় পক্ষের গ্রন্থাগারগুলির সম্ভাব্য কার্যকর পদ্ধতি ছিল, তবে কিছু ক্ষেত্রে ব্যতিক্রম করে যা আমার পক্ষে কাজ করা উচিত। আমি কি করতে পারি?

• আমার যা প্রয়োজন ঠিক তা বাস্তবায়ন করুন। একটি নির্দিষ্ট সময়সীমা এ কঠিন হতে পারে।
• তৃতীয় পক্ষের কোডটি সংশোধন করুন। তবে তারপরে আমাকে প্রতিটি আপগ্রেডের সাথে মার্জ সংঘাতের সন্ধান করতে হবে।
• ব্যতিক্রমটিকে সাধারণ নাল পয়েন্টার, বুলিয়ান মিথ্যা বা যাই হোক না কেন রূপান্তর করতে একটি মোড়কের পদ্ধতি লিখুন।

উদাহরণস্বরূপ, গ্রন্থাগার পদ্ধতি

public foo findFoo() {...} 

প্রথম foo প্রদান করে, তবে কিছুই না থাকলে এটি একটি ব্যতিক্রম ছুঁড়ে দেয়। তবে আমার যা দরকার তা হ'ল প্রথম ফু বা নাল ফেরানোর পদ্ধতি। সুতরাং আমি এটি একটি লিখুন:

public foo myFindFoo() {
    try {
        return findFoo() 
    } 
    catch (NoFooException ex) {
        return null;
    }
}

ঝরঝরে নয়। তবে মাঝে মাঝে ব্যবহারিক সমাধান।

Comments

"ব্যতিক্রমগুলি যেখানে তারা আপনার জন্য কাজ করা উচিত" নিক্ষেপ করার অর্থ কী?

— কর্সিকা

@ কর্সিকা, আমার মনে যে উদাহরণটি আসে তা হ'ল তালিকা বা অনুরূপ ডেটা কাঠামোর মাধ্যমে অনুসন্ধান পদ্ধতি methods তারা কিছু না পেলে কি তারা ব্যর্থ হয় বা তারা কোনও শূন্যমূল্য দেয় না? অন্য উদাহরণ হ'ল ওয়েটউন্টিল পদ্ধতিগুলি যা একটি বুলেটিয়ান মিথ্যা প্রত্যাবর্তনের চেয়ে সময়সীমাতে ব্যর্থ হয়।

— ওম