ভেক্সিং ব্যতিক্রম ছোঁড়া এড়াতে কীভাবে?

Question

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

বিশেষ করে:

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

Comments

আপনার সংরক্ষণের উদাহরণ যা ব্যর্থ হতে পারে সত্যই ভয়াবহ ভিক্সিং ব্যতিক্রম নয়। এটি বেশ সাধারণ এবং সম্ভবত এটির ব্যতিক্রম হওয়া উচিত ।

— এস। লট

@ এস.লোট: এর অর্থ কি সাধারণ? পরিস্থিতি নিজেই, না এই পরিস্থিতিতে ব্যতিক্রম ছুঁড়ে? যাইহোক, আমি আপনার সাথে একমত যে এটি প্রকৃতপক্ষে যদি উদ্বেগজনক পরিস্থিতি হয় তবে তা স্পষ্ট নয়। আমি প্রশ্ন আপডেট করব।

— মাইক 16

"পরিস্থিতি নিজেই, বা এই পরিস্থিতিতে একটি ব্যতিক্রম নিক্ষেপ" উভয়ই।

— এস। লট

Answer 1

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

ভাল প্রশ্ন.

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

আমার মনে দ্বিতীয় প্রশ্নটি আসে: আপনি যে তথ্য ব্যবহারকারীর কাছে ফিরে যেতে চান তা কি কার্যকর ? অর্থাৎ, তারা কি সেই তথ্যের ভিত্তিতে কিছু সিদ্ধান্ত নিতে চলেছে?

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

কলকারী যত্ন করে কেন সংরক্ষণ ব্যর্থ হয়? হাল ছেড়ে দেওয়া বা আবার চেষ্টা করা বাদে তারা কি এ বিষয়ে কিছু করতে যাচ্ছে?

আসুন তর্কের খাতিরে ধরে নেওয়া যাক যে অপারেশন ব্যর্থ হয়েছে তার উপর নির্ভর করে কলার সত্যই বিভিন্ন পদক্ষেপ গ্রহণ করছে।

তৃতীয় প্রশ্নটি মাথায় আসে: ব্যর্থতা মোডটি কি ব্যতিক্রম ? আমি তোমাদের বিভ্রান্তিকর হতে পারে মনে সম্ভব সঙ্গে আহামরি কোনো ঘটনা । আমি দু'জন ব্যবহারকারী একই সময়ে একই রেকর্ডটি ব্যতিক্রমী-তবে-সম্ভাব্য পরিস্থিতি হিসাবে পরিবর্তিত করার চেষ্টা করছি, সাধারণ পরিস্থিতি নয় not

আসুন তর্কের খাতিরে ধরে নেওয়া যাক এটি অবাস্তব নয়।

চতুর্থ প্রশ্নটি যা মনে আসে তা হ'ল: সময়ের আগে খারাপ পরিস্থিতি নির্ভরযোগ্যভাবে সনাক্ত করার উপায় আছে কি?

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

পঞ্চম প্রশ্নটি যা মনে আসে তা হ'ল: এআইপি ডিজাইনের এমন কোনও উপায় আছে যাতে খারাপ পরিস্থিতি রোধ করা যায়?

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

Comments

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

— মাইক 17

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

— এরিক লিপার্ট

আমি এখনই প্রশ্নের উত্তর দেওয়া বিবেচনা করি, তবে আমি কেবল কৌতূহলী;) যদি পদ্ধতিটি 2 বা ততোধিক কারণে ব্যর্থ হতে পারে তবে ব্যর্থতাগুলি কার্যক্ষম হয়, ব্যর্থতাগুলি উদ্বেগহীন এবং ব্যর্থতা সময়ের আগে সনাক্ত করা যায় না বা প্রতিরোধ করা যায় না, আপনি কি করতে চান?

— মাইক 19

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

— ম্যাথু

Answer 2

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

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

Answer 3

save()পদ্ধতি একটি ব্যতিক্রম নিক্ষেপ উচিত নয়।

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

রিটার্ন মানগুলি ব্যতিক্রমগুলি পরিচালনা করার ভাল উপায় নয়।