33

যদি কোনও পদ্ধতি থাকে

bool DoStuff() {
    try {
        // doing stuff...
        return true;
    }
    catch (SomeSpecificException ex) {
        return false;
    }
}

এটি বরং বলা উচিত IsStuffDone()?

উভয় নামের ব্যবহারকারীর দ্বারা ভুল ব্যাখ্যা করা যেতে পারে: যদি নাম হয় DoStuff()তবে এটি কেন বুলিয়ান ফিরিয়ে দেয়? নামটি থাকলে IsStuffDone()পদ্ধতিটি কোনও কার্য সম্পাদন করে বা কেবল তার ফলাফলটি পরীক্ষা করে কিনা তা পরিষ্কার নয়।

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

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

— লিম্বো নির্বাসন
সূত্র

2

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

— বেনি

7

বেশিরভাগ সময়, আমি এটিকে "ভাঙ্গা" বলি কারণ মোড়কের booleanবদলে ফিরে আসা বা ব্যতিক্রমটি পাস করা প্রায় সর্বদা ভুল।

— মার্টিনাস

2

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

— কোডসইনচওস

2

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

— বব জার্ভিস - মনিকা

5

যারা বলছেন তাদের সকলের জন্য: কেবল একটি ব্যতিক্রম ছুঁড়ে ফেলুন (বা পাস করুন), আপনি এই কোডটি কীভাবে ব্যবহার হচ্ছে তা নিয়ে ভিত্তিহীন অনুমান করছেন। একটি সম্ভাব্য পরিস্থিতি হ'ল সমস্যা সমাধানের বিভিন্ন সমস্যা রয়েছে, বিভিন্ন ধরণের হিউরিস্টিক সমাধান পদ্ধতি যা ক্রমবর্ধমান ব্যয়ে সমস্যার আরও বড় সাবক্লাস সমাধান করে; এরকম কিছু লেখার অর্থ হবে if (FirstMethodSucceeds(problem) or SecondMethodSucceeds(problem) or ...) Hurray(); else UniversalSolve(problem);। (কাস্টম?) ব্যতিক্রমগুলি দিয়ে একই কাজ করা অযথা আরো জটিল হবে।

— মার্ক ভ্যান লিউউয়েন

68

.NET- এ, আপনার প্রায়শই এমন পদ্ধতিগুলির জোড়া থাকে যেখানে তাদের মধ্যে একটি ব্যতিক্রম ( DoStuff) ফেলে দিতে পারে এবং অন্যটি বুলিয়ান স্ট্যাটাসটি প্রদান করে এবং সফলভাবে কার্যকর করার পরে, আউট প্যারামিটারের মাধ্যমে প্রকৃত ফলাফল ( TryDoStuff)।

(মাইক্রোসফ্ট এটিকে "ট্রাই পার্স প্যাটার্ন" বলে , যেহেতু সম্ভবত এটির জন্য সবচেয়ে সুস্পষ্ট উদাহরণ TryParseবিভিন্ন আদিম ধরণের পদ্ধতি))

তাহলে Tryউপসর্গ আপনার ভাষায় বিরল হয়, তাহলে আপনি সম্ভবত এটি ব্যবহার করা উচিত নয়।

— ne2dmar
সূত্র

3

+1 আমি অন্য কোথাও এই ধরণের জিনিসটি দেখেছি। if (TryDoStuff()) print("Did stuff"); else print("Could not do stuff");আমার মতে এটি বেশ মানসম্পন্ন এবং স্বজ্ঞাত প্রজ্ঞাময়।

— কার্ল নিকল

12

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

— ট্রিলিয়ান

এফওয়াইআই, Remove.NET ফ্রেমওয়ার্কে উদাহরণস্বরূপ এমনও রয়েছে যেগুলি ডেটা স্ট্রাকচার (যেমন Dictionary) থেকে কোনও উপাদান সরিয়ে ফেলবে এবং এটিকে ফিরিয়ে দেবে bool। এপিআইর গ্রাহকরা এটি গ্রহণ বা এড়িয়ে যাওয়ার সিদ্ধান্ত নিতে পারেন। তবে ত্রুটিগুলি ব্যতিক্রম হিসাবে রিপোর্ট করা হয়েছে।

— ওমর ইকবাল

18

আপনি যদি কেবল কলিং কোডটি ব্যতিক্রম করে ফেলে দেন তবে কী হবে?

