সর্বশেষে চেষ্টা করুন (ধরা ছাড়াই) বনাম এনাম-রাষ্ট্রের বৈধতা

Question

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

আমার সর্বোত্তম অনুশীলনের বিষয়ে দ্বিধাদ্বন্দ্ব হ'ল যে কোনও একটি এনাম ফেরত দেওয়ার জন্য চেষ্টা / ক্যাপচার / অবশেষে ব্যবহার করা উচিত (বা কোনও মান এমন, যা ত্রুটির জন্য 0, ঠিকানার জন্য 1, সতর্কতার জন্য 2, কেসের উপর নির্ভর করে) ব্যবহার করা উচিত একটি উত্তর সর্বদা যথাযথ থাকে, বা কলিং অংশটি এটি মোকাবেলা করতে পারে এমন কোনওটি ব্যতিক্রম হওয়া উচিত?

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

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

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

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

আবার, HTTP get / post উদাহরণ সহ প্রশ্নটি হ'ল, আপনার কি নতুন কোনও অবজেক্ট সরবরাহ করা উচিত যা মূল আহ্বানকারীটির কী ঘটেছে তা বর্ণনা করে? এই সহায়িকা যদি আপনি যে লাইব্রেরিতে ব্যবহার করছেন আপনি এটি অপারেশনের জন্য একটি স্ট্যাটাস কোড সরবরাহ করবেন কিনা তা প্রত্যাশা করবেন, বা আপনি এটি চেষ্টা-বাধা ব্লকে অন্তর্ভুক্ত করবেন? আপনি যদি এটি ডিজাইনিং করে থাকেন, আপনি কি কোনও স্থিতি কোড সরবরাহ করবেন বা একটি ব্যতিক্রম ছুঁড়বেন এবং তার পরিবর্তে উচ্চ স্তরের এটি কোনও স্থিতি কোড / বার্তায় অনুবাদ করতে দেবেন?

সংক্ষিপ্তসার: যদি কোনও টুকরো কোড ব্যতিক্রমের পরিবর্তে কোনও স্থিতি কোড দেয় যা ফল দেয় তবে তার সাথে আপনি কীভাবে চয়ন করেন?

Comments

এটি ত্রুটিটি মোকাবেলা করছে না যা ব্যবহার করা হচ্ছে ত্রুটি হ্যান্ডলিংয়ের ফর্ম পরিবর্তন করে। 404 ক্ষেত্রে আপনি এটি পাস হতে দিতেন কারণ আপনি এটি পরিচালনা করতে অক্ষম।

— স্টোনমেটাল

"এমন একটি অন্তর্নিহিত যা মানকে 0, ত্রুটির জন্য 1, ঠিকানার জন্য 2, সতর্কবার্তা ইত্যাদির জন্য 2" দয়া করে বলুন এটি একটি অফ-দ্য কাফের উদাহরণ ছিল! 0

— টির

Answer 1

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

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

প্রোগ্রাম লজিক প্রয়োগ করতে ব্যতিক্রম কখনও ব্যবহার করা উচিত নয়। অন্য কথায়, কিছু করার জন্য ব্যতিক্রম ছোঁড়াবেন না; এটি করা যায়নি বলে উল্লেখ করে একটি ব্যতিক্রম নিক্ষেপ করুন।

Comments

উত্তরের জন্য ধন্যবাদ, এটি সর্বাধিক তথ্যবহুল তবে আমার ফোকাস ব্যতিক্রম হ্যান্ডলিংয়ে, এবং ব্যতিক্রম ছোঁড়া নয়। আপনি এটি পাওয়ার সাথে সাথে 404 টি ব্যতিক্রমটি ধরতে হবে বা আপনার এটি স্ট্যাকের উপরে উঠিয়ে দেওয়া উচিত?

— মিহালিস বাগোস

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

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

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

— জর্জিও

Answer 2

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

উদাহরণস্বরূপ, System.IO.File.OpenRead () যদি ফাইল সরবরাহ না করে তবে একটি ফাইলনটফাউন্ডএক্সেপশন নিক্ষেপ করবে, তবে এটি একটি .Exists () পদ্ধতিও সরবরাহ করে যা একটি বুলিয়ান মান প্রদান করে যা ফাইলটি উপস্থিত রয়েছে যা আপনার আগে কল করা উচিত কিনা তা নির্দেশ করে returns কোনও অপ্রত্যাশিত ব্যতিক্রম এড়াতে ওপেনআড () কে কল করা হচ্ছে।

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

Comments

অনেক লোক, বিশেষত পাইথন প্রোগ্রামাররা ইএএফপি পছন্দ করে অর্থাৎ "অনুমতি পাওয়ার চেয়ে ক্ষমা চাওয়া আরও সহজ"

— মার্ক বুথ

.Exists () হিসাবে ব্যতিক্রম এড়ানোর বিষয়ে মন্তব্য করার জন্য +1।

— কোডিংআউটলৌড

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

— গ্যাভিন হাডেন

Answer 3

