খালি ক্যাচগুলি কেন খারাপ ধারণা? [বন্ধ]

192

বন্ধ । এই প্রশ্নটি মতামত ভিত্তিক । এটি বর্তমানে উত্তর গ্রহণ করছে না।

এই প্রশ্নটি উন্নত করতে চান? প্রশ্নটি আপডেট করুন যাতে পোস্টটি সম্পাদনা করে সত্য এবং উদ্ধৃতি দিয়ে উত্তর দেওয়া যায় ।

4 বছর আগে বন্ধ ছিল ।

এই প্রশ্নটি উন্নত করুন

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

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

exception-handling try-catch

— স্যামুয়েল ক্যারিজো
সূত্র

53

কেন এটি খালি থাকতে হবে তা ব্যাখ্যা করে আমি একটি মন্তব্য লিখব।

— মেহরদাদ আফশারি

5

... বা কমপক্ষে লগ হ'ল এটি ধরা পড়েছিল।

— ম্যাট বি

2

@ ওসিডিসিও: ক্লিনআপ কোডের জন্য এড়িয়ে চলুন, এটিকে সাধারণভাবে এড়িয়ে চলুন না।

— জন স্যান্ডার্স

1

@ ওসিডেসিও: ট্রাই ব্যবহার না করার জন্য আরেকটি ঘটনা .c যেমন সংখ্যার রূপান্তর ব্যতিক্রমগুলি

— এমপিপ্রচার্ড

1

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

— নট

297

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

এটি ইঞ্জিনের সতর্কতার আলোতে কালো টেপ লাগানোর সমতুল্য।

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

— নেড ব্যাচেল্ডার
সূত্র

4

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

— জন রুডি

37

সাদৃশ্যটিও পছন্দ করুন - এবং সমস্ত নিয়মের মতো ব্যতিক্রমও রয়েছে। উদাহরণস্বরূপ আপনার ভিসিআরের জ্বলজ্বল ঘড়ির উপরে কালো টেপ ব্যবহার করা পুরোপুরি ঠিক OK

— মাইকেল বুড়

3

গৃহীত অনুশীলন থেকে যে কোনও প্রস্থানের মতো, উপযুক্ত হলে এটি করুন এবং এটি নথি করুন যাতে পরবর্তী লোক জানে যে আপনি কী করেছেন এবং কেন।

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

5

@ জেসন: খুব কমপক্ষে, আপনি কেন ব্যতিক্রমগুলি চুপ করে যাচ্ছেন তা বোঝাতে একটি বিশদ মন্তব্য অন্তর্ভুক্ত করা উচিত।

— নেড ব্যাচেল্ডার

1

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

— বরিস বি।

38

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

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

— অ্যাডাম রবিনসন
সূত্র

11

আমি যতদূর বলতে পারি না যে কে খালি ক্যাচ ব্লক ব্যবহার করে বাজে প্রোগ্রামার এবং সে জানে না যে সে কী করছে ...

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

উদাহরণস্বরূপ, কিছু HTTP সার্ভার লাইব্রেরি বিবেচনা করুন, সার্ভার যদি ব্যতিক্রম ছুঁড়ে দেয় তবে আমি কম যত্ন করতে পারি না কারণ ক্লায়েন্ট সংযোগ বিচ্ছিন্ন হয়ে গেছে এবং index.htmlপাঠানো যায় না।

— লুবস হাসকো
সূত্র

6

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

— বেন ভয়েগট

8

বিরল দৃষ্টান্ত রয়েছে যেখানে এটি ন্যায়সঙ্গত হতে পারে। পাইথনে আপনি প্রায়শই এই ধরণের নির্মাণ দেখতে পান:

try:
    result = foo()
except ValueError:
    result = None

সুতরাং এটি করা ঠিক হতে পারে (আপনার প্রয়োগের উপর নির্ভর করে):

result = bar()
if result == None:
    try:
        result = foo()
    except ValueError:
        pass # Python pass is equivalent to { } in curly-brace languages
 # Now result == None if bar() returned None *and* foo() failed

