ব্যতিক্রম হ্যান্ডলিংয়ের জন্য কীভাবে ক্যাচ ব্যবহারের চেষ্টা করা সেরা অনুশীলন

201

একজন সিনিয়র বিকাশকারী হিসাবে দাবি করা এমন কেউ থেকেও আমার সহকর্মীর কোড বজায় রাখার সময় আমি প্রায়শই নিম্নলিখিত কোডটি দেখতে পাই:

try
{
  //do something
}
catch
{
  //Do nothing
}

বা কখনও কখনও তারা নিম্নলিখিত try catchব্লকের মতো ফাইল লগ করতে লগিংয়ের তথ্য লিখেন

try
{
  //do some work
}
catch(Exception exception)
{
   WriteException2LogFile(exception);
}

আমি কেবল ভাবছি যে তারা কী করেছে তা অনুশীলন? এটি আমাকে বিভ্রান্ত করে তোলে কারণ আমার চিন্তাভাবনায় ব্যবহারকারীদের জানা উচিত যে সিস্টেমের সাথে কী ঘটে।

আমাকে কিছু উপদেশ দিন দয়া করে।

— তোয়ান এনগুইন
সূত্র

128

স্নিপেট # 1 99,999% সময় অগ্রহণযোগ্য।

— লেপি

22

সরাসরি ব্যবহারকারীর কাছে ব্যতিক্রম প্রদর্শন কখনই মূলত দুটি কারণে নয়: ১. যদি এটি সাধারণ ব্যবহারকারী (গুলি) হয় তবে তিনি বিরক্ত হবেন এমন পাঠ্য ত্রুটি বার্তা যা তার / তার পক্ষে খুব কম বলে tells ২. (যদি) তিনি, তথাকথিত, হ্যাকার (গুলি) তিনি দরকারী তথ্য পেতে পারেন। সেরা অনুশীলন, আইএমও, ব্যতিক্রম লগ করা এবং বন্ধুত্বপূর্ণ ত্রুটি বার্তা প্রদর্শন করা হয়।

— Leri

4

@ লেপ্পি যদি কিছু অপ্রত্যাশিত ঘটে (যেমন NullReferenceবা ArgumentNullএটি অ্যাপ্লিকেশন প্রবাহের অংশ নয়) এর অর্থ হ'ল একটি বাগ রয়েছে যা ঠিক করতে হবে তাই তাদের লগ ইন করা আপনার কোডটি আরও দ্রুত ডিবাগ করতে সহায়তা করবে।

— Leri

14

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

— কোরি

12

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

— অ্যান্টনি পেগ্রাম

300

আমার ব্যতিক্রম পরিচালনার কৌশলটি হ'ল:

ধরা সব অপরিচালিত ব্যতিক্রম করার hooking দ্বারা Application.ThreadException event, তারপর সিদ্ধান্ত নেন:
- কোনও ইউআই অ্যাপ্লিকেশনটির জন্য: ক্ষমা প্রার্থনার বার্তা (উইনফর্মস) সহ এটি ব্যবহারকারীর কাছে পপ করা
- কোনও পরিষেবা বা কনসোল অ্যাপ্লিকেশনটির জন্য: এটি কোনও ফাইলে লগইন করুন (পরিষেবা বা কনসোল)

তারপরে আমি সর্বদা কোডের প্রতিটি টুকরাকে ঘিরে রাখি যা বাহ্যিকভাবে চালিত হয় try/catch:

উইনফর্মস অবকাঠামো দ্বারা চালিত সমস্ত ইভেন্ট (লোড, ক্লিক, নির্বাচিত পরিবর্তন ...)
সমস্ত ইভেন্ট তৃতীয় পক্ষের উপাদানগুলি দ্বারা বরখাস্ত

তারপরে আমি 'চেষ্টা / ধরুন' এ সংযুক্ত

আমি জানি এমন সমস্ত অপারেশন সম্ভবত সব সময় কাজ না করে (আইও অপারেশন, সম্ভাব্য শূন্য বিভাগের সাথে গণনা ...)। এই জাতীয় ক্ষেত্রে, আমি ApplicationException("custom message", innerException)কী ঘটেছে তা ট্র্যাক রাখতে আমি একটি নতুন ছুঁড়ে ফেলি

অতিরিক্তভাবে, আমি ব্যতিক্রমগুলি সঠিকভাবে সাজানোর জন্য যথাসাধ্য চেষ্টা করি । ব্যতিক্রম আছে যা:

তাত্ক্ষণিক ব্যবহারকারীর দেখানো দরকার
ক্যাসকেডিং সমস্যা এড়াতে যখন জিনিসগুলি ঘটে তখন তাদের একসাথে রাখার জন্য কিছু অতিরিক্ত প্রসেসিংয়ের প্রয়োজন হয় (যেমন: রাখুন put পূরণের finallyসময় বিভাগে আপডেট করুন TreeView)
ব্যবহারকারীর যত্ন নেই, তবে কী ঘটেছিল তা জানা গুরুত্বপূর্ণ। তাই আমি সর্বদা সেগুলি লগ করি:
- ইভেন্ট লগ
- বা ডিস্কে একটি। লগ ফাইল এ

অ্যাপ্লিকেশন শীর্ষ স্তরের ত্রুটি হ্যান্ডলারের ব্যতিক্রমগুলি পরিচালনা করতে কিছু স্থিতিশীল পদ্ধতি ডিজাইন করা ভাল অনুশীলন ।

আমি নিজেকে চেষ্টা করার জন্য জোর করে:

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

সুতরাং অবশেষে:

খারাপ:

// DON'T DO THIS, ITS BAD
try
{
    ...
}
catch 
{
   // only air...
}

বেহুদা:

// DONT'T DO THIS, ITS USELESS
try
{
    ...
}
catch(Exception ex)
{
    throw ex;
}

ক্যাচ না করে অবশেষে চেষ্টা করা পুরোপুরি বৈধ:

try
{
    listView1.BeginUpdate();

    // If an exception occurs in the following code, then the finally will be executed
    // and the exception will be thrown
    ...
}
finally
{
    // I WANT THIS CODE TO RUN EVENTUALLY REGARDLESS AN EXCEPTION OCCURED OR NOT
    listView1.EndUpdate();
}

আমি শীর্ষ স্তরে কী করি:

// i.e When the user clicks on a button
try
{
    ...
}
catch(Exception ex)
{
    ex.Log(); // Log exception

    -- OR --

    ex.Log().Display(); // Log exception, then show it to the user with apologies...
}

আমি কিছু ডাকা ফাংশনে যা করি:

// Calculation module
try
{
    ...
}
catch(Exception ex)
{
    // Add useful information to the exception
    throw new ApplicationException("Something wrong happened in the calculation module :", ex);
}

// IO module
try
{
    ...
}
catch(Exception ex)
{
    throw new ApplicationException(string.Format("I cannot write the file {0} to {1}", fileName, directoryName), ex);
}

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

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

// Usage:

try
{
    // boom
}
catch(Exception ex)
{
    // Only log exception
    ex.Log();

    -- OR --

    // Only display exception
    ex.Display();

    -- OR --

    // Log, then display exception
    ex.Log().Display();

    -- OR --

    // Add some user-friendly message to an exception
    new ApplicationException("Unable to calculate !", ex).Log().Display();
}

// Extension methods

internal static Exception Log(this Exception ex)
{
    File.AppendAllText("CaughtExceptions" + DateTime.Now.ToString("yyyy-MM-dd") + ".log", DateTime.Now.ToString("HH:mm:ss") + ": " + ex.Message + "\n" + ex.ToString() + "\n");
    return ex;
}

internal static Exception Display(this Exception ex, string msg = null, MessageBoxImage img = MessageBoxImage.Error)
{
    MessageBox.Show(msg ?? ex.Message, "", MessageBoxButton.OK, img);
    return ex;
}

— ল্যারি
সূত্র

98

catch(Exception ex) { throw ex; }সি # এ অপ্রয়োজনীয়ের চেয়েও খারাপ (আপনি যে ব্যতিক্রম ধরছেন তা নির্বিশেষে)। পুনর্বিবেচনা করতে, ব্যবহার করুন throw;। প্রাক্তনটির সাথে, ব্যতিক্রমটি দেখতে পাবেন যেমনটি এটির উত্তর থেকেই রয়েছে throw exতবে এটি সঠিকভাবে মূল throwবিবৃতি থেকে উদ্ভূত হবে ।

— একটি সিভিএন

2