এইভাবে আপনি কখন আপনার কোড ব্যবহার করছেন তার ব্যতিক্রম হ্যান্ডলিংকে প্রতিনিধিত্ব করছেন। ভবিষ্যতে আপনি নিম্নলিখিতটি করতে চাইলে কী হবে:

যদি কোনও ব্যতিক্রম ছুঁড়ে না দেওয়া হয় তবে ব্যবস্থা নিন A
যদি (উদাহরণস্বরূপ) একটি FileNotFoundExceptionনিক্ষেপ করা হয়, পদক্ষেপ খ
অন্য কোনও ব্যতিক্রম ছুঁড়ে ফেলা হলে, ব্যবস্থা নিন সি

যদি আপনি আপনার ব্যতিক্রম পিছনে ফেলে দেন তবে উপরের পরিবর্তনটি কেবলমাত্র একটি অতিরিক্ত catchব্লক যুক্ত করতে বাধ্য করবে। যদি আপনি এটি যেমনটি রেখে দেন তবে আপনাকে সেই পদ্ধতি এবং যে স্থান থেকে পদ্ধতিটি বলা হয় সেটিকে পরিবর্তন করতে হবে, যা প্রকল্পের জটিলতার উপর নির্ভর করে একাধিক স্থানে থাকতে পারে।

— npinti
সূত্র

1

যদি ব্যতিক্রমটি এমন ধরনের হয় যেগুলি অর্পণ করা যায় না এবং অভ্যন্তরীণভাবে মোকাবেলা করা উচিত?

— লিম্বো নির্বাসিত

2

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

— npinti

6

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

— কার্ল নিকল

1

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

— ডোভাল

1

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

— কার্ল নিকল

7

DoStuff() যথেষ্ট, এবং ফাংশনটির রিটার্নিং মান নথিভুক্ত করা উচিত, এবং আপনাকে উপলব্ধ অনেকগুলি এপিআই অনুসন্ধান করে ফাংশনের নামে উল্লেখ করার দরকার নেই:

পিএইচপি

// this method update and return the number affected rows 
// called update instead of updateAndGetAffectedCount
$affected = $query->update(/* values */);

সি-শার্প

// Remove item from the List
// returns true if item is successfully removed; otherwise, false.
public bool Remove( T item )

— AMD
সূত্র

6

জাভাতে, সংগ্রহের এপিআই একটি অ্যাড পদ্ধতি সংজ্ঞায়িত করে যা একটি বুলিয়ান দেয়। এটি মূলত অ্যাডের সংগ্রহ পরিবর্তন করেছে কিনা তা ফিরিয়ে দেয়। সুতরাং Listএটির জন্য এটি সাধারণত সত্য হবে, যেহেতু আইটেমটি যুক্ত করা হয়েছিল, যখন Setএটির জন্য এটি ইতিমধ্যে উপস্থিত থাকলে এটি মিথ্যা ফিরতে পারে, যেহেতু Setপ্রতিটি অনন্য আইটেমকে একবারে অনুমতি দেয়।

এটি বলে, আপনি যদি কোনও আইটেম যোগ করেন যা সংগ্রহের দ্বারা অনুমোদিত নয়, উদাহরণস্বরূপ, একটি নাল মান, NullPointerExceptionঅ্যাডটি মিথ্যা প্রত্যাবর্তনের পরিবর্তে একটি নিক্ষেপ করবে ।

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

— mrjink
সূত্র

1

বিভিন্ন কারণে ব্যতিক্রম হতে পারে, ব্যতিক্রম, সাধারণ শর্ত, তাই এটি ব্যবহার করবে:

boolean doStuff() - returns true when successful

বুলিয়ান মানে কী তা নথিভুক্ত করা গুরুত্বপূর্ণ।

— user136354
সূত্র

1

আমার সাধারণত পদ্ধতিগুলি একটি OperationResult(বা OperationResult<T>) ফেরত দেয় এবং IsSuccessসম্পত্তি OperationResultযথাযথভাবে সেট করে । যদি 'সাধারণ' পদ্ধতিটি বাতিল থাকে তবে ফিরে আসুন OperationResult, যদি 'স্বাভাবিক' পদ্ধতিটি কোনও বস্তু ফেরত দেয় তবে ফিরে আসুন OperationResult<T>এবং যথাযথভাবে Itemসম্পত্তি সেট করুন OperationResult। আমি OperationResultযেমন .Failed(string reason)এবং এর পদ্ধতি থাকার পরামর্শ দিই .Succeeded(T item)। OperationResultআপনার সিস্টেমে দ্রুত পরিচিত ধরণের হয়ে ওঠে এবং বিকাশকারীরা কীভাবে এটি পরিচালনা করবেন তা জানতে পারেন।