সাম্প্রতিক। নেট প্রকল্পে, একটি নির্দিষ্ট ইন্টারফেস প্রয়োগকারী ক্লাসগুলি খুঁজতে আমাকে প্লাগইন ডিএলএল গণনা করার জন্য কোড লিখতে হয়েছিল। কোডের প্রাসঙ্গিক বিট (ভিবি.এনইটি তে, দুঃখিত) হ'ল:

    For Each dllFile As String In dllFiles
        Try
            ' Try to load the DLL as a .NET Assembly
            Dim dll As Assembly = Assembly.LoadFile(dllFile)
            ' Loop through the classes in the DLL
            For Each cls As Type In dll.GetExportedTypes()
                ' Does this class implement the interface?
                If interfaceType.IsAssignableFrom(cls) Then

                    ' ... more code here ...

                End If
            Next
        Catch ex As Exception
            ' Unable to load the Assembly or enumerate types -- just ignore
        End Try
    Next

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

— ড্যানিয়েল প্রাইডেন
সূত্র

আপনার উত্তরটি দেখার আগে আমি লগ 4 নেটকে সেই উদাহরণগুলির মধ্যে একটি হিসাবে উল্লেখ করেছি।

— স্কট লরেন্স 18

7

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

সম্পর্কিত নোটে, বেশিরভাগ লোকেরা জানেন না যে একটি ক্যাপচ with} বা শেষ অবধি with either দিয়ে একটি চেষ্টা ব্লক অনুসরণ করা যেতে পারে, কেবল একটির প্রয়োজন।

— জাস্টিন
সূত্র

1

+1 আমি যুক্ত প্রভাবের জন্য সেই শেষ বাক্যে 'বা' চাপ দিয়েছি

— এমপিপ্রচার্ড

দ্বিতীয় অনুচ্ছেদে ভাষা নির্ভর হতে পারে, যদিও, ঠিক?

— ডেভিড জেড

3

