"কতটা খারাপ" অবশেষে চেষ্টা-ধরার ব্লক-এ সম্পর্কিত কোড নয়?

Question

এটি একটি সম্পর্কিত প্রশ্ন: খারাপ স্টাইল / বিপজ্জনকতার পরে কাজ করার জন্য শেষ অবধি ব্যবহার কী?

রেফারেন্স করা Q তে শেষ অবধি কোডটি ব্যবহৃত কাঠামো এবং প্রাক-আনার প্রয়োজনীয়তার সাথে সম্পর্কিত। আমার প্রশ্নটি কিছুটা আলাদা এবং আমি বিশ্বাস করি এটি বিস্তৃত দর্শকদের কাছে জার্মানি। আমার বিশেষ উদাহরণটি একটি সি # উইনফর্ম অ্যাপ্লিকেশন, তবে এটি সি ++ / জাভা অবশেষে ব্যবহারের ক্ষেত্রেও প্রযোজ্য।

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

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

অবশেষে ব্লকগুলিতে ফর্ম / মডিউল / নিয়ন্ত্রণ ফর্ম্যাটিং কলগুলি থাকবে (অ্যাপ্লিকেশনটি সমাপ্ত হতে চলেছে, ক্যাচ ব্লকে প্রকাশিত হওয়া সত্ত্বেও) পাশাপাশি প্যানেলের মতো নতুন অবজেক্ট তৈরি করা হবে।

মোটামুটিভাবে:

    পদ্ধতি নাম (...)
    {
        চেষ্টা
        {
            // পদ্ধতির জন্য প্রচুর কোড ...
            // কোড যা নিক্ষেপ করতে পারে ...
            // পদ্ধতি এবং একটি রিটার্নের জন্য আরও অনেক কোড ...
        }
        ধরা (কিছু)
        handle // হ্যান্ডেল ব্যতিক্রম}
        পরিশেষে
        {
            // ব্যতিক্রমের কারণে কিছু ক্লিনআপ, জিনিস বন্ধ করা
            // তৈরি করা স্টাফের জন্য আরও কোড (কোনও ব্যতিক্রম ছুঁড়ে ফেলতে পারে তা উপেক্ষা করে) ...
            // সম্ভবত আরও কিছু অবজেক্ট তৈরি করুন
        }
    }

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

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

Comments

"সি ++" ট্যাগটি এখানে নেই, কারণ সি ++ নেই (এবং এটির প্রয়োজন নেই) finally। সমস্ত ভাল ব্যবহারগুলি RAII / আরআরআইডি / এসবিআরএম (আপনার পছন্দমতো সংক্ষিপ্ত আকার) এর আওতায় আসে।

— ডেভিড থর্নলি

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

— DXM

