জাভা বা সি # তে ব্যতিক্রমী পরিচালনার জন্য সেরা অনুশীলনগুলি [বন্ধ]


117

আমার অ্যাপ্লিকেশনটিতে কীভাবে ব্যতিক্রমগুলি পরিচালনা করা যায় তা স্থির করতে আমি আটকে আছি।

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

ফলস্বরূপ, আমি যদি কোনও ব্যতিক্রমের মুখোমুখি হই তবে আমি কেবল এটি ফাংশনটির মধ্যেই ধরি এবং কলকে মিথ্যা ফিরিয়ে দেব। আমার যুক্তিটি হ'ল যে সমস্ত কলকারী সত্যই যত্নবান তা হ'ল যদি কাজটি সফল হয় তবে কেন এটি সফল হয়নি।

এখানে একটি সাধারণ পদ্ধতির কয়েকটি নমুনা কোড (জাভাতে) রয়েছে

public boolean doSomething(Object p_somthingToDoOn)
{
    boolean result = false;

    try{
        // if dirty object then clean
        doactualStuffOnObject(p_jsonObject);

        //assume success (no exception thrown)
        result = true;
    }
    catch(Exception Ex)
    {
        //don't care about exceptions
        Ex.printStackTrace();
    }
    return result;
}

আমি মনে করি এই পদ্ধতিটি ঠিক আছে, তবে ব্যতিক্রমগুলি পরিচালনা করার জন্য সর্বোত্তম অনুশীলনগুলি কী তা জানতে আমি সত্যিই আগ্রহী (যদি কল স্ট্যাকের সমস্ত উপায় অবলম্বন করা উচিত তবে আমি কি সত্যই বাধা দেব?)।

মূল প্রশ্নের সংক্ষিপ্তসার:

  1. কেবল ব্যাতিক্রমগুলি ধরা কি ঠিক আছে তবে সেগুলি বুদবুদ না করে বা আনুষ্ঠানিকভাবে সিস্টেমকে অবহিত করা (লগ বা ব্যবহারকারীর কাছে কোনও বিজ্ঞপ্তির মাধ্যমে)?
  2. ব্যতিক্রমগুলির জন্য কী সর্বোত্তম অনুশীলনগুলি রয়েছে যার ফলে চেষ্টা / ক্যাপ ব্লক প্রয়োজন হয় এমন সমস্ত কিছুর ফলাফল হয় না?

অনুসরণ / সম্পাদনা করুন

সমস্ত প্রতিক্রিয়ার জন্য ধন্যবাদ, অনলাইনে ব্যতিক্রম পরিচালনার জন্য কিছু দুর্দান্ত উত্স পাওয়া গেছে:

দেখে মনে হয় যে প্রসঙ্গের ভিত্তিতে পরিবর্তিত হয় সেই বিষয়গুলির মধ্যে একটি ব্যতিক্রম ব্যয় পরিচালনা তবে সবচেয়ে বড় কথা, তারা কীভাবে কোনও সিস্টেমের মধ্যে ব্যতিক্রমগুলি পরিচালনা করে তার সাথে সামঞ্জস্য হওয়া উচিত।

অতিরিক্ত চেষ্টা / ক্যাচের মাধ্যমে বা কোনও ব্যতিক্রমকে এর সম্মান না দেওয়ার মাধ্যমে কোড-রটটির জন্য নজর রাখুন (একটি ব্যতিক্রম সিস্টেমকে সতর্ক করে দিচ্ছে, আরও কী সতর্ক করার দরকার?)

এছাড়াও, এটি m3rLinEz থেকে একটি দুর্দান্ত পছন্দ মন্তব্য ।

আমি অ্যান্ডারস হিজলসবার্গ এবং আপনার সাথে একমত হতে চাই যে অপারেশন সফল হয় বা না হয় সেক্ষেত্রে সর্বাধিক কলকারীরা যত্নশীল।

