ত্রুটি ভেরিয়েবলগুলি একটি অ্যান্টি-প্যাটার্ন বা ভাল ডিজাইন রয়েছে?

Question

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

Comments

এটি কি জন্য try/ catchবিদ্যমান। উপরন্তু, আপনি আপনার লাগাতে পারেন try/ catch(উদ্বেগের বৃহত্তর বিচ্ছেদের জন্য, যার ফলে) এটি পরিচালনা করার জন্য আরো একটি উপযুক্ত অবস্থান আরও আপ অনেক স্ট্যাক।

— jpmc26

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

— Nzall

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

— পিয়াদার

@ পাইদার আমি একটি পৃথক প্রশ্ন তৈরি করেছি যেখানে এটি আরও

— নিখরচায়

API ডিজাইনের একটি সাধারণ নীতি যা আপনাকে বেশ দূরে নিয়ে আসে তা হ'ল পিএইচপি কী করছে তা সর্বদা সন্ধান করা এবং তারপরে সঠিক বিপরীত জিনিসটি করা।

— ফিলিপ

Answer 1

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

আপনার পছন্দ থাকলে ব্যতিক্রমগুলি ব্যবহার করার বেশ কয়েকটি সুবিধা রয়েছে।

বার্তা

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

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

ব্যতিক্রম বার্তাগুলির ক্ষেত্রে, আমি যথাসম্ভব প্রসঙ্গ সরবরাহ করি, যেমন:

"Foo" নামের একটি নীতি ব্যবহারকারী "বার" এর জন্য পুনরুদ্ধার করা যায়নি, যা ব্যবহারকারীর প্রোফাইলে রেফারেন্স করা হয়েছিল।

এটি একটি রিটার্ন কোড -85 এর সাথে তুলনা করুন। আপনি কোনটি পছন্দ করবেন?

স্ট্যাক কল

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

দ্রুত পক্ষপাতমূলক পদ্ধতির ব্যর্থতা

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

মোড়ানো এবং মুদ্রণ ব্যতিক্রমগুলি

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

কোড সরলতা

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

উপসংহার

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

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

Comments

উইন্ডোজ এর সার্বজনীন এপিআইগুলিতে সি সামঞ্জস্য বজায় রাখতে সি ++ ফাংশন থেকে HRE صلاحt মানগুলি ফেরত দেয় (এবং কারণ আপনি সীমানা পেরিয়ে মার্শাল ব্যতিক্রম করার চেষ্টা করে আঘাতের বিশ্বে জড়িয়ে পড়তে শুরু করেছেন)। আপনি কোনও অ্যাপ্লিকেশন লিখলে অন্ধভাবে অপারেটিং সিস্টেমের মডেলটি অনুসরণ করবেন না।

— কোডি গ্রে

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

— jpmc26

@ ট্রেনটনমাকি আপনি যদি সি ++ কনস্ট্রাক্টরদের ত্রুটি সম্পর্কে কথা বলছেন তবে সর্বোত্তম উত্তরটি এখানে রয়েছে: parashift.com/c++-faq-lite/ctors-can-throw.html । সংক্ষেপে, একটি ব্যতিক্রম ছুঁড়ে ফেলুন তবে প্রথমে সম্ভাব্য ফুটো পরিষ্কার করতে ভুলবেন না। আমি অন্য কোনও ভাষা সম্পর্কে সচেতন নই যেখানে কেবল নির্মাতার কাছ থেকে সোজা নিক্ষেপ করা খারাপ জিনিস। আমার মনে হয় এমন একটি API এর বেশিরভাগ ব্যবহারকারীর ত্রুটি কোডগুলি চেক করার পরিবর্তে ব্যতিক্রমগুলি ধরা পছন্দ করবে।

— ওগ্রে গীতসংহিতা 33

