আমাকে বলা হয়েছে যে ব্যতিক্রম কেবলমাত্র ব্যতিক্রমী ক্ষেত্রে ব্যবহার করা উচিত। আমার কেস ব্যতিক্রমী হলে আমি কীভাবে জানব?

Question

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

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

তবে এটি আমার বোধগম্য যে ব্যতিক্রমগুলি প্রথম স্থানে আবিষ্কার হয়েছিল। এটা আপনি ব্যবহার করা হয় ছিল ফলাফলের পরিদর্শন করা যদি কোনো ত্রুটি ঘটেছে দেখতে। আপনি যদি চেক করতে ব্যর্থ হন তবে আপনার লক্ষ্য না করে খারাপ কিছু ঘটতে পারে।

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

যাইহোক, আমি এখানে যা বলেছি তা সংশোধন করতে দ্বিধা বোধ করবেন। আমার মূল প্রশ্নটি যদি কেউ বলে যে ব্যতিক্রম ব্যতিক্রমী হওয়া উচিত তবে আমি কীভাবে জানব যে আমার মামলাটি ব্যতিক্রমী কিনা?

Comments

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

— Thorsten müller

ব্যবহারকারীরা বোবা হয়ে গেলে তারা অবৈধ ইনপুট সরবরাহ করে। ব্যবহারকারীরা স্মার্ট হয়ে গেলে তারা অবৈধ ইনপুট সরবরাহ করে খেলেন। সুতরাং, অবৈধ ব্যবহারকারী ইনপুট ব্যতিক্রম নয় an

— mouviciel

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

— এরিক কিং

"ব্যতিক্রমী"! = "বিরল ঘটনা ঘটে"

— কন্ডিশন

আমি এরিক লিপার্টের ভেক্সিং ব্যতিক্রমগুলি শালীন পরামর্শ হিসাবে পাই ।

— ব্রায়ান

Answer 1

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

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

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

Comments

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

— রবার্ট হার্ভে

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

— কার্ল বিলেফেল্ট

@ রবার্টহারভে জাভাতে কৌশলটি হ'ল প্রাক-মনগড়া ব্যতিক্রম বস্তু নিক্ষেপ করা throw new ...। অথবা, কাস্টম ব্যতিক্রমগুলি ছুঁড়ে ফেলুন, যেখানে ফিলিইনস্ট্যাকট্রেস () ওভাররাইট করা আছে। তারপরে আপনার কোনও পারফরম্যান্স অবক্ষয় লক্ষ্য করা উচিত নয়, হিটগুলির কথা বলা উচিত নয় ।

— ইঙ্গো

+1: ঠিক আমি কী উত্তর দিতে যাচ্ছিলাম। কোডটি সহজ করার সময় এটি ব্যবহার করুন। ব্যতিক্রমগুলি আরও স্পষ্ট কোড দিতে পারে যেখানে কল-স্ট্যাকের প্রতিটি স্তরে আপনাকে রিটার্ন মানগুলি পরীক্ষা করতে বিরক্ত করতে হবে না। (অন্য সব কিছুর মতো, যদি ভুল উপায়ে ব্যবহার করা হয় তবে তা আপনার কোডটিকে একটি ভয়াবহ জগাখিচুড়ি করে তুলতে পারে))

— লিও