এই মন্তব্য থেকে এটি ব্যতিক্রমগুলি নিয়ে কাজ করার সময় ভাবার জন্য কিছু প্রশ্ন নিয়ে আসে:

  • এই ব্যতিক্রমটি কী ছুঁড়ে দেওয়া হচ্ছে?
  • কীভাবে এটি হ্যান্ডেল করা যায়?
  • কলকারী কি ব্যাতিক্রমের বিষয়ে সত্যই চিন্তা করে বা কলটি সফল হয়েছিল কিনা সেগুলি তারা কেবল যত্ন করে?
  • কোনও কলকারীকে কোনও সম্ভাব্য ব্যতিক্রম পরিচালনা করতে বাধ্য করা কি প্রশংসনীয়?
  • আপনি কি ভাষার আইডেমগুলির প্রতি শ্রদ্ধাশীল হচ্ছেন?
    • আপনার কি সত্যিই বুলেটের মতো সাফল্যের পতাকা ফিরিয়ে দিতে হবে? রিটার্নিং বুলিয়ান (বা কোনও int) জাভা (জাভাতে আপনি কেবল ব্যতিক্রমটি পরিচালনা করবেন) এর চেয়ে সি মানসিকতার চেয়ে বেশি।
    • ভাষার সাথে সম্পর্কিত ত্রুটি পরিচালনার কনস্ট্রাক্টগুলি অনুসরণ করুন :)!

যদিও ওরাকল সম্প্রদায়ের নিবন্ধটি জাভাতে রয়েছে, তবে এটি বেশ বিস্তৃত ভাষার ভাষার জন্য সাধারণ পরামর্শ। চমৎকার নিবন্ধ, আমি যা খুঁজছিলাম ঠিক তাই।
শনি খরগোশ

উত্তর:


61

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

আপনার প্রশ্ন হিসাবে:

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

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

আপনি যা করতে পারেন তা হ'ল আপনার ত্রুটি কোডগুলি একটি
মোনাডে মুড়ে ফেলা

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

আমি মনে করি এটি বলা ভাল: "আপনার কেবলমাত্র ব্যাতিক্রমগুলি গ্রহণ করা উচিত যা আপনি বাস্তবে পরিচালনা করতে পারেন" "
দিদিয়ার এ।

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

25

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

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

সাধারণভাবে আমি নিম্নলিখিত নিয়মগুলি ব্যবহার করি:

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

আমি নীচের কোডটি গন্ধ হিসাবে পেয়েছি:

try
{
    //do something
}
catch(Exception)
{
   throw;
}

এই জাতীয় কোড কোনও লাভ করে না এবং অন্তর্ভুক্ত করা উচিত নয়।


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

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

কোডটি একটি বিন্দু দেয়: আপনি "নিক্ষেপ" এ একটি ব্রেকপয়েন্ট নির্ধারণ করতে পারেন।
রাউহটজ

3
দুর্বল বিন্দু, আপনি কোনও ছোঁড়া ব্যতিক্রম ভেঙ্গে ভিএসকে বলতে পারেন বা আপনি এটিকে সংকুচিত করে একটি নির্দিষ্ট ব্যতিক্রম চয়ন করতে পারেন। ভিএস ২০০৮-এ ডিবাগের আওতায় একটি মেনু আইটেম রয়েছে (এটি খুঁজতে আপনাকে আপনার সরঞ্জামদণ্ডগুলি কাস্টমাইজ করতে হবে) নামক ব্যতিক্রমগুলি
জোশবার্ক

"কোড গন্ধ" উদাহরণটির একটি নির্দিষ্ট পার্শ্ব প্রতিক্রিয়া রয়েছে, এমনকি সেই সহজ আকারে। যদি বিন্দুর চারপাশে যে // do somethingকোনও try/finallyব্লক অন্তর্ভুক্ত থাকে তবে finallyব্লকগুলি catchব্লকের আগে কার্যকর করা হবে । ব্যতীত try/catchব্যতিক্রমগুলি সমস্ত finallyব্লক কার্যকর না করে স্ট্যাকের শীর্ষে উঠে যাবে । এটি শীর্ষ-স্তরের হ্যান্ডলারটিকে finallyব্লকগুলি কার্যকর করতে হবে কি না তা সিদ্ধান্ত নিতে দেয়।
ড্যানিয়েল আর্উইকার

9

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

ব্যর্থতা এবং ব্যতিক্রম

পৃষ্ঠার নীচে দুর্দান্ত সংস্থানগুলিও রয়েছে।

আমি অ্যান্ডারস হিজলসবার্গ এবং আপনার সাথে একমত হতে চাই যে অপারেশন সফল হয় বা না হয় সেক্ষেত্রে সর্বাধিক কলকারীরা যত্নশীল।

বিল ভেনার্স : আপনি পরীক্ষিত ব্যতিক্রমগুলির ক্ষেত্রে স্কেলাবিলিটি এবং সংস্করণ উদ্বেগের কথা উল্লেখ করেছেন। আপনি এই দুটি ইস্যু বলতে কী বোঝাতে চেয়েছেন?

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