আপনি কেন Application.ThreadExceptionইভেন্টটি হুক করেন এবং একটি ব্যতীত প্রতিটি ব্যতিক্রম গুটিয়ে যান catch(Exception ex) {ex.Log(ex);}। আমি সম্ভবত একমত হব যে পূর্ববর্তীটি একটি দুর্দান্ত অনুশীলন, তবে পরবর্তীটি আপনার ত্রুটিযুক্ত লগগুলি নকল করার ঝুঁকি যুক্ত করে এবং ব্যতিক্রম ঘটেছে তা লুকিয়ে রাখে। এছাড়াও throw exখুব খারাপ।

— কিথ

1

আমি ধরা সম্পর্কে বুঝতে পেরেছি (ব্যতিক্রম ex) {নিক্ষেপ প্রাক্তন; use অকেজো হওয়া। সুতরাং আমি অনুমান করি "রিডানডান্ট" "এটি করবেন না" বলতে সর্বোত্তম শব্দ নয়। সে কারণেই আমি পোস্টটিকে কিছুটা আরও ভাল করে জানিয়েছি যে চেষ্টা করার চেষ্টা করার দুটি প্রথম উদাহরণ এড়ানো উচিত।

— ল্যারি

3

দুর্দান্ত এবং গঠনমূলক উত্তর, সর্বোপরি আমি কেবল বায়ু :) এই শব্দটি উপভোগ করেছি এবং Application.ThreadExceptionইভেন্টটির জন্য ধন্যবাদ , আমি এটি সম্পর্কে খুব একটা দরকারী ছিল না।

— মাহদী তাহসিলদারি

4

এমএসডিএন পরামর্শ দেয় যে আপনার কোডটিতে অ্যাপ্লিকেশনএক্সেপশন ব্যতিক্রম করা উচিত নয় ।

— ডেভিডআরআর

61

সর্বোত্তম অনুশীলন হ'ল ব্যতিক্রম হ্যান্ডলিংয়ের বিষয়টি কখনই আড়াল করা উচিত নয় । এর অর্থ হ'ল try-catchব্লকগুলি অত্যন্ত বিরল হওয়া উচিত।

3 টি পরিস্থিতিতে রয়েছে যেখানে একটি ব্যবহার করে try-catchবোঝা যায়।

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

মনে করুন আপনি কোনও দূরবর্তী এপিআইতে সংযোগ করছেন, এখানে আপনি কিছু ত্রুটি আশা করতে জানেন (এবং সেই পরিস্থিতিতে কিছু থাকতে পারে), সুতরাং এটি 1 কেস:

try 
{
    remoteApi.Connect()
}
catch(ApiConnectionSecurityException ex) 
{
    // User's security details have expired
    return false;
}

return true;

নোট করুন যে অন্য কোনও ব্যতিক্রম ধরা পড়ে না, যেমনটি প্রত্যাশিত নয়।

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

try
{
    DBConnection.Save();
}
catch
{
    // Roll back the DB changes so they aren't corrupted on ANY exception
    DBConnection.Rollback();

    // Re-throw the exception, it's critical that the user knows that it failed to save
    throw;
}

নোট করুন যে আমরা ব্যাতিক্রমটি আবার ছুঁড়েছি - উচ্চতর কোডটিতে এখনও কিছুটা ব্যর্থ হয়েছে তা জানতে হবে।

পরিশেষে আমাদের ইউআই আছে - এখানে আমরা সম্পূর্ণরূপে হাতছাড়া হওয়া ব্যতিক্রম করতে চাই না, তবে আমরা সেগুলিও গোপন করতে চাই না। এখানে আমাদের কেস 3 এর উদাহরণ রয়েছে:

try
{
    // Do something
}
catch(Exception ex) 
{
    // Log exception for developers
    WriteException2LogFile(ex);

    // Display message to users
    DisplayWarningBox("An error has occurred, please contact support!");
}

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

এর অর্থ হ'ল কেস 1 (পরিচিত ব্যতিক্রমগুলি) এবং কেস 3 (ওয়ান অফ অফ ইউআই হ্যান্ডলিং) উভয়েরই আরও ভাল নিদর্শন রয়েছে (প্রত্যাশিত ত্রুটি বা হাতের ত্রুটিটি ইউআই-তে হ্যান্ডলিং এড়ানো)।

এমনকি কেস 2 আরও ভাল নিদর্শন দ্বারা প্রতিস্থাপন করা যেতে পারে, উদাহরণস্বরূপ লেনদেনের স্কোপগুলি ( usingব্লকগুলি যে কোনও লেনদেনের সময় সংঘটিত হয় না) বিকাশকারীদের সেরা অনুশীলনের প্যাটার্নটিকে ভুল পেতে শক্ত করে তোলে।