@ ব্রেন্ডন ধরুন কিছু ব্যতিক্রম ঘটে এবং কল স্ট্যাকের ত্রুটি-পরিচালনা কোডটি 4 স্তরের নীচে। আপনি যদি একটি ত্রুটি কোড ব্যবহার করেন তবে হ্যান্ডলারের উপরের সমস্ত 4 ফাংশনের ত্রুটি কোডের প্রকারটি তাদের ফেরতের মান হিসাবে হওয়া দরকার এবং আপনাকে if (foo() == ERROR) { return ERROR; } else { // continue }প্রতিটি স্তরে একটি শৃঙ্খলা করতে হবে । যদি আপনি একটি চেক না করা ব্যতিক্রম ছুঁড়ে ফেলে থাকেন তবে "যদি ত্রুটি ফেরত ত্রুটি হয়" তবে কোলাহলপূর্ণ ও অপ্রয়োজনীয় কোনও শব্দ নেই। এছাড়াও, যদি আপনি যুক্তি হিসাবে ফাংশনগুলি অতিক্রম করে থাকেন তবে ত্রুটি কোডটি ব্যবহার করে ফাংশনের স্বাক্ষরটি একটি বেমানান প্রকারে পরিবর্তিত হতে পারে, তবুও ত্রুটি নাও ঘটতে পারে।

— ডোভাল

Answer 2

কখন ব্যতিক্রম নিক্ষেপ করা উচিত? কোডটি আসার পরে, আমি মনে করি যে নিম্নলিখিত ব্যাখ্যাটি খুব সহায়ক:

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

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

আপনার প্রশ্নের উত্তর দেওয়ার জন্য আপনার কোডটি দেখতে হবে যেখানে ব্যবহারকারীর ইনপুটটি প্রক্রিয়াভুক্ত। এটি দেখতে এরকম কিছু দেখাচ্ছে:

public void Save(PersonData personData) { … }

পদ্ধতির নামটি কি কিছু বৈধকরণের পরামর্শ দেয়? না। এই ক্ষেত্রে একটি অবৈধ পার্সোনডাটা অবশ্যই একটি ব্যতিক্রম ছুঁড়ে ফেলে।

ধরুন শ্রেণীর আরও একটি পদ্ধতি রয়েছে যা দেখতে দেখতে এটির মতো দেখাচ্ছে:

public ValidationResult Validate(PersonData personData) { … }

পদ্ধতির নামটি কি কিছু বৈধকরণের পরামর্শ দেয়? হ্যাঁ. এই ক্ষেত্রে একটি অবৈধ পার্সোনডাটা কোনও ব্যতিক্রম ছোঁড়া উচিত নয়।

জিনিসগুলিকে একসাথে রাখার জন্য, উভয় পদ্ধতিই ক্লায়েন্ট কোডটি দেখতে দেখতে উচিত:

ValidationResult validationResult = personRegister.Validate(personData);
if (validationResult.IsValid())
{
    personRegister.Save(personData)
}
else
{
    // Throw an exception? To answer this look at the context!
    // That is: (a) Method name, (b) signature and
    // (c) where this method is (expected) to be used.
}

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

Comments

গতকালই আমি একটি struct"ভ্যালিডেশন রিসাল্ট" বলেছিলাম এবং আমার কোডটি আপনার বর্ণনার পদ্ধতি অনুসারে গঠন করেছি।

— পল

এটি আপনার প্রশ্নের উত্তর দিতে সহায়তা করে না, তবে আমি কেবল উল্লেখ করতে চাই যে আপনি স্পষ্টভাবে বা উদ্দেশ্যমূলকভাবে কমান্ড-কোয়েরি বিচ্ছেদ নীতিটি অনুসরণ করেছিলেন ( en.wikedia.org/wiki/Command-query_separation )। ;-)

— থিও লেনডরফ

ভাল যুক্তি! একটি অসুবিধা: আপনার উদাহরণস্বরূপ, বৈধতা আসলে দুটিবার সম্পাদিত হয়: একবার Validate(অবৈধ হলে মিথ্যা প্রত্যাবর্তন) এবং একবারের সময় Save( অবৈধ হলে একটি নির্দিষ্ট, ভাল-নথিভুক্ত ব্যতিক্রম ছোঁড়া)। অবশ্যই, বৈধতা ফলাফল অবজেক্টের ভিতরে ক্যাশে করা যেতে পারে, তবে এটি অতিরিক্ত জটিলতা যুক্ত করবে, যেহেতু বৈধকরণের ফলাফলটি পরিবর্তনে অবৈধ হওয়া দরকার।

— হেইনজি

@ হাইঞ্জি আমি একমত এটি রিফ্যাক্টর করা যেতে পারে যাতে Validate()এটিকে Save()পদ্ধতির অভ্যন্তরে বলা হয় ValidationResultএবং ব্যতিক্রমের জন্য একটি উপযুক্ত বার্তা তৈরি করতে এর থেকে নির্দিষ্ট বিবরণ ব্যবহার করা যেতে পারে।

— ফিল

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

— অ্যান্ডি

Answer 3

ব্যতিক্রম ব্যতিক্রমী হওয়া উচিত: এটি প্রত্যাশিত যে ব্যবহারকারী অবৈধ ডেটা ইনপুট করতে পারে, সুতরাং এটি ব্যতিক্রমী ক্ষেত্রে নয়

সেই যুক্তিতে:

• এটি প্রত্যাশিত যে কোনও ফাইলের অস্তিত্ব থাকতে পারে, সুতরাং এটি ব্যতিক্রমী ঘটনা নয়।
• এটি আশা করা যায় যে সার্ভারের সাথে সংযোগটি হারিয়ে যেতে পারে, সুতরাং এটি ব্যতিক্রমী ঘটনা নয় isn't
• এটি প্রত্যাশিত যে কনফিগারেশন ফাইলটি গার্ফড হয়ে যেতে পারে যাতে এটি ব্যতিক্রমী ঘটনা নয়
• এটি আশা করা যায় যে আপনার অনুরোধটি মাঝে মাঝে পড়ে যায়, সুতরাং এটি ব্যতিক্রমী ঘটনা নয়

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

তাই আমি মনে করি "ব্যতিক্রম ব্যতিক্রমী হওয়া উচিত" থাম্বের একটি ভয়ানক নিয়ম।

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

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

Comments

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

— উইনস্টন ইওয়ার্ট

+1 "exceptions should be exceptional" is a terrible rule of thumb.ভাল বলেছেন! এটি সেই জিনিসগুলির মধ্যে একটি যা কেবলমাত্র তাদের সম্পর্কে চিন্তা না করে পুনরাবৃত্তি করে।

— আন্দ্রেস এফ।

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

— মাইক্রা

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

— উইনস্টন ইওয়ার্ট

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

— উইনস্টন ইওয়ার্ট

Answer 4

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

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

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

সম্পাদনা (বিবেচনা করার মতো আরও কিছু):

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

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

Comments

কিন্তু কেন? প্রত্যাশিত সমস্যাগুলি মোকাবেলায় ব্যতিক্রমগুলি কেন কম দরকারী?

— উইনস্টন ইওয়ার্ট

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

— উইনস্টন ইওয়ার্ট

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

— উইনস্টন ইওয়ার্ট

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

— কন্ডিশন

ফাইল.ReadAllBytes একটি FileNotFoundExceptionভুল ইনপুট দেওয়া হলে একটি নিক্ষেপ করবে (উদাহরণস্বরূপ একটি অ-অস্তিত্বশীল ফাইলের নাম)। এই ত্রুটি হুমকির একমাত্র বৈধ উপায়, ত্রুটি কোডগুলি ফেরত না দিয়ে আপনি আর কী করতে পারেন?

— ও

Answer 5

উল্লেখ

থেকে বাস্তবমুখী প্রোগ্রামার:

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

তারা পড়ার জন্য একটি ফাইল খোলার উদাহরণ পরীক্ষা করে যায়, এবং ফাইলটির অস্তিত্ব নেই - এটি কি একটি ব্যতিক্রম বাড়াতে হবে?

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

পরে তারা কেন এই পদ্ধতিটি বেছে নিয়েছিল তা নিয়ে তারা আলোচনা করে:

[এ] এন ব্যতিক্রমগুলি তাত্ক্ষণিক, নিয়ন্ত্রণের অ-স্থানীয় স্থানান্তরকে উপস্থাপন করে - এটি এক ধরণের ক্যাসকেডিং goto। যে প্রোগ্রামগুলি তাদের সাধারণ প্রক্রিয়াজাতকরণের অংশ হিসাবে ব্যতিক্রমগুলি ব্যবহার করে তারা ক্লাসিক স্প্যাগেটি কোডের সমস্ত পাঠযোগ্যতা এবং রক্ষণাবেক্ষণের সমস্যায় ভোগেন। এই প্রোগ্রামগুলি এনক্যাপসুলেশনটি ভেঙে দেয়: রুটিনগুলি এবং তাদের কলকারীরা ব্যতিক্রম হ্যান্ডলিংয়ের মাধ্যমে আরও দৃ tight়তার সাথে মিলিত হয়।

আপনার অবস্থা সম্পর্কে

আপনার প্রশ্নটি ফুটে উঠেছে "বৈধতা ত্রুটিগুলি কি ব্যতিক্রমগুলি বাড়িয়ে তুলবে?" উত্তরটি হ'ল এটি বৈধতা কোথায় ঘটছে তার উপর নির্ভর করে।

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

Answer 6

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

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

Comments

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

— jmoreno