নতুন সংস্করণে একটি থ্রোস ক্লজে একটি নতুন ব্যতিক্রম যুক্ত করা ক্লায়েন্ট কোডকে ভেঙে দেয়। এটি একটি ইন্টারফেসে একটি পদ্ধতি যুক্ত করার মতো। আপনি কোনও ইন্টারফেস প্রকাশের পরে, এটি সমস্ত ব্যবহারিক উদ্দেশ্যে অপরিবর্তনীয়, কারণ এটির কোনও প্রয়োগের ক্ষেত্রে পরবর্তী সংস্করণে আপনি যে পদ্ধতিগুলি যুক্ত করতে চান তা থাকতে পারে। সুতরাং আপনি পরিবর্তে একটি নতুন ইন্টারফেস তৈরি করতে হবে। একইভাবে ব্যতিক্রম সহ, আপনাকে হয় foo2 নামে একটি সম্পূর্ণ নতুন পদ্ধতি তৈরি করতে হবে যা আরও ব্যতিক্রম ছুঁড়ে ফেলেছে, বা আপনাকে নতুন foo এ ব্যতিক্রম D ধরতে হবে এবং D কে A, B বা C তে রূপান্তর করতে হবে either

বিল ভেনারস : তবে আপনি কি সেই ক্ষেত্রে তাদের কোডটি ভঙ্গ করছেন না, এমনকি চেক ব্যাতীত কোনও ভাষায়ও ? যদি foo- র নতুন সংস্করণটি কোনও নতুন ব্যতিক্রম ছোঁড়াচ্ছে যা ক্লায়েন্টদের পরিচালনা করার বিষয়ে চিন্তা করা উচিত, তবে কোডটি লেখার সময় তাদের ব্যতিক্রমটি কী আশা করা যায়নি?

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

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

সম্পাদনা: কনভার্সটায়নে আরও বিশদ যুক্ত করা হয়েছে


এর জন্য ধন্যবাদ! আমি আপনার উত্তর সম্পর্কে তথ্য দিয়ে আমার প্রশ্ন আপডেট!
আতারিপেট

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

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

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

8

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

থাম্বের নিয়ম হিসাবে, ব্যতিক্রম হ্যান্ডলিং কোনও নির্দিষ্ট ক্রমে এই নির্দেশিকাগুলির চারপাশে কিছু হওয়া উচিত:

  • রক্ষণাবেক্ষণের স্বার্থে সর্বদা ব্যতিক্রমগুলি লগ করুন যাতে আপনি যখন বাগগুলি দেখা শুরু করেন তখন লগটি আপনার বাগটি সম্ভবত শুরু হওয়া স্থানটির দিকে নির্দেশ করতে সহায়তা করবে। কখনই ত্যাগ করবেন না printStackTrace()বা পছন্দ করুন না এমন সম্ভাবনা হ'ল আপনার ব্যবহারকারীর মধ্যে একটি হ'ল শেষ পর্যন্ত সেই স্ট্যাকের একটি চিহ্ন খুঁজে পাবে এবং এর সাথে কী করবে সে সম্পর্কে ঠিক শূন্য জ্ঞান থাকবে ।
  • আপনি এবং যেগুলি হ্যান্ডেল করতে পারেন সেই ব্যতিক্রমগুলি ধরুন এবং সেগুলি হ্যান্ডেল করুন , কেবল তাদের স্ট্যাকের উপরে ফেলে দেবেন না।
  • সর্বদা একটি নির্দিষ্ট ব্যতিক্রম শ্রেণি ধরুন এবং সাধারণত আপনার টাইপটি কখনই ধরা উচিত নয় Exception, আপনি সম্ভবত অন্যথায় গুরুত্বপূর্ণ ব্যতিক্রমগুলি গ্রাস করতে পারেন।
  • কখনই না (কখনও) Errorএস !! , যার অর্থ: কখনও ধরা Throwableগুলি যেমন Errorগুলি পরেরটির উপশ্রেণী হয়। Errorগুলি হ'ল এমন সমস্যা যা আপনি সম্ভবত পরিচালনা করতে পারবেন না (যেমন OutOfMemory, বা অন্যান্য জেভিএম সমস্যা)

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


চেক করা ব্যতিক্রমগুলি সি # তে কোনও সমস্যা নয় কারণ এতে সেগুলি নেই।
ক্লিটাস

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

5

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


3

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

যাত্রা।

try
{
   sendMessage();

   if(message == success)
   {
       doStuff();
   }
   else if(message == failed)
   {
       throw;
   }
}
catch(Exception)
{
    logAndRecover();
}

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