উদাহরণস্বরূপ ধরুন আপনার কাছে বড় আকারের ASP.Net অ্যাপ্লিকেশন রয়েছে। ত্রুটি লগিং হতে পারে মাধ্যমে ELMAH , ত্রুটি প্রদর্শন স্থানীয়ভাবে একটি তথ্যপূর্ণ YSoD এবং উত্পাদন মধ্যে একটা চমৎকার স্থানীয় বার্তা হতে পারে না। ডাটাবেস সংযোগগুলি সমস্ত লেনদেনের স্কোপ এবং usingব্লকগুলির মাধ্যমে হতে পারে । আপনার একক try-catchব্লকের দরকার নেই ।

টিএল; ডিআর: সেরা অনুশীলন হ'ল try-catchব্লকগুলি একেবারেই ব্যবহার না করা ।

— কিথ
সূত্র

4

@ জোর্জ আপনার পুরো পোস্টটি পড়া উচিত, এবং আপনি যদি এখনও একমত না হন তবে আমার সমর্থনকারী যুক্তিগুলির বিরুদ্ধে লড়াই করা আরও গঠনমূলক হবে, কেবল এই কথাটি বলার চেয়ে যে আপনি আমার সিদ্ধান্তটি পছন্দ করেন না। এর চেয়ে প্রায় সবসময় আরও ভাল প্যাটার্ন থাকে try-catch- এটি (খুব মাঝেমধ্যে) কার্যকর হতে পারে এবং আমি তর্ক করছি না যে আপনার কখনই সেগুলি ব্যবহার করা উচিত নয়, তবে 99% সময়ের আরও ভাল উপায় রয়েছে।

— কিথ

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

— b_levitt

34

একটি ব্যতিক্রম একটি ব্লকিং ত্রুটি ।

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

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

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

উদাহরণস্বরূপ, যদি আপনি জানেন যে কিছু পূর্ণসংখ্যার ইনপুটটি একটি অবৈধ ফর্ম্যাট নিয়ে আসতে পারে তবে তার int.TryParseপরিবর্তে ব্যবহার করুন int.Parse। এমন অনেকগুলি ঘটনা রয়েছে যেখানে আপনি "যদি এটি ব্যর্থ হয় তবে কেবল একটি ব্যতিক্রম ছুঁড়ে" বলার পরিবর্তে এটি করতে পারেন।

ব্যতিক্রম ছোঁড়া ব্যয়বহুল।

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

এএসপি.এনইটি : গ্লোবাল.অ্যাস্যাক্স অ্যাপ্লিকেশন_রর
অন্যান্য: অ্যাপডোমাইন.ফার্সচেঞ্জ এক্সেপশন ইভেন্ট ।

আমার অবস্থান হ'ল স্থানীয় চেষ্টা / ক্যাচগুলি বিশেষ কেসগুলি পরিচালনা করার জন্য আরও উপযুক্ত where কোনও ত্রুটিযুক্ত ব্যতিক্রম ছড়িয়ে দেওয়া যা পুরো বাগটিটি কার্যকর করতে আপনাকে নিঃশব্দ করা প্রয়োজন)।

বাকি মামলার জন্য:

ব্যতিক্রম এড়ানোর চেষ্টা করুন।
যদি এটি সম্ভব না হয়: প্রথম-সুযোগ ব্যতিক্রম হ্যান্ডলার।
অথবা একটি পোস্টশার্প দিক (এওপি) ব্যবহার করুন।

কিছু মন্তব্যে @ সাদাবাইটকে উত্তর দিচ্ছি ...

@ হোয়াইটাম্বিট বলেছেন:

ব্যতিক্রমগুলি মারাত্মক ত্রুটি নয়, তারা ব্যতিক্রম! কখনও কখনও তারা ত্রুটিও হয় না, তবে তাদের মারাত্মক-ত্রুটিগুলি বিবেচনা করা ব্যতিক্রমগুলি কী তা সম্পূর্ণ মিথ্যা বোঝা।

প্রথমত, কিভাবে একটি ব্যতিক্রম এমনকি ত্রুটি হতে পারে না?