@ জোমরনো: অবশ্যই, আপনি কোডটি অপ্রকাশনীয় অবস্থার বিষয়ে কিছু করতে পারলে ট্রাই পার্স ব্যবহার করতে পারেন, এবং পার্সে যখন তা না পারত।

— রবার্ট হার্ভে

Answer 7

আপনার দু'টি উদ্বেগ বিবেচনা করা উচিত:

1. আপনি একটি উদ্বেগ নিয়ে আলোচনা করুন - আসুন আমরা এটিকে ডাকি Assignerযেহেতু এই উদ্বেগটি কাঠামোগত অবজেক্টগুলিকে ইনপুটগুলি অর্পণ করা - এবং আপনি এই প্রতিরোধকে বৈধ বলে সীমাবদ্ধতা প্রকাশ করেন

2. একটি সু-বাস্তবায়িত ব্যবহারকারী-ইন্টারফেসের অতিরিক্ত উদ্বেগ রয়েছে: ব্যবহারকারী ইনপুটটির বৈধতা এবং ত্রুটি সম্পর্কে গঠনমূলক প্রতিক্রিয়া (আসুন এই অংশটি কল করুন Validator)

Assignerউপাদানটির দৃষ্টিকোণ থেকে , একটি ব্যতিক্রম ছোঁড়া সম্পূর্ণ যুক্তিসঙ্গত, যেহেতু আপনি লঙ্ঘন করা হয়েছে এমন একটি প্রতিবন্ধকতা প্রকাশ করেছেন।

ব্যবহারকারীর অভিজ্ঞতার দৃষ্টিকোণ থেকে , ব্যবহারকারীর Assignerপ্রথমে সরাসরি এটির সাথে কথা বলা উচিত নয় । তারা এটা কথা বলা হবে মাধ্যমেValidator ।

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

আপনি লক্ষ্য করবেন যে এই উদ্বেগগুলি কীভাবে কার্যকর করা হয় আমি তা উল্লেখ করিনি । দেখে মনে হচ্ছে আপনি কথা বলছেন Assignerএবং আপনার সহকর্মী সম্মিলিত বিষয়ে কথা বলছেন Validator+Assigner। একবার আপনি বুঝতে পারছি সেখানে হয় দুটি পৃথক (বা খণ্ডনীয়) উদ্বেগ, অন্তত আপনি এটা বুদ্ধিমানের নিয়ে আলোচনা করতে পারেন।

---

রেননের মন্তব্যে সম্বোধন করার জন্য, আমি কেবল ধরে নিচ্ছি যে একবার আপনি আপনার দুটি পৃথক উদ্বেগ চিহ্নিত করেছেন, তবে প্রতিটি প্রসঙ্গে কেসের ক্ষেত্রে ব্যতিক্রমী বলে বিবেচনা করা উচিত তা স্পষ্ট।

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

আমি অনুমান করি যা এর প্রত্যক্ষ উত্তর দেয়

... আমার মামলাটি যদি ব্যতিক্রমী হয় তবে আমি কীভাবে জানব?

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

Comments

-১ হ্যাঁ, দুটি উদ্বেগ রয়েছে, তবে এই প্রশ্নের উত্তর দেয় না "আমার মামলাটি যদি ব্যতিক্রমী হয় তবে আমি কীভাবে জানব?"

— আরমালকে

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

— 24:44

... আসলে, সম্ভবত এটি হয় না - পরিবর্তে আমি আমার উত্তরটিতে আপনার বক্তব্য সম্বোধন করেছি।

— বেহুদা

Answer 8

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

Answer 9

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

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

সুতরাং একটি সাধারণ নিয়ম হিসাবে, যদি:

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

তারপরে আপনার কোডটিকে কখনও ব্যতিক্রম করা উচিত নয়, এমনকি পরে ধরা পড়ে। অবৈধ ডেটা ফাঁদে ফেলতে, আপনি ইউআই স্তরে বা Int32.TryParse()উপস্থাপনা স্তরের মতো কোডে ভ্যালিডেটর ব্যবহার করতে পারেন ।

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

Answer 10

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

যদি পঠন-উপাত্ত রুটিন ব্যতিক্রমগুলি ব্যবহার না করে তবে কেবল পঠন সফল হয় কি না তা জানায়, কলিং কোডটি দেখতে হবে:

temp = dataSource.readInteger();
if (temp == null) return null;
field1 = (int)temp;
temp = dataSource.readInteger();
if (temp == null) return null;
field2 = (int)temp;
temp = dataSource.readString();
if (temp == null) return null;
field3 = temp;

ইত্যাদি কাজের প্রতিটি কাজের জন্য তিন লাইনের কোড ব্যয় করা। বিপরীতে, যদি readIntegerকোনও ফাইলের শেষের মুখোমুখি হওয়ার পরে যদি ব্যতিক্রম ছুঁড়ে ফেলা হয় এবং যদি কলার কেবল ব্যাতিক্রম করতে পারে তবে কোডটি হয়ে যায়:

field1 = dataSource.readInteger();
field2 = dataSource.readInteger();
field3 = dataSource.readString();

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

do
{
  temp = dataSource.tryReadInteger();
  if (temp == null) break;
  total += (int)temp;
} while(true);

বনাম

try
{
  do
  {
    total += (int)dataSource.readInteger();
  }
  while(true);
}
catch endOfDataSourceException ex
{ // Don't do anything, since this is an expected condition (eventually)
}

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

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

Answer 11

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

আপনি যখন কিছু অ্যালগরিদম লিখছেন, কেবল ভবিষ্যতে সেই ব্যক্তির কথা চিন্তা করুন যিনি এটি পড়ছেন। আপনি যখন এমন কোনও জায়গায় এসে পৌঁছেছেন যেখানে কোনও সম্ভাব্য সমস্যা দেখা দিতে পারে, তখন নিজেকে জিজ্ঞাসা করুন যে পাঠক আপনি এখন সেই সমস্যাটি কীভাবে পরিচালনা করছেন তা দেখতে চান , বা পাঠক কেবল অ্যালগরিদমটি চালিয়ে যেতে পছন্দ করবেন?

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

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

Answer 12

আমরা কেবল প্রথমটি নয়, ইনপুটটিতে যে প্রতি ত্রুটি পেতে পারি তার প্রতিবেদন করার প্রয়োজন হতে পারে।

এই কারণেই আপনি এখানে একটি ব্যতিক্রম ছুঁড়ে ফেলতে পারবেন না। একটি ব্যতিক্রম অবিলম্বে বৈধতা প্রক্রিয়া বাধা দেয়। সুতরাং এটি সম্পন্ন করার জন্য প্রচুর কাজ হবে।

একটি খারাপ উদাহরণ:

Dogব্যতিক্রম ব্যবহার করে শ্রেণীর জন্য বৈধতা পদ্ধতি :

void validate(Set<DogValidationException> previousExceptions) {
    if (!DOG_NAME_PATTERN.matcher(this.name).matches()) {
        DogValidationException disallowedName = new DogValidationException(Problem.DISALLOWED_DOG_NAME);
        if (!previousExceptions.contains(disallowedName)){
            throw disallowedName;
        }
    }
    if (this.legs < 4) {
        DogValidationException invalidDog = new DogValidationException(Problem.LITERALLY_INVALID_DOG);
        if (!previousExceptions.contains(invalidDog)){
            throw invalidDog;
        }
    }
    // etc.
}

কীভাবে এটি কল করবেন:

Set<DogValidationException> exceptions = new HashSet<DogValidationException>();
boolean retry;
do {
    retry = false;
    try {
        dog.validate(exceptions);
    } catch (DogValidationException e) {
        exceptions.add(e);
        retry = true;
    }
} while (retry);

if(exceptions.isEmpty()) {
    dogDAO.beginTransaction();
    dogDAO.save(dog);
    dogDAO.commitAndCloseTransaction();
} else {
    // notify user to fix the problems
}

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

আরও ভাল পদ্ধতির হ'ল:

পদ্ধতি কল:

Set<Problem> validationResults = dog.validate();
if(validationResults.isEmpty()) {
    dogDAO.beginTransaction();
    dogDAO.save(dog);
    dogDAO.commitAndCloseTransaction();
} else {
    // notify user to fix the problems
}

বৈধকরণ পদ্ধতি:

Set<Problem> validate() {
    Set<Problem> result = new HashSet<Problem>();
    if(!DOG_NAME_PATTERN.matcher(this.name).matches()) {
        result.add(Problem.DISALLOWED_DOG_NAME);
    }
    if(this.legs < 4) {
        result.add(Problem.LITERALLY_INVALID_DOG);
    }
    // etc.
    return result;
}

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

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