2

উপরের সমস্তটি যুক্তিসঙ্গত বলে মনে হয় এবং প্রায়শই আপনার কর্মক্ষেত্রে একটি নীতি থাকতে পারে। আমাদের জায়গায় আমরা ব্যতিক্রমগুলির ধরনগুলিতে সংজ্ঞায়িত করেছি: (চেক করা হয়নি) SystemExceptionএবং ApplicationException(পরীক্ষিত)।

আমরা একমত হয়েছি যে SystemExceptionএর পুনরুদ্ধারযোগ্য হওয়ার সম্ভাবনা কম এবং শীর্ষে একবারে পরিচালনা করা হবে। আরও প্রসঙ্গ প্রদান করার জন্য, আমাদের SystemExceptionগুলি ইঙ্গিত তারা কোথায় ঘটেছে, যেমন exteneded হয় RepositoryException, ServiceEceptionইত্যাদি

ApplicationExceptionএর ব্যবসায়ের অর্থ এর মতো InsufficientFundsExceptionহতে পারে এবং ক্লায়েন্ট কোড দ্বারা পরিচালনা করা উচিত।

একটি দৃ concrete় উদাহরণ হিসাবে উইটোহুত, আপনার প্রয়োগ সম্পর্কে মন্তব্য করা কঠিন, তবে আমি কখনও রিটার্ন কোড ব্যবহার করব না, এগুলি রক্ষণাবেক্ষণের সমস্যা issue আপনি একটি ব্যতিক্রম গ্রাস করতে পারেন, তবে আপনাকে কেন সিদ্ধান্ত নিতে হবে এবং সর্বদা ইভেন্টটি এবং স্ট্যাকট্রেস লগ করুন। শেষ অবধি, আপনার পদ্ধতিতে অন্য কোনও প্রক্রিয়াজাতকরণ না থাকায় এটি মোটামুটি অনর্থক (এনক্যাপসুলেশন বাদে?), সুতরাং doactualStuffOnObject(p_jsonObject);কোনও বুলিয়ান ফিরে আসতে পারে!


1

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

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

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


1

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

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

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

// throws NumberNotHexidecimalException
int ParseHexidecimal(string numberToParse); 

bool TryParseHexidecimal(string numberToParse, out int parsedInt)
{
     try
     {
         parsedInt = ParseHexidecimal(numberToParse);
         return true;
     }
     catch(NumberNotHexidecimalException ex)
     {
         parsedInt = 0;
         return false;
     }
     catch(Exception ex)
     {
         // Implement the error policy for unexpected exceptions:
         // log a callstack, assert if a debugger is attached etc.
         LogRetailAssert(ex);
         // rethrow the exception
         // The downside is that a JIT debugger will have the next
         // line as the place that threw the exception, rather than
         // the original location further down the stack.
         throw;
         // A better practice is to use an exception filter here.
         // see the link to Exception Filter Inject above
         // http://code.msdn.microsoft.com/ExceptionFilterInjct
     }
}

আপনি ট্রাইএক্সএক্সএক্সএক্সএক্স এর মতো কোনও প্যাটার্ন ব্যবহার করেন বা না তা কোনও স্টাইলের প্রশ্নই নয়। সমস্ত ব্যতিক্রম ধরা এবং সেগুলি গ্রাস করার প্রশ্ন কোনও স্টাইলের সমস্যা নয়। অপ্রত্যাশিত ব্যতিক্রম প্রচারের অনুমতি দেওয়া হয়েছে তা নিশ্চিত করুন!


আমি নেট। এ ট্রাইএক্সএক্সএক্সএক্স প্যাটার্নটি পছন্দ করি।
জোশবার্ক

1

আপনি যে ভাষাটি ব্যবহার করছেন তার জন্য আমি স্ট্যান্ডার্ড লাইব্রেরি থেকে আপনার ইঙ্গিত নেওয়ার পরামর্শ দিই। আমি সি # এর পক্ষে কথা বলতে পারি না, তবে জাভা দেখি।

উদাহরণস্বরূপ java.lang.reflect.Array এর একটি স্ট্যাটিক setপদ্ধতি রয়েছে:

static void set(Object array, int index, Object value);

সি উপায় হবে

static int set(Object array, int index, Object value);

... রিটার্ন মান সাফল্যের সূচক হিসাবে। তবে আপনি আর বিশ্বে নেই।

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