কোনও ডাটাবেস সংযোগ => ব্যতিক্রম নয়।
কিছু টাইপ => ব্যতিক্রমকে বিশ্লেষণ করতে অবৈধ স্ট্রিং ফর্ম্যাট
জেএসএনকে বিশ্লেষণ করার চেষ্টা করছে এবং ইনপুট আসলে জেএসওএন => ব্যতিক্রম নয়
আর্গুমেন্ট nullযখন বস্তুর আশা ছিল => ব্যতিক্রম
কিছু লাইব্রেরিতে একটি বাগ => রয়েছে অপ্রত্যাশিত ব্যতিক্রম
এখানে একটি সকেট সংযোগ রয়েছে এবং এটি সংযোগ বিচ্ছিন্ন হয়ে যায়। তারপরে আপনি কোনও বার্তা => ব্যতিক্রম প্রেরণের চেষ্টা করবেন
...

যখন একটি ব্যতিক্রম নিক্ষিপ্ত হয় 1k মামলা তালিকা পারে এবং সব পরে, সম্ভব মামলার কোনো হতে হবে একটি ত্রুটি ।

ব্যতিক্রম হয় , একটি ত্রুটি কারণ দিনের শেষে এটা একটা বস্তুর ডায়গনিস্টিক তথ্য সংগ্রহ - এটা একটি বার্তা রয়েছে এবং এটি ঘটে যখন কিছু গোলমাল হয়।

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

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

[...] তাদের বিবেচনা করুন মারাত্মক ত্রুটিগুলি ব্যতিক্রমগুলি কী তা সম্পূর্ণ মিথ্যা বোঝা।

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

@TheWitembit উদ্বেগ সম্পর্কে আরও উত্তর

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

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

একটি অযথিত ব্যতিক্রম সাধারণত একটি ত্রুটি হয়ে যায়, তবে ব্যতিক্রমগুলি নিজেই কোডড্রজেক্ট নয় / আর্টিকেলগুলি / 15921/ নয়- সব- এক্সেক্সশনস -আর- ত্রুটিগুলি

এই নিবন্ধটি কেবল লেখকের মতামত বা দৃষ্টিভঙ্গি।

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

[...] প্রোগ্রামটি চালিয়ে যাওয়ার জন্য উদ্ভূত নির্দিষ্ট ত্রুটিগুলি পরিচালনা করতে এই ব্যতিক্রমগুলি ব্যবহার করা ব্যতিক্রমকে কোডিং বলে। এই অ্যান্টি-প্যাটার্নটি কার্য সম্পাদন এবং রক্ষণাবেক্ষণে সফ্টওয়্যারটিকে দ্রুত হ্রাস করতে পারে।

এটি কোথাও বলে:

ভুল ব্যতিক্রম ব্যবহার

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

সত্য, আমি বিশ্বাস করি যে সফটওয়্যার বিকাশ করা যায় না ব্যবহারের ক্ষেত্রে গুরুত্বের সাথে গ্রহণ করবেন না। যদি আপনি এটি জানেন ...

আপনার ডাটাবেস অফলাইনে যেতে পারে ...
কিছু ফাইল লক করা যেতে পারে ...
কিছু ফর্ম্যাটিং সমর্থিত নাও হতে পারে ...
কিছু ডোমেন বৈধতা ব্যর্থ হতে পারে ...
আপনার অ্যাপ্লিকেশনটি অফলাইন মোডে কাজ করা উচিত ...
যাই হোক না কেন ব্যবহার ক্ষেত্রে ...

... আপনি এর জন্য ব্যতিক্রম ব্যবহার করবেন না । আপনি নিয়মিত নিয়ন্ত্রণ প্রবাহ ব্যবহার করে এই ব্যবহারের ক্ষেত্রে সমর্থন করবেন ।

এবং যদি কিছু অপ্রত্যাশিত ব্যবহারের ক্ষেত্রে আচ্ছাদিত না হয় তবে আপনার কোডটি দ্রুত ব্যর্থ হবে, কারণ এটি একটি ব্যতিক্রম ছুঁড়ে দেবে । ঠিক আছে, কারণ একটি ব্যতিক্রম একটি ব্যতিক্রমী ক্ষেত্রে ।

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

— মাতাস ফিডেমরাইজার
সূত্র

6

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

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

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

— ChrisCW
সূত্র

6

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

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

আপনি একটি নতুন, আরও নির্দিষ্ট ব্যতিক্রম তৈরি করতে এবং নিক্ষেপ করতে পারেন।