"এই জাতীয় উন্নত পরিস্থিতিগুলি রিটার্ন মানগুলির সাথে কার্যকর করা সহজ নয়" " অবশ্যই পারবেন! আপনাকে যা করতে হবে তা হ'ল একটি ErrorStateReturnVariableসুপার-ক্লাস তৈরি করা এবং এর একটি বৈশিষ্ট্য হ'ল InnerErrorState(যা একটি উদাহরণ ErrorStateReturnVariable), যা প্রয়োগ করে সাব-ক্লাসগুলি ত্রুটিগুলির একটি শৃঙ্খলা প্রদর্শন করতে পারে ... ওহ, অপেক্ষা করুন। : পি

— ব্রায়ান এস

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

— ম্যাথিউ এম।

Answer 2

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

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

Comments

ব্যাখ্যা করার জন্য ধন্যবাদ! আপনার উত্তর + ওমর ইকবাল আমার প্রশ্নের উত্তর দিয়েছেন।

— মিকায়লা মাকি

"সতর্কতাগুলি" হ্যান্ডেল করার আরেকটি উপায় হ'ল ডিফল্টরূপে একটি ব্যতিক্রম ছুঁড়ে ফেলা এবং ব্যতিক্রমটিকে নিক্ষেপ করা থেকে বিরত রাখতে এক ধরণের alচ্ছিক পতাকা দেওয়া।

— সায়ানফিশ

@ সায়ানফিশ: হ্যাঁ, তবে বিশেষত গ্রন্থাগারগুলি তৈরি করার সময় এই জাতীয় জিনিসগুলিকে অতিরিক্তভাবে ডিজাইন না করার বিষয়ে আমাদের অবশ্যই যত্নবান হতে হবে। উন্নত প্রদান এক সহজ এবং বা একাধিক 2, 3 চেয়ে সতর্কবার্তা প্রক্রিয়া কাজ।

— ডক ব্রাউন

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

— গুডডর

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

— ডক ব্রাউন

Answer 3

ত্রুটি সংকেত দেওয়ার একাধিক উপায় রয়েছে:

• একটি ত্রুটি ভেরিয়েবল চেক করতে: সি , গো , ...
• একটি ব্যতিক্রম: জাভা , সি # , ...
• একটি "শর্ত" হ্যান্ডলার: লিস্প (কেবল?), ...
• একটি বহুকীর্ণ রিটার্ন: হাস্কেল , এমএল , মরিচা , ...

ত্রুটি ভেরিয়েবলের সমস্যা হ'ল এটি পরীক্ষা করা ভুলে যাওয়া সহজ।

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

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

পলিমর্ফিক রিটার্ন ( Either a bহাস্কেলের মধ্যে) এখন পর্যন্ত আমার প্রিয় সমাধান:

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

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

Comments

ভাল উত্তর! আমি আশা করছিলাম যে আমি ত্রুটিগুলি পরিচালনা করার উপায়গুলির একটি তালিকা পেতে পারি।

— মিকায়লা মাকি

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

— ডঙ্ক

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

— ম্যাথিউ এম।

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

— ডাঙ্ক

Answer 4

আমি মনে করি এটি ভয়ঙ্কর। আমি বর্তমানে একটি জাভা অ্যাপ রিফ্যাক্টর করছি যা ব্যতিক্রমের পরিবর্তে রিটার্ন মান ব্যবহার করে। যদিও আপনি সম্ভবত জাভা নিয়ে কাজ করছেন না, তবে আমি মনে করি এটি তবেই প্রযোজ্য।

আপনি এই জাতীয় কোড দিয়ে শেষ:

String result = x.doActionA();
if (result != null) {
  throw new Exception(result);
}
result = x.doActionB();
if (result != null) {
  throw new Exception(result);
}

অথবা এটা:

if (!x.doActionA()) {
  throw new Exception(x.getError());
}
if (!x.doActionB()) {
  throw new Exception(x.getError());
}

আমি বরং ক্রিয়াগুলি তাদের ব্যাতিক্রমগুলি ছুঁড়ে ফেলাতে চাই, তাই আপনি এরকম কিছু দিয়ে শেষ করুন:

x.doActionA();
x.doActionB();

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

বর্তমান (ভয়ঙ্কর) কোড:

private String doActionA() {
  try {
    someOperationThatCanGoWrong1();
    someOperationThatCanGoWrong2();
    someOperationThatCanGoWrong3();
    return null;
  } catch(Exception e) {
    return "Something went wrong!";
  }
}

নতুন এবং উন্নত:

private void doActionA() throws Exception {
  someOperationThatCanGoWrong1();
  someOperationThatCanGoWrong2();
  someOperationThatCanGoWrong3();
}

"কিছু ভুল হয়ে গেছে!" এর চেয়ে স্ট্র্যাকের ট্রেস সংরক্ষণ করা হয়েছে এবং বার্তাটি ব্যাতিক্রমে পাওয়া যায়।

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

Comments

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

— অবহিত

এটি সত্য, তবে বর্তমানে ঘটছে না। এবং আপনি সর্বদা doActionA এ ব্যতিক্রমটি ধরতে পারেন এবং স্থিতির বার্তার সাহায্যে এটিকে অন্য কোনও ব্যতিক্রমতে মুড়িয়ে রাখতে পারেন। তারপরে আপনার কাছে স্ট্যাক ট্রেস এবং দরকারী বার্তা থাকবে। throw new Exception("Something went wrong with " + instanceVar, ex);

— মির্জিংক

আমি সম্মত, এটি আপনার পরিস্থিতিতে নাও হতে পারে। তবে আপনি "সর্বদা" তথ্য doActionA () এ রাখতে পারবেন না। কেন? DoActionA () এর কলকারী কেবলমাত্র সেই তথ্য থাকতে পারে যা আপনার অন্তর্ভুক্ত করতে হবে।

— অবহিত

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

— mrjink

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

— ডাঙ্ক

Answer 5

"ঘটে যাওয়া বেশ কয়েকটি সম্ভাব্য ত্রুটিগুলি পরিচালনা করার জন্য, এটি কার্যকর করা বন্ধ করে দেওয়া উচিত নয়,"

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

আমি যে দুটি নিদর্শন ব্যবহার করেছি তা হ'ল:

• একটি ত্রুটি / সতর্কতা সংগ্রহ, হয় পাস হয়েছে বা সদস্য ভেরিয়েবল হিসাবে রাখা হয়েছে। যা আপনি স্টাফ সংযোজন এবং কেবল প্রক্রিয়া চালিয়ে যান। আমি ব্যক্তিগতভাবে এই পদ্ধতির পছন্দ করি না কারণ আমার কাছে মনে হয় এটি কলারকে বিতরণ করে।

• একটি ত্রুটি / সতর্কতা হ্যান্ডলার অবজেক্টে পাস করুন (বা এটি সদস্য ভেরিয়েবল হিসাবে সেট করুন)। এবং প্রতিটি ত্রুটি হ্যান্ডলারের একটি সদস্য ফাংশন কল করে। এইভাবে ফোনকারী সিদ্ধান্ত নিতে পারে যে এইরকম নন-টার্মিনেট ত্রুটিগুলি দিয়ে কী করা উচিত।

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

একটি ত্রুটি হ্যান্ডলার ব্যবহার করে টিপিকাল কোডটি এর মতো দেখতে পারে

class MyFunClass {
  public interface ErrorHandler {
     void onError(Exception e);
     void onWarning(Exception e);
  }

  ErrorHandler eh;

