চেষ্টা করুন / ধরুন / লগ করুন / রিথ্রো - এন্টি প্যাটার্নটি কি?


19

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

public static bool DoOperation(int num1, int num2)
{
    try
    {
        /* do some work with num1 and num2 */
    }
    catch (Exception ex)
    {
        logger.log("error occured while number 1 = {num1} and number 2 = {num2}"); 
        throw;
    }
}

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

ধন্যবাদ!


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

আমি বলছি প্রতিটি পদ্ধতি চেষ্টা / ধরুন এবং কেবল ক্যাচ ব্লকটিতে লগইন করুন এবং পুনঃসূচনা করুন - এটি কি ঠিক আছে?
রাহুলগা_দেব

2
আমনের নির্দেশ অনুসারে যদি আপনার ভাষায় স্ট্যাক-ট্রেস থাকে তবে প্রতিটি ক্যাপে লগইন করা অর্থহীন। তবে ব্যতিক্রম মোড়ানো এবং অতিরিক্ত তথ্য যুক্ত করা ভাল অনুশীলন।
ইউফোরিক

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

1
লিথ: ছোট কোড স্নিপেট যুক্ত হয়েছে। আমি সি #
রাহুলগা_দেব

উত্তর:


19

সমস্যাটি স্থানীয় ক্যাচ ব্লক নয়, সমস্যাটি লগ এবং পুনর্বিবেচনা । হয় ব্যতিক্রমটি পরিচালনা করুন বা এটিকে একটি নতুন ব্যতিক্রম সহ মোড়ানো করুন যা অতিরিক্ত প্রসঙ্গ যুক্ত করে এবং এটি ছুঁড়ে। অন্যথায় আপনি একই ব্যতিক্রম জন্য বেশ কয়েকটি সদৃশ লগ এন্ট্রি চালানো হবে।

এখানে ধারণাটি হ'ল আপনার অ্যাপ্লিকেশনটি ডিবাগ করার ক্ষমতা বাড়ানো

উদাহরণ # 1: এটি হ্যান্ডেল করুন

try
{
    doSomething();
}
catch (Exception e)
{
    log.Info("Couldn't do something", e);
    doSomethingElse();
}

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

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

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

try
{
    context.DrawLine(x1,y1, x2,y2);
}
catch (OutOfMemoryException)
{
    // WinForms throws OutOfMemory if the figure you are attempting to
    // draw takes up less than one pixel (true story)
}

উদাহরণ # 2: অতিরিক্ত প্রসঙ্গ যুক্ত করুন এবং নিক্ষেপ করুন

try
{
    doSomething(line);
}
catch (Exception e)
{
    throw new MyApplicationException(filename, line, e);
}

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

উদাহরণ # 3: ব্যতিক্রম ছাড়া কিছু করবেন না

try
{
    doSomething();
}
finally
{
   // cleanup resources but let the exception percolate
}

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


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

আমি আমার উত্তরে একটি গাইডলাইন সরবরাহ করেছি। এটি কি আপনার প্রশ্নের উত্তর দেয় না?
বেরিন লরিটস

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

7

আমি বিশ্বাস করি না যে স্থানীয় ক্যাচগুলি একটি অ্যান্টি-প্যাটার্ন, আসলে যদি আমি সঠিকভাবে মনে করি তবে এটি আসলে জাভাতে প্রয়োগ করা হয়েছে!

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

আমি নীচের একটি করতে পারলে ব্যক্তিগতভাবে আমি কোনও ফাংশনের অভ্যন্তরে ত্রুটিগুলি ধরা পছন্দ করি:

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

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

উদাহরণ স্বরূপ:

public bool TryConnectToDatabase()
{
  try
  {
    this.ConnectToDatabase(_databaseType); // this method will throw if it fails to connect
    return true;
  }
  catch(Exception ex)
  {
     this.Logger.Error(ex, "There was an error connecting to the database, the databaseType was {0}", _databaseType);
    return false;
  }
}

বা একটি পুনর্বিবেচনা উদাহরণ:

public IDbConnection ConnectToDatabase()
{
  try
  {
    // connect to the database and return the connection, will throw if the connection cannot be made
  }
  catch(Exception ex)
  {
     this.Logger.Error(ex, "There was an error connecting to the database, the databaseType was {0}", _databaseType);
    throw;
  }
}

তারপরে আপনি স্ট্যাকের শীর্ষে ত্রুটিটি ধরেন এবং ব্যবহারকারীর কাছে একটি দুর্দান্ত ব্যবহারকারী বান্ধব বার্তা উপস্থাপন করেন।

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

আপনি কোন ভাষায় কাজ করছেন তবে একটি নেট নেট বিকাশকারী হিসাবে উল্লেখ করেন নি এবং উল্লেখ না করার জন্য এটি বহুবার দেখেছি।