অন্যরা যেমন উল্লেখ করেছে - আপনি যে ধরনের ব্যতিক্রম ধরেন সে ক্ষেত্রে আপনার যথাসম্ভব সুনির্দিষ্ট হওয়া উচিত।


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

0

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

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

সম্পাদনা: চেষ্টা / ধরাতে সমস্ত কিছু মোড়ানো করার প্রশ্নে আমি মনে করি উত্তরটি হ্যাঁ। ব্যতিক্রমগুলি আপনার কোডে এত বিরল হওয়া উচিত যে ক্যাচ ব্লকের কোডটি খুব কমই চালিত করে যে এটি কার্য সম্পাদনকে একেবারেই আঘাত করে না। একটি ব্যতিক্রম এমন একটি রাষ্ট্র হওয়া উচিত যেখানে আপনার রাষ্ট্রীয় যন্ত্রটি ভেঙে গেছে এবং কী করতে হবে তা জানে না। কমপক্ষে একটি ব্যতিক্রম পুনর্বিবেচনা করুন যা সেই সময়ে কী ঘটছে তা ব্যাখ্যা করে এবং এর অভ্যন্তরে ধরা পড়ার ব্যতিক্রম রয়েছে। "পদ্ধতি doSomeStuff ব্যতীত ()" আপনার ছুটিতে (বা একটি নতুন চাকরীতে) যাওয়ার সময় কেন এটি ভেঙেছিল তা বুঝতে হবে এমন কারও পক্ষে খুব কার্যকর নয়।


ভুলে যাবেন না যে একটি ব্যতিক্রম ব্লক সেটআপের জন্য খুব বেশি খরচ হয় ...
0

0

আমার কৌশল:

যদি মূল ফাংশনটি অকার্যকর হয় তবে আমি এটিকে ফিরে আসি বুলে । ব্যতিক্রম / ত্রুটি ঘটলে মিথ্যা প্রত্যাবর্তন হয় , যদি সবকিছু ঠিক থাকে তবে সত্য সত্য

যদি ফাংশনটি কোনও কিছু ফিরে আসে তবে যখন ব্যতিক্রম / ত্রুটি ঘটে তখন ফিরে আসে নালায় , অন্যথায় ফেরতযোগ্য আইটেম।

বোলের পরিবর্তে ত্রুটির বর্ণনা সহ একটি স্ট্রিং ফেরত দেওয়া যেতে পারে।

প্রতিটি ক্ষেত্রে কোনও ফেরত দেওয়ার আগে ত্রুটিটি লগ করুন।


0

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


আমি পুরোপুরি একমত আমি কেবল এক্স.প্রিন্টস্ট্যাকট্রেস () করেছি; আমি ধরা পড়ার মধ্যে কিছু করছিলাম (যেমন পুনর্বিবেচনা নয়) এর উদাহরণ হিসাবে।
আতারিপেট

0

ট্র্যাচ / ক্যাচ ব্লকগুলি প্রথম (প্রধান) সেটটিতে এম্বেড করা যুক্তিবিদ্যার দ্বিতীয় সেট গঠন করে, যেমন এগুলি স্প্যাগেটি কোডটি ডিবাগ করা শক্ত, অপঠনযোগ্য পাউন্ড আউট করার একটি দুর্দান্ত উপায়।

তবুও, যুক্তিসঙ্গতভাবে তারা ব্যবহারযোগ্যতার জন্য আশ্চর্য কাজ করে, তবে আপনার কেবল দুটি সহজ নিয়ম অনুসরণ করা উচিত:

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

  • নিম্ন স্তরে ধরা পড়ে না এমন কোডে উদ্ভূত যে কোনও বা অদ্ভুত শর্তগুলি পরিচালনা করতে উচ্চ-স্তরে একটি বড় হ্যান্ডলার ব্যবহার করুন। ত্রুটিগুলি (লগ, পুনরায় সূচনা, পুনরুদ্ধার, ইত্যাদি) দিয়ে দরকারী কিছু করুন।

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

পল।


0

আমি উত্তরটি দিয়ে কিছুটা দেরি করতে পারি তবে ত্রুটি পরিচালনার বিষয়টি এমন একটি বিষয় যা আমরা সর্বদা সময়ের সাথে পরিবর্তিত এবং বিকশিত হতে পারি। আপনি যদি এই বিষয় সম্পর্কে আরও কিছু পড়তে চান তবে আমি এটি সম্পর্কে আমার নতুন ব্লগে একটি পোস্ট লিখেছি। http://taoofdevelopment.wordpress.com

শুভ কোডিং।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.