  public void canFail(int i) {
     if(i==0) {
        if(eh!=null) eh.onWarning(new Exception("canFail shouldn't be called with i=0"));
     }
     if(i==1) {
        if(eh!=null) eh.onError(new Exception("canFail called with i=1 is fatal");
        throw new RuntimeException("canFail called with i=2");
     }
     if(i==2) {
        if(eh!=null) eh.onError(new Exception("canFail called with i=2 is an error, but not fatal"));
     }
  }
}

Comments

ব্যবহারকারীরা একটি ত্রুটি না করে একটি সতর্কতা চায় তা লক্ষ্য করার জন্য +1। পাইথনের warningsপ্যাকেজটি উল্লেখ করার মতো হতে পারে , যা এই সমস্যার জন্য আরও একটি প্যাটার্ন দেয়।

— জেমস_পিক

মহান উত্তরের জন্য ধন্যবাদ! এটি আমি যা দেখতে চেয়েছিলাম তার চেয়ে বেশি, ত্রুটিগুলি পরিচালনা করার জন্য অতিরিক্ত নিদর্শনগুলি যেখানে traditionalতিহ্যগত চেষ্টা / ধরা যথেষ্ট না পারে।

— মিকায়লা মাকি

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

— সুপারক্যাট

Answer 6

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

Answer 7

প্রশ্নের উত্তর ইতিমধ্যে দেওয়া হয়েছে, তবে আমি নিজেকে সাহায্য করতে পারি না।

আপনি ব্যতিক্রমটি সমস্ত ব্যবহারের ক্ষেত্রে সমাধান দেওয়ার জন্য সত্যই আশা করতে পারবেন না। কারও হাতুড়ি?

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

আপনি তর্ক করতে পারেন যে এই সমস্ত বৈধতা বৈধতা মডিউলটির শেষে একটি ব্যতিক্রম হিসাবে নিক্ষেপ করা যেতে পারে তবে এগুলি নাম ব্যতীত অন্য কোনও ক্ষেত্রে ত্রুটি কোড হবে।

সুতরাং এখানে পাঠটি হ'ল: ব্যতিক্রম কোডগুলির মতো ব্যতিক্রমগুলিরও তাদের স্থান রয়েছে। বুদ্ধি করে বেছে নিন।

Comments

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

— jhr

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

— আলেকজান্দ্রে স্যান্টোস

এবং আপনি একটি বিস্ময়কর-শক্তিশালী-কিন্তু-সত্যিই-দুর্বল পাসওয়ার্ড দিয়ে কি করবেন? আপনি প্রবাহকে বাধাগ্রহণ করতে এবং ব্যবহারকারীকে একটি বার্তা দেখিয়েছেন যা প্রেরণ করা পাসওয়ার্ড খুব শক্তিশালী নয়। সুতরাং একটি MiddlyStrongValidatorবা কিছু আছে। এবং যদি এটি আপনার প্রবাহকে সত্যই বাধা দেয় না, Validatorঅবশ্যই প্রবাহটি আগেই বলা হত, এটি প্রবাহটি এগিয়ে নেওয়ার আগে যখন ব্যবহারকারী এখনও তাদের পাসওয়ার্ড (বা অনুরূপ) প্রবেশ করছিল। তবে তারপরে বৈধতাটি প্রথম স্থানে প্রশ্ন করা পদ্ধতির অংশ ছিল না। :) সম্ভবত সর্বোপরি স্বাদের বিষয় ...

— jhr

@ jhr আমি যে বৈধতা লিখেছি সেগুলিতে আমি সাধারণত একটি AggregateException(বা অনুরূপ ValidationException) তৈরি করব এবং প্রতিটি বৈধতা ইস্যুর জন্য অভ্যন্তরীণ ব্যতিক্রমগুলিতে সুনির্দিষ্ট ব্যতিক্রমগুলি রেখে দেব। উদাহরণস্বরূপ, এটি হতে পারে BadPasswordException: "ব্যবহারকারীর পাসওয়ার্ডটি ন্যূনতম 6 এর দৈর্ঘ্যের চেয়ে কম" বা MandatoryFieldMissingException: "ব্যবহারকারীর জন্য প্রথম নামটি অবশ্যই সরবরাহ করতে হবে" ইত্যাদি error এটি ত্রুটি কোডের সমতুল্য নয়। এই সমস্ত বার্তাগুলি ব্যবহারকারীর কাছে এমনভাবে প্রদর্শন করা যেতে পারে যা তারা বুঝতে পারে, এবং যদি এর NullReferenceExceptionপরিবর্তে কোনও ছুঁড়ে দেওয়া হয়, তবে আমরা একটি বাগ পেয়েছি।

— ওমর ইকবাল

Answer 8

ব্যবহারের ক্ষেত্রে রয়েছে ত্রুটি কোডগুলি ব্যতিক্রমগুলির চেয়ে পছন্দসই।

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

অন্যান্য উত্তরগুলিতে সাধারণভাবে ত্রুটি কোডগুলিতে ব্যতিক্রমগুলি কেন পছন্দ করা উচিত তা অন্তর্ভুক্ত করা হয়েছে।

Comments

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

— jhr

না, আমি কলারের কাছে এটির প্রতিবেদন করছি। একজন ব্যতিক্রম যেমন ঠিক তেমনি ব্যবহারকারীর ত্রুটি সম্পর্কে জানতে বা না জানা দরকার তা সিদ্ধান্ত নেওয়ার পক্ষে এই কলারের দায়িত্ব।

— জ্যাক এইডলি

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

— সুপারক্যাট

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

— সুপারক্যাট

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

— jhr

Answer 9

ব্যতিক্রমগুলি ভাল উপযুক্ত না হলে ব্যতিক্রমগুলি ব্যবহার না করার ক্ষেত্রে অবশ্যই কোনও ভুল নেই।

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

Comments

প্রশ্ন আকর্ষণীয়। আমি আমার প্রশ্ন এবং আমার বোঝার সমস্যাটি অস্পষ্ট পরিভাষা বলে মনে করি। আপনি যা বর্ণনা করেছেন তা ব্যতিক্রমী নয়, তবে এটি একটি ত্রুটি। আমাদের কী বলা উচিত?

— মিকায়লা মাকি

Answer 10

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

ইন পার্ল 6 এটি সম্পন্ন মাধ্যমে করা হয় fail, যা যদি withing no fatal;সুযোগ একটি বিশেষ unthrown ব্যতিক্রম ফেরৎ Failureঅবজেক্ট।

ইন পার্ল 5 আপনি ব্যবহার করতে পারেন কনটেক্সচুয়াল :: রিটার্ন আপনার সাথে এটা করতে পারেন return FAIL।

Answer 11

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

তবে তারপরে আপনি যদি কিছু পরিবর্তন করেন তবে আপনাকে সেই মানটি যেভাবেই করতে হবে omp যদিও থেমে থেমে থেমে থেমে থেমে থেমে থেমে থেমে থেমে থেমে থেমে থেমে থেমে থেমে থেমে থাকতে পারি না।

সম্পাদনা: আমি বুঝতে পারি না এটি একটি নির্দিষ্ট ক্ষেত্রে পরিবর্তে সফ্টওয়্যার দৃষ্টান্তের প্রশ্ন।

আমার আমার নির্দিষ্ট ক্ষেত্রে আমার পয়েন্টগুলি আরও স্পষ্ট করে বলি যাতে আমার উত্তরটি বোঝায়

1. আমার কাছে সত্তা সামগ্রীর সংগ্রহ রয়েছে have
2. আমার কাছে প্রক্রিয়াগত স্টাইলের ওয়েব পরিষেবা রয়েছে যা এই সত্তাগুলির সাথে কাজ করে

দুটি ধরণের ত্রুটি রয়েছে:

1. পরিষেবা স্তরটিতে প্রক্রিয়াজাতকরণের সময় ত্রুটিগুলি
2. সত্তা অবজেক্টগুলিতে অসঙ্গতি রয়েছে বলে ত্রুটি

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

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

• একটি বৈধতা ভেরিয়েবল ব্যবহার করে
• সেটার থেকে কোনও ক্ষেত্রটি ভুলভাবে সেট করা থাকলে অবিলম্বে একটি ব্যতিক্রম নিক্ষেপ করুন

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

এক্ষেত্রে সর্বোত্তম কাজটি হ'ল বৈধতা ত্রুটির ক্যাশে কোনও বৈধতা ব্যবহার না করেই একক বৈধকরণ পদ্ধতি ব্যবহার করা। এটি সেটারকে ঠিক সেটার হিসাবে রাখতে সহায়তা করে।

Comments

আমি দেখছি আপনি কি সম্পর্কে কথা বলছেন। আকর্ষণীয় পদ্ধতির। আমি আনন্দিত এটি উত্তর সেট অংশ।

— মিকায়লা মাকি