অবশ্যই আপনি আই 6 বা আই 7 ;-) সম্পর্কে কথা বলছেন ... যেখানে ধরা দরকার বা শেষ পর্যন্ত কার্যকর হয় না। (এটি

— আইই

সূত্র: webbugtrack.blogspot.com/2007/11/…

— স্কানলিফ

খুবই সত্য. ভাষা হাইলাইট মূল্য হতে পারে। আমি বিশ্বাস করি। নেট ঠিক আছে

— এমপিপ্রচার্ড

7

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

আপনি যদি ব্যতিক্রমটি পরিচালনা করতে না চান, এটি কোনও হ্যান্ডেল করতে পারে এমন কোনও কোড না পৌঁছানো পর্যন্ত এটি উপরের দিকে প্রচার করুন। কিছু যদি ব্যতিক্রম পরিচালনা করতে না পারে তবে অ্যাপ্লিকেশনটি নীচে নামানো উচিত।

— রিড কোপসি
সূত্র

3

কখনও কখনও আপনি জানেন যে এটি কিছু প্রভাবিত করবে না। তারপরে এগিয়ে যান এবং এটি করুন, এবং মন্তব্য করুন যাতে পরের লোকটি কেবল আপনাকে অক্ষম বলে মনে করেন না যে আপনি অক্ষম।

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

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

— রিড কোপসি

2

@ ডেভিড থর্নলি: আপনি কীভাবে জানবেন যে এটি কোনও প্রত্যাশিত এবং অর্থহীন ত্রুটি বা এর পরিবর্তে wardর্ধ্বমুখী প্রচারিত হওয়া উচিত কিনা তা নির্ধারণের জন্য ব্যতিক্রম পরিদর্শন না করলে এটি কোনও কিছুর উপর প্রভাব ফেলবে না?

— ডেভ শেরোহমান

2

@ ডেভ: যদিও catch (Exception) {}একটি খারাপ ধারণা, catch (SpecificExceptionType) {}পুরোপুরি ঠিক আছে। প্রোগ্রামার ডিআইডি ক্যাচ ক্লজে টাইপ তথ্য ব্যবহার করে ব্যতিক্রমটি পরীক্ষা করে।

— বেন ভয়েগট

7

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

তবে সে ক্ষেত্রেও একটি ডিবাগ বার্তা ক্রমযুক্ত হতে পারে।

— balpha
সূত্র

5

প্রতি জোশ ব্লচ - আইটেম 65: দো ব্যতিক্রমসমূহ উপেক্ষা করতে এর কার্যকরী জাভা :

একটি খালি ক্যাচ ব্লক ব্যতিক্রমগুলির উদ্দেশ্যকে পরাস্ত করে
খুব কমপক্ষে, ক্যাচ ব্লকের একটি মন্তব্য থাকতে হবে যাতে ব্যতিক্রম উপেক্ষা করা কেন উপযুক্ত expla

— KrishPrabakar
সূত্র

3

একটি খালি ক্যাচ ব্লকটি মূলত বলছে "আমি কী ত্রুটি নিক্ষেপ করা হয় তা জানতে চাই না, আমি কেবল তাদের এড়িয়ে চলেছি।"

এটি ভিবি 6 এর মতো On Error Resume Next, ব্যতিক্রম ছোঁড়ার পরে চেষ্টা ব্লকের কিছু বাদ দেওয়া হবে।

যা তখন কিছু ভেঙে গেলে সহায়তা করে না।

— Powerlord
সূত্র

আমি আসলে বলতে পারি "অন ত্রুটি পুনরায় শুরু করুন পরবর্তী" আরও খারাপ - এটি পরের লাইনেই নির্বিশেষে চেষ্টা করবে। একটি খালি ক্যাচ চেষ্টা বিবৃতিটির সমাপ্তি বন্ধনী পাস করতে লাফিয়ে যাবে

— এমপিপ্রচার্ড

ভাল যুক্তি. আমি সম্ভবত আমার প্রতিক্রিয়া লক্ষ্য করা উচিত।

— পাওয়ারলর্ড

1

এটি ঠিক সত্য নয়, যদি আপনার একটি খালি চেষ্টা থাকে ... একটি নির্দিষ্ট ব্যতিক্রম ধরণের সাথে ধরেন, তবে এটি কেবল এই ধরণের ব্যতিক্রম উপেক্ষা করবে এবং এটি বৈধ হতে পারে ...

— মেটা-নাইট

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

— স্কট লরেন্স 18

@ স্কট: কিছু ভাষা (যেমন জাভা) ব্যতিক্রমগুলি চেক করেছে ... ব্যতিক্রমগুলি আপনাকে ক্যাচ ব্লক লিখতে বাধ্য করা হয়েছে।

— পাওয়ারলর্ড

3

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

— চিত্রকল্পবাদ
সূত্র

2

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

— complexcipher
সূত্র

1

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

— Nate
সূত্র

1

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

— দেনিযেল
সূত্র

1

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

— AndersK
সূত্র

1

এটি সম্ভবত কখনও সঠিক জিনিস নয় কারণ আপনি চুপচাপ প্রতিটি সম্ভাব্য ব্যতিক্রমটি অতিক্রম করছেন । যদি আপনি যে সুনির্দিষ্ট ব্যতিক্রম প্রত্যাশা করছেন সেখানে যদি থাকে তবে তার জন্য আপনার পরীক্ষা করা উচিত, যদি এটি আপনার ব্যতিক্রম না হয় তবে পুনর্বিবেচনা করুন।

try
{
    // Do some processing.
}
catch (FileNotFound fnf)
{
    HandleFileNotFound(fnf);
}
catch (Exception e)
{
    if (!IsGenericButExpected(e))
        throw;
}

public bool IsGenericButExpected(Exception exception)
{
    var expected = false;
    if (exception.Message == "some expected message")
    {
        // Handle gracefully ... ie. log or something.
        expected = true;
    }

    return expected;
}

— xanadont
সূত্র

1

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

— পাঠ করা যায়

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

— xanadont

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

— xanadont

2

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

— উইম কোয়েন

Eek। ব্যতিক্রম.মেসেজ স্থানীয়করণ করা যেতে পারে এবং এভাবে আপনি যা আশা করেন তা তা নয় not এটা ঠিক ভুল।

— ফ্র্যাঙ্কোমার্স

1

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

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

আরেকটি উদাহরণ: সিএলআর 2.0 ২. চূড়ান্তকরণকারী থ্রেডে হাতছাড়া হওয়া ব্যতিক্রমগুলি আচরণ করার পদ্ধতি পরিবর্তন করেছে। 2.0 এর আগে প্রক্রিয়াটিকে এই পরিস্থিতিতে বেঁচে থাকার অনুমতি দেওয়া হয়েছিল। বর্তমান সিএলআর-এ চূড়ান্তকরণকারী থ্রেডে একটি অপরিবর্তিত ব্যতিক্রম ঘটলে প্রক্রিয়াটি সমাপ্ত হয়।

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

— ব্রায়ান রাসমুসেন
সূত্র

1

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

সুতরাং, আপনার উদাহরণ সহকারে, সে ক্ষেত্রে এটি একটি খারাপ ধারণা কারণ আপনি সমস্ত ব্যতিক্রমগুলি ধরা এবং উপেক্ষা করছেন । আপনি যদি কেবল ধরা EInfoFromIrrelevantSourceNotAvailableএবং এড়িয়ে যাচ্ছিলেন তবে তা ঠিক আছে, তবে আপনি নন। আপনি এড়াচ্ছেন ENetworkIsDown, যা গুরুত্বপূর্ণ বা নাও হতে পারে। আপনি উপেক্ষা করছেন ENetworkCardHasMeltedএবংEFPUHasDecidedThatOnePlusOneIsSeventeen যা প্রায় অবশ্যই গুরুত্বপূর্ণ are

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

— ডেভ শেরোহমান
সূত্র

1

এমন পরিস্থিতি রয়েছে যেখানে আপনি সেগুলি ব্যবহার করতে পারেন তবে সেগুলি খুব কমই হওয়া উচিত। আমি যে কোনও পরিস্থিতিতে ব্যবহার করতে পারি সেগুলির মধ্যে রয়েছে:

ব্যতিক্রম লগিং; প্রসঙ্গের উপর নির্ভর করে আপনি তার পরিবর্তে পোস্টহীন ব্যতিক্রম বা বার্তা পোস্ট করতে পারেন want
প্রযুক্তিগত পরিস্থিতি, যেমন রেন্ডারিং বা সাউন্ড প্রসেসিং বা একটি তালিকার বাক্স কলব্যাকের মতো লুপিং, যেখানে আচরণটি নিজেই সমস্যাটি দেখায় সেখানে একটি ব্যতিক্রম ছুঁড়ে ফেলার উপায়টি পাওয়া যায় এবং ব্যতিক্রমটি লগ ইন করলে সম্ভবত 1000 এর "এক্সএক্সএক্সএফ ব্যর্থ" বার্তাগুলি আসে ।
প্রোগ্রামগুলি যে ব্যর্থ হতে পারে না , যদিও তাদের এখনও কমপক্ষে কিছু লগইন করা উচিত।

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

  public static bool TryAction(Action pAction)
  {
     try { pAction(); return true; }
     catch (Exception exception)
     {
        LogException(exception);
        return false;
     }
  }

  public static bool TryActionQuietly(Action pAction)
  {
     try { pAction(); return true; }
     catch(Exception exception)
     {
        LogExceptionQuietly(exception);
        return false;
     }
  }

  public static void LogException(Exception pException)
  {
     try
     {
        AlertBox(pException, true);
        LogExceptionQuietly(pException);
     }
     catch { }
  }

  public static void LogExceptionQuietly(Exception pException)
  {
     try { Debug.WriteLine("Exception: {0}", pException.Message); } catch { }
  }

তারপরে প্রতিটি ইভেন্ট হ্যান্ডলার এর মতো কিছু করতে পারে:

  private void mCloseToolStripMenuItem_Click(object pSender, EventArgs pEventArgs)
  {
     EditorDefines.TryAction(Dispose);
  }

অথবা

  private void MainForm_Paint(object pSender, PaintEventArgs pEventArgs)
  {
     EditorDefines.TryActionQuietly(() => Render(pEventArgs));
  }

তাত্ত্বিকভাবে, আপনি চেষ্টা করতে পারেন নিবন্ধন কল যা রেন্ডারিং জন্য ভাল হতে পারে যাতে একটি ব্যতিক্রম অন্তহীন পরিমাণ বার্তা উত্পন্ন না করে।

— ডেভ কাজিনো
সূত্র

1

আপনি যদি ক্যাচ ব্লকে কী করবেন তা জানেন না, আপনি কেবল এই ব্যতিক্রমটি লগ করতে পারেন, তবে এটিকে ফাঁকা রাখবেন না।

        try
        {
            string a = "125";
            int b = int.Parse(a);
        }
        catch (Exception ex)
        {
            Log.LogError(ex);
        }

— আন্দজেজ ম্যাকিয়াসোভিচ
সূত্র

কেন এই নিম্নমানের ছিল?

— ভিনো

0

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

— Chadit
সূত্র