— স্কট রিকম্যান
সূত্র

0

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

উদাহরণস্বরূপ, অবজেক্টিভ-সি ভাষায় এবং আইওএস / ম্যাক ওএস এক্স এসডি কে পদ্ধতির নামগুলি সাধারণত:

- (returndatatype) viewDidLoad {
- (returndatatype) isVisible {
- (returndatatype) appendMessage:datatype variablename with:datatype variablename {

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

পিএইচপি-তে, সংযোগ ব্যর্থ হলে মাইএসকিএল_কনেক্ট () মিথ্যা প্রত্যাবর্তন করবে। এটি বলবে না, তবে এটি করে এবং ডকুমেন্টেশন বলে যে এটি তাই করে এটি প্রোগ্রামারের কাছে ভুল ব্যাখ্যা করা যায় না।

— Gergy008
সূত্র

আহ, তবে ভিউডিডলড হ'ল কলব্যাক বিজ্ঞপ্তি। ব্যবহারকারীরা ভিউ লোড করার জন্য এটি কল করে না। বরং ভিউ লোড হওয়ার পরে এটি বলা হয়। অনুরূপভাবে: isVisible দৃশ্যমানতা সেট করে না, বরং এটি কেবল বর্তমান মানটি প্রদান করে। এটা না কি কিছু।

— লিলবির্ডি

0

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

তবে, এটি নামকরণের বিষয়ে নয়। এটি আপনি কীভাবে আপনার পদ্ধতির ইনপুট / আউটপুট পরামিতিগুলি ডিজাইন করেন।

আমার ধারণা হ'ল যদি কোনও পদ্ধতির কোনও রিটার্ন মান থাকে তবে সেই পদ্ধতিটি কল করার উদ্দেশ্যটি সেই রিটার্নের মান পাওয়া উচিত। সুতরাং, কোনও অপারেশনের স্থিতি নির্দেশ করতে আপনার রিটার্নের ধরণটি ব্যবহার করা উচিত।

সি # তে আমি আউট প্যারামিটার ব্যবহার করতে পছন্দ করি। একটি আউট ব্যবহার করে আমি প্যারামিটারটিকে পার্শ্ব প্যারামিটার হিসাবে চিহ্নিত করছি। বিশেষভাবে যে সি # 6 ইনলাইন ভেরিয়েবল ঘোষণাকে সমর্থন করবে।

DoStuff(out var isStuffDone); // The out parameter name clearly states its purpose.
DoStuff(out var _); // I use _ for naming parameters that I am ignoring.

— 000
সূত্র

0

আমি পদ্ধতির প্রাথমিক ভূমিকার ভিত্তিতে একটি নাম বেছে নেব। সত্য, এই পদ্ধতিটি বুলিয়ান মানটি 'ইস' উপসর্গের আদেশ দেয় না। আসুন কিছু জাভা কোড আসুন, যা বেশ 'বিস্তৃতভাবে' ইস 'উপসর্গটি ব্যবহার করে। তাকান java.io.File.delete()। এটি ফিরে আসে boolean, কিন্তু এটি বলা হয় না isFileDeleted()। কারণটি হ'ল মেটোডের প্রাথমিক ভূমিকা হ'ল কোনও ফাইল মুছে ফেলা। কেউ এই পদ্ধতিটিকে কোনও ফাইল মুছে ফেলার উদ্দেশ্যে কল করে।

বুলিয়ানটি কেবল কাজের ফলাফলের সাথে সংযুক্ত করতে এসেছে। অন্যদিকে দেখা যাকjava.util.Map.isEmpty() । স্পষ্টতই, আপনি সংগ্রহটি খালি কিনা তা খুঁজে বের করার জন্য আপনি এই জাতীয় পদ্ধতিতে কল করেন। আপনি কোন জিনিস সম্পন্ন করতে চান না। আপনি কেবল বর্তমান অবস্থাটি কী তা জানতে চান।

তাই ব্যক্তিগতভাবে আমি দৃ defin়ভাবেই লেগে থাকব DoStuff()।

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

— জেসেক প্রুসিয়া
সূত্র