int GetInt(int[] array, int index)
{
    try
    {
        return array[index];
    }
    catch(System.IndexOutOfRangeException e)
    {
        throw new System.ArgumentOutOfRangeException(
            "Parameter index is out of range.");
    }
}

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

    try
{
    // Try to access a resource.
}
catch (System.UnauthorizedAccessException e)
{
    // Call a custom error logging procedure.
    LogError(e);
    // Re-throw the error.
    throw;     
}

আমি পুরো " ব্যতিক্রম এবং ব্যতিক্রম হ্যান্ডলিং " বিভাগ এবং ব্যাতিক্রমের জন্য সেরা অভ্যাসগুলি পড়ার পরামর্শ দেব ।

— হামিদ মোসাল্লা
সূত্র

1

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

— fhnaseer
সূত্র

1

ব্যতিক্রম সহ, আমি নিম্নলিখিত চেষ্টা:

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

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

কোডে, এরকম কিছু:

try{
    //Some code here
}
catch(DivideByZeroException dz){
    AlerUserDivideByZerohappened();
}
catch(Exception e){
    treatGeneralException(e);
}
finally{
    //if a IO operation here i close the hanging handlers for example
}

— Sorcerer86pt
সূত্র

1

শূন্য ব্যতিক্রম দ্বারা ভাগ করুন এবং এগুলি এর 0চেয়ে আগে একটি সংখ্যার জন্য আগে পরীক্ষা করে আরও ভাল আচরণ করা হয় try-catch। এছাড়াও Exceptionএখানে জেনেরিক ধরেন কেন ? আপনি আশা করছেন না এমন সমস্ত ক্ষেত্রে এখানে এটি মোকাবেলা করার চেয়ে ত্রুটি বুবলি করা ভাল।

— কিথ

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

— Sorcerer86pt

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

— কিথ

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

— মাইক লেটন

1

দ্বিতীয় পদ্ধতির একটি ভাল এক।

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

try
{
  //do some work
}
catch(Exception exception)
{
   WriteException2LogFile(exception);//it will write the or log the error in a text file
}

আমি আপনাকে আপনার সম্পূর্ণ অ্যাপ্লিকেশন জন্য দ্বিতীয় পদ্ধতির জন্য যান সুপারিশ।

— প্রণয় রানা
সূত্র

2

দ্বিতীয় ত্রুটিটি ব্যবহারকারীকে ত্রুটি দেখা দেওয়ার চেয়ে দেখায় না - উদাহরণস্বরূপ যদি তারা এমন কিছু সংরক্ষণ করে যে তারা জানত না যে এটি ব্যর্থ হয়েছে। catchব্লকগুলি সর্বদা হয় throwব্যতিক্রমকে বুদবুদ করার জন্য কল করা উচিত বা কিছু ফিরিয়ে দিতে / এমন কিছু প্রদর্শন করা উচিত যা ব্যবহারকারীকে বলে যে ক্রিয়াটি ব্যর্থ হয়েছে। 6 মাস পরে নয়, যখন তারা এটি পুনরুদ্ধার করার চেষ্টা করে এবং এটি খুঁজে না পায় তখন তারা যখন যা যা হয় তা সংরক্ষণ করতে ব্যর্থ হলে আপনি সমর্থন কলটি পেতে চান।

— কিথ

0

ফাঁকা ধরা ব্লকটি করা আরও খারাপ কাজ। যদি কোনও ত্রুটি থাকে তবে এটি পরিচালনা করার সেরা উপায় হ'ল:

এটিকে ফাইল-ডাটাবেস ইত্যাদিতে লগইন করুন ..
ফ্লাইতে এটি ঠিক করার চেষ্টা করুন (সম্ভবত সেই অপারেশন করার বিকল্প উপায় চেষ্টা করে)
যদি আমরা এটি ঠিক করতে না পারি তবে ব্যবহারকারীকে অবহিত করুন যে কিছু ত্রুটি রয়েছে এবং অবশ্যই অপারেশনটি বাতিল করে দিন

— Stasel
সূত্র

0

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

— থাই আন ডাচ
সূত্র

0

ত্রুটি দেখা দিলে সেরা ব্যায়ামটি ব্যতিক্রম হয় throw কারণ একটি ত্রুটি ঘটেছে এবং এটি লুকানো উচিত নয়।

আপনি যখন এটি আড়াল করতে চান তবে বাস্তব জীবনে আপনার বেশ কয়েকটি পরিস্থিতি থাকতে পারে

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