@ ডিএক্সএম: এটির দৃশ্যায়ন করতে আমার সমস্যা হচ্ছে (এবং আমি জানি যে finallyসি # তে কী ঘটে)। সি ++ সমমান কী? আমি যা ভাবছি তা হল কোডের পরে কোড catchএবং এটি সি # এর পরে কোডের জন্য একই প্রয়োগ করে finally।

— ডেভিড থর্নলি

@ ডেভিডথর্নলি: অবশেষে কোড হ'ল এমন কোড যা কোনও বিষয়ই কার্যকর করে না ।

— orlp

@ নাইটক্র্যাকার, এটি সত্যই সঠিক নয়। এটি করলে তা কার্যকর করা হবে না Environment.FailFast(); যদি আপনার অবিচ্ছিন্ন ব্যতিক্রম থাকে তবে এটি কার্যকর করা যাবে না। আপনি যদি finallyম্যানুয়ালি পুনরাবৃত্তি করেন এমন একটি ইেট্রেটর ব্লক থাকে এবং এটি আরও জটিল হয়ে ওঠে ।

— সুইভ

Answer 1

বিকাশকারীদের দ্বারা লিখিত একটি ভয়ানক উত্তরাধিকারী উইন্ডোজ ফর্মস কোডটি মোকাবেলা করতে হয়েছিল যখন আমি স্পষ্টভাবে জানতাম না যে তারা কী করছে I've

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

বলা হচ্ছে যে...

আমার প্রথম পরামর্শটি: এটি যদি না ভেঙে যায় তবে এটি স্পর্শ করবেন না!

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

আমার দ্বিতীয় পরামর্শটি হ'ল: যদি আপনাকে আরও বৈশিষ্ট্য যুক্ত করতে হয় তবে বিদ্যমান কোড কাঠামো যথাসম্ভব রাখার চেষ্টা করুন যাতে আপনি কোডটি ভাঙেন না।

উদাহরণ: যদি আপনার মনে হয় যে উত্তরাধিকারসূত্রে যথাযথ উত্তরাধিকার সূত্রে প্রতিস্থাপন করা যেতে পারে তবে আপনার সাবধানতা অবলম্বন করতে হবে এবং চারপাশে জিনিসগুলি সরিয়ে নেওয়ার সিদ্ধান্ত নেওয়ার আগে আপনাকে অবশ্যই দুবার চিন্তা করতে হবে।

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

আমার তৃতীয় পরামর্শটি হ'ল: আপনি কোডটি ভাঙলে আপনি পুড়ে যাবেন, এটি আপনার দোষ কিনা বা তা নয়।

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

আপনার লিগ্যাসি কোডটি পুনরায় লেখার দরকার নেই কেন তার কয়েকটি কারণ ব্যাখ্যা করে জোল তার নিবন্ধে খুব ভালভাবে লিখেছেন।

http://www.joelonsoftware.com/articles/fog0000000069.html

সুতরাং আপনার এই ধরণের কোড সম্পর্কে সত্যই খারাপ লাগা উচিত (এবং আপনার মতো কখনও লেখা উচিত নয়) তবে এটি বজায় রাখা সম্পূর্ণ ভিন্ন দৈত্য।

আমার অভিজ্ঞতা সম্পর্কে: আমাকে কোডটি প্রায় 1 বছর ধরে রাখতে হয়েছিল এবং শেষ পর্যন্ত আমি এটি স্ক্র্যাচ থেকে পুনরায় লিখতে সক্ষম হয়েছি তবে সমস্ত একবারে নয়।

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

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

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

কয়েক বছর পরে এবং এই অ্যাপ্লিকেশনটি পুরো সংস্থার ব্যবহৃত একটি সুন্দর কী সরঞ্জামে পরিণত হয়েছে। আমি 100% নিশ্চিত যে আমি পুরো জিনিসটি আবার না লিখলে কখনও সম্ভব হত না।

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

Comments

+1 টি। তবে শেষ বাক্যটি সিরিয়াল কিলারকে বোঝায়। সত্যিই প্রয়োজন?

— মার্কজে

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

— রিকি ক্লার্কসন

@ রিকি ক্লার্কসন আমি সম্মত আপনি কখন এটি অত্যধিক করছেন (এটি বাস্তবায়ন করার প্রয়োজন নেই) এবং আপনি যখন পরিবর্তনগুলি যুক্ত করে অ্যাপ্লিকেশনটিকে সত্যই আঘাত করছেন তখন তা জেনে রাখা সত্যিই শক্ত।

— অ্যালেক্স

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

— অ্যালেক্স

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

Answer 2

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

http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052

যা আপনাকে কোডটিকে আরও পরীক্ষামূলক করে তুলতে, ইউনিট পরীক্ষা যুক্ত করতে এবং নতুন বৈশিষ্ট্য যুক্ত করার সময় কোডটি ভঙ্গ করা এড়াতে মূল্যবান ইঙ্গিত দেয়।

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

Answer 3

ধরুন আপনার কল করার জন্য ছয়টি পদ্ধতি রয়েছে যার মধ্যে চারটি কেবল তখনই কল করা উচিত যখন প্রথমটি কোনও ত্রুটি না করে সম্পূর্ণ করে। দুটি বিকল্প বিবেচনা করুন:

try {
     method1();  // throws
     method2();
     method3();
     method4();
     method5();
 } catch(e) {
     // handle error
 }
 method6();

বনাম

 try {
      method1();  // throws
 }
 catch(e) {
      // handle error
 }
 if(! error ) {
     method2();
     method3();
     method4();
     method5();
 }
 method6();

দ্বিতীয় কোডে, আপনি রিটার্ন কোডগুলির মতো ব্যতিক্রমগুলি চিকিত্সা করছেন। ধারণাগতভাবে, এটি অনুরূপ:

rc = method1();
if( rc != error ) {
     method2();
     method3();
     method4();
     method5();
 }
 method6();

যদি আমরা এমন প্রতিটি পদ্ধতি মোড়তে যাচ্ছি যা চেষ্টা / ক্যাচ ব্লকে ব্যতিক্রম করতে পারে তবে কোনও ভাষা বৈশিষ্ট্যে ব্যতিক্রম হওয়ার কী দরকার? কোনও লাভ নেই এবং আরও টাইপিং রয়েছে।

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

rc = method1();
if( rc != error ) {
     rc = method2();
     if( rc != error ) {
         rc = method3();
         if( rc != error ) {
             rc = method4();
             if(rc != error ) {
                 method5();
             }
         }
     }
 }
 method6();

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

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

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

void method0() : throws MyNewException 
{
    try {
        method1();  // throws MyOtherException
    }
    catch(e) {
        if(e == MyOtherException)
            throw MyNewException();
    }
    method2();
}

এখানে, আপনি কেবল স্তরগুলি যুক্ত করছেন, এবং স্তরগুলি বিভ্রান্তি যুক্ত করে। শুধু এটি করুন:

void method0() : throws MyOtherException
{
    method1();
    method2();
}

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

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

Comments

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

এই পদ্ধতির সাথে একটি প্রধান সমস্যা হ'ল এটি এমন কোনও ক্ষেত্রে কোনও পার্থক্য রাখে না যেখানে method0অর্ধ-প্রত্যাশা হতে পারে যে কোনও ব্যতিক্রম ছুঁড়ে দেওয়া হতে পারে, এবং যেখানে এটি না হয়। উদাহরণস্বরূপ, ধরুন method1কখনও কখনও একটি নিক্ষেপ করতে পারে InvalidArgumentExceptionতবে এটি যদি তা না করে তবে এটি কোনও বস্তুকে অস্থায়ীভাবে-অবৈধ অবস্থায় ফেলে দেবে যা সংশোধন করবে method2, যা প্রত্যাশাই সর্বদা অবৈধ অবস্থানে ফিরে যাবে state যদি পদ্ধতি 2 একটি নিক্ষেপ করে InvalidArgumentException, কোডটি এর থেকে এই জাতীয় ব্যতিক্রম ধরার প্রত্যাশা করে তবে কোডটি method1এটি ধরবে, যদিও ...

— সুপারক্যাট

... সিস্টেমের রাষ্ট্র কোডের প্রত্যাশার সাথে মিলবে। যদি পদ্ধতি 1 থেকে নিক্ষিপ্ত একটি ব্যতিক্রম পদ্ধতি 2 দ্বারা ছুঁড়ে দেওয়া থেকে পৃথকভাবে পরিচালনা করা উচিত, তবে কীভাবে সংবেদনশীলভাবে এগুলি মোড়ানো না করা সম্ভব?

— সুপারক্যাট

আদর্শভাবে আপনার ব্যতিক্রমগুলি যথেষ্ট পরিমাণে দানাদার যে এটি একটি বিরল পরিস্থিতি।

— রোবট