আপনি উত্তর দিবেন না:

catch(Exception ex)
{
  throw ex;
}

ব্যবহার করুন:

catch(Exception ex)
{
  throw;
}

প্রাক্তনটি স্ট্যাকের ট্রেস পুনরায় সেট করে এবং আপনার শীর্ষ স্তরেরটিকে পুরোপুরি অকেজো করে তোলে!

TLDR

স্থানীয়ভাবে ক্যাচিং কোনও অ্যান্টি-প্যাটার্ন নয়, এটি প্রায়শই কোনও ডিজাইনের অংশ হতে পারে এবং ত্রুটিতে অতিরিক্ত প্রসঙ্গ যুক্ত করতে সহায়তা করতে পারে।


3
ক্যাচটিতে লগিংয়ের বিন্দু কী, যখন একই লগারটি শীর্ষ স্তরের ব্যতিক্রম হ্যান্ডলারটিতে ব্যবহৃত হত?
ইউফোরিক

আপনার কাছে অতিরিক্ত তথ্য থাকতে পারে (যেমন স্থানীয় ভেরিয়েবলগুলি) যা আপনার কাছে স্ট্যাকের শীর্ষে অ্যাক্সেস থাকবে না। উদাহরণস্বরূপ উদাহরণটি আপডেট করব।
লিথ

2
সেক্ষেত্রে অতিরিক্ত ডেটা এবং অভ্যন্তরীণ ব্যতিক্রম সহ নতুন ব্যতিক্রম নিক্ষেপ করুন।
ইউফোরিক

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

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

4

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

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

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

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


4

আমি দেখতে যখন try/catch/log প্রতিটি পদ্ধতিতে এটি উদ্বেগ উত্থাপন করে যে বিকাশকারীদের তাদের প্রয়োগে কী ঘটতে পারে বা না হতে পারে তার কোনও ধারণা ছিল না, এটি সবচেয়ে খারাপ বলে ধরেছিল এবং সমস্ত প্রত্যাশিত বাগের কারণেই তারা প্রাকৃতিকভাবে সব জায়গায় লগইন করেছিল।

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

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

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

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


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

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

2

আপনার যদি প্রসঙ্গের তথ্য রেকর্ড করতে হয় যা ইতিমধ্যে ব্যতিক্রম নয়, আপনি এটি একটি নতুন ব্যতিক্রমের মধ্যে আবদ্ধ করুন এবং মূল ব্যতিক্রম হিসাবে এটি সরবরাহ করুন InnerException। এইভাবে এখনও আপনার কাছে মূল স্ট্যাক ট্রেস সংরক্ষণ করা আছে। তাই:

public static bool DoOperation(int num1, int num2)
{
    try
    {
        /* do some work with num1 and num2 */
    }
    catch (Exception ex)
    {
        throw new Exception("error occured while number 1 = {num1} and number 2 = {num2}", ex);
    }
}

Exceptionকনস্ট্রাক্টরের দ্বিতীয় প্যারামিটারটি একটি অভ্যন্তরীণ ব্যতিক্রম সরবরাহ করে। তারপরে আপনি সমস্ত ব্যতিক্রমগুলি এক জায়গায় লগ করতে পারেন এবং আপনি এখনও একই লগ এন্ট্রিতে সম্পূর্ণ স্ট্যাক ট্রেস এবং প্রাসঙ্গিক তথ্য পাবেন।

আপনি একটি কাস্টম ব্যতিক্রম ক্লাস ব্যবহার করতে চাইতে পারেন, তবে পয়েন্টটি একই।

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


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

@ ম্যাক্স: মূল ব্যতিক্রম প্রকারটি অভ্যন্তরীণ ব্যতিক্রম হিসাবে এখনও উপলব্ধ।
জ্যাকবিবি 17'18

যেটা আমি মনে করছি! এখন কল স্ট্যাকের প্রত্যেকে, যারা স্কেলএক্সসেপশনটির জন্য আকর্ষণীয় ছিল, তারা কখনই তা পাবে না।
সর্বাধিক

1

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

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

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

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


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

1
@ ডেভিড আর্নো সত্য, তবে আপনি যে কোনও প্রসঙ্গ সরবরাহ করতে পারেন তাও সেই নির্দিষ্ট হতে পারে না। নাহলে আপনারা থাকতেন try { tester.test(); } catch (NullPointerException e) { logger.error("Variable tester was null!"); }। স্ট্যাক ট্রেস বেশিরভাগ ক্ষেত্রেই যথেষ্ট, তবে অভাবের কারণে, ত্রুটির ধরণটি সাধারণত পর্যাপ্ত is
নীল
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.