একটি এনাম ফেরত দেওয়ার জন্য / চেষ্টা / অবশেষে ব্যবহার করুন (বা কোনও মান যা একটি মানের প্রতিনিধিত্ব করে, ত্রুটির জন্য 0, ঠিকানার জন্য 1, সতর্কতার জন্য 2, কেসের উপর নির্ভর করে) যাতে উত্তরটি সর্বদা যথাযথ থাকে,

এটি একটি ভয়ানক নকশা। একটি সংখ্যার কোড অনুবাদ করে একটি ব্যতিক্রম "মাস্ক" করবেন না। এটি একটি যথাযথ, দ্ব্যর্থহীন ব্যতিক্রম হিসাবে ছেড়ে দিন।

বা কেউ কি ব্যতিক্রমটি দিয়ে যাওয়ার অনুমতি দেয় যাতে কলিং অংশটি এটি মোকাবেলা করে?

ব্যতিক্রমগুলি এটাই।

এটি যতটা সম্ভব উত্থাপিত যেখানে কাছাকাছি মোকাবেলা

মোটেও সর্বজনীন সত্য নয়। এটি একটি ভাল ধারণা কিছু সময়। অন্যান্য সময় এটি হিসাবে সহায়ক হয় না।

Comments

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

— মিহালিস বাগোস

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

— এস্লট

আমি বলছি না যে আপনার মতামত গণনা করা হচ্ছে তবে আমি বলছি আপনার মতামত বিকাশিত নয়। এই মন্তব্যটি সহ, আমি এটি যুক্তিটি গ্রহণ করি যে যেখানে আমরা ব্যতিক্রমগুলি ব্যবহার করতে পারি, আমাদের উচিত, কেবলমাত্র আমরা পারি তাই? কোড প্রবাহের

— কেসগুলির

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

— এস .লট

Answer 4

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

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

কখন কীভাবে কীভাবে আপত্তি হস্তান্তর করা যায় সেগুলি ছাড়া আর কীভাবে তাদের কী করতে হবে তা না জানার আগে পর্যন্ত কীভাবে সেট আপ করবেন তার কোনও সত্য ও নিয়ম নেই।

Answer 5

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

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

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

সুতরাং ওপিকে আমার প্রশ্ন হল পৃথিবীতে কেন আপনি ত্রুটি কোডগুলি ফেরত দেওয়ার ক্ষেত্রে ব্যতিক্রমগুলি ব্যবহার করতে চান না ?

Answer 6

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

এটি কোডের একটি ভাল নিয়ম মনে করে:

কোডের লাইনগুলি সোনার বুলেটের মতো। কাজটি সম্পন্ন করতে আপনি যতটা সম্ভব ব্যবহার করতে চান।

Answer 7

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

আমি আরও সুবিধা নিয়েছি যে একটি ব্যতিক্রম ছোঁড়া কার্যকর করা বন্ধ করে দেয় কারণ ডেটা অবৈধ হলে আমি মৃত্যুদন্ড কার্যকর করতে চাই না to

উদাহরণ স্বরূপ

procedure Validate(var R:TValidationRecord);
begin
  if Field1 is not valid then
  begin
    R.Field1ErrorCode=SomeErrorCode;
    ErrorFlag := True; 
  end; 
  if Field2 is not valid then
  begin
    R.Field2ErrorCode=SomeErrorCode;
    ErrorFlag := True; 
  end;
  if Field3 is not valid then
  begin
    R.Field3ErrorCode=SomeErrorCode;
    ErrorFlag := True; 
  end;

  if ErrorFlag then
    ThrowException
end;

যদি কেবল বুলিয়ানের উপর নির্ভর করে তবে আমার ফাংশনটি ব্যবহার করে বিকাশকারীকে এটি অ্যাকাউন্টের লেখায় নেওয়া উচিত:

if not Validate() then
  DoNotContinue();

তবে তিনি ভুলে গিয়ে কেবল কল করতে পারেন Validate()(আমি জানি যে তাঁর উচিত নয়, তবে তিনি সম্ভবত পারেন)।

সুতরাং, উপরের কোডটিতে আমি দুটি সুবিধা পেয়েছি:

1. বৈধতা কার্যে কেবল একটি ব্যতিক্রম।
2. ব্যতিক্রম, এমনকি অনাবৃত, কার্যকর করা বন্ধ করে দেয় এবং পরীক্ষার সময় উপস্থিত হয়

Answer 8

এখানে একটি উত্তর নেই - এই জাতীয় ধরণের মত এক ধরণের HttpException নয়।

এটি প্রচুর পরিমাণে বোঝায় যে অন্তর্নিহিত এইচটিটিপি লাইব্রেরিগুলি যখন একটি 4xx বা 5XX প্রতিক্রিয়া পেয়ে থাকে তখন ব্যতিক্রম করে; গতবার আমি এইচটিটিপি স্পেসিফিকেশনগুলির দিকে চেয়েছিলাম সেগুলি ছিল ত্রুটি।

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