— গ্রেগরি নোজিক
সূত্র

6

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

— একটি সিভিএন

0

ব্যতিক্রমগুলির জন্য আপনার এই নকশা নির্দেশিকাগুলি বিবেচনা করা উচিত

ব্যতিক্রম ছোঁড়া
স্ট্যান্ডার্ড ব্যতিক্রম প্রকারের ব্যবহার
ব্যতিক্রম এবং পারফরম্যান্স

https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/exceptions

— Jaider
সূত্র

0

catchকোনো আর্গুমেন্ট ছাড়া কেবল হয় খাওয়া ব্যতিক্রম এবং কোন ব্যবহার হয়। মারাত্মক ত্রুটি ঘটলে কী হবে? আপনি যদি যুক্তি ছাড়াই ক্যাচ ব্যবহার করেন তবে কী হয়েছে তা জানার কোনও উপায় নেই।

একটি ক্যাচ স্টেটমেন্টে আরও নির্দিষ্ট ব্যতিক্রম যেমন ধরতে হবে FileNotFoundExceptionএবং তারপরে একেবারে শেষে আপনার ধরা উচিত Exceptionযা অন্য কোনও ব্যতিক্রম ধরা পড়ে এবং লগ করে।

— Anirudha
সূত্র

কেন একজন জেনারেল catch(Exception)শেষে? আপনি যদি এটির প্রত্যাশা না করেন তবে পরবর্তী স্তর পর্যন্ত এটি প্রেরণা সর্বদা সেরা অনুশীলন।

— কিথ

1

@ কিথ হ্যাঁ আপনি ঠিক বলেছেন ... যে ব্যতিক্রমগুলি আপনি প্রত্যাশা করছেন তা ধরার কোনও মানে নেই তবে লগিংয়ের উদ্দেশ্যে আপনি সাধারণ ব্যতিক্রম করতে পারেন ..

— আনিরুধা

0

কখনও কখনও আপনার ব্যতিক্রমগুলি ব্যবহার করা উচিত যা ব্যবহারকারীদের কিছুই বলে না।

আমার উপায়:

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

এটি অবশ্যই সেরা অনুশীলন হতে হবে না। ;-)

— Fanda
সূত্র

0

আমি তোমাকে কিছু বলতে পারি:

স্নিপেট # 1 গ্রহণযোগ্য নয় কারণ এটি ব্যতিক্রম উপেক্ষা করে। (এটি এটিকে গ্রাস করছে যেমন কিছুই হয় নি)।

সুতরাং ক্যাচ ব্লক যুক্ত করবেন না যা কিছুই করে না বা কেবল পুনরায় ব্যবহার করে।

ক্যাচ ব্লকের কিছু মান যুক্ত করা উচিত। উদাহরণস্বরূপ আউটপুট বার্তা শেষ ব্যবহারকারী বা লগ ত্রুটি।

সাধারণ ফ্লো প্রোগ্রাম যুক্তির জন্য ব্যতিক্রম ব্যবহার করবেন না। উদাহরণ স্বরূপ:

যেমন ইনপুট বৈধতা। <- এটি বৈধ ব্যতিক্রমী পরিস্থিতি নয়, বরং IsValid(myInput);ইনপুট আইটেমটি বৈধ কিনা তা পরীক্ষা করার জন্য আপনার পদ্ধতি লিখতে হবে।

ব্যতিক্রম এড়ানোর জন্য ডিজাইন কোড। উদাহরণ স্বরূপ:

int Parse(string input);

যদি আমরা এমন মানটি পাস করি যা ইন্টিতে পার্স করা যায় না, তবে এই পদ্ধতিটি নিক্ষেপ করবে এবং ব্যতিক্রম করবে, এর পরিবর্তে আমরা এরকম কিছু লিখতে পারি:

bool TryParse(string input,out int result); <- এই পদ্ধতিটি পার্স সাফল্যজনক হলে ইঙ্গিত করে যে বুলিয়ান ফিরে আসবে।

হতে পারে এটি এই প্রশ্নের সুযোগের বাইরে কিছুটা নয়, তবে আমি আশা করি যে এটি আপনাকে try {} catch(){}এবং ব্যতিক্রমগুলি সম্পর্কে সঠিক সিদ্ধান্ত নিতে সহায়তা করবে ।

— Roxy'Pro
সূত্র