কীভাবে ব্যতিক্রমগুলি ডিজাইন করবেন

11

আমি খুব সাধারণ একটি প্রশ্ন নিয়ে সংগ্রাম করছি:

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

আমি এই কৌশল অনুসরণ করার কথা ভাবছি:

1) কি ভুল হচ্ছে?

কিছু জিজ্ঞাসা করা হয়, যা অনুমোদিত নয়।
কিছু জিজ্ঞাসা করা হয়েছে, এটি অনুমোদিত, কিন্তু ভুল পরামিতিগুলির কারণে এটি কাজ করে না।
অভ্যন্তরীণ ত্রুটির কারণে কিছু জিজ্ঞাসা করা হয়, এটি অনুমোদিত তবে এটি কার্যকর হয় না।

2) কে অনুরোধ চালু করছে?

ক্লায়েন্ট অ্যাপ্লিকেশন
অন্য একটি সার্ভার অ্যাপ্লিকেশন

3) বার্তা হস্তান্তর: যেহেতু আমরা একটি সার্ভার অ্যাপ্লিকেশন নিয়ে কাজ করছি, এটি বার্তা প্রাপ্তি এবং প্রেরণ সম্পর্কিত। তাহলে কী যদি কোনও বার্তা প্রেরণ ভুল হয়ে যায়?

এই হিসাবে, আমরা নিম্নলিখিত ব্যতিক্রম প্রকারগুলি পেতে পারি:

ServerNotAllowedException
ClientNotAllowedException
ServerParameterException
ClientParameterException
অভ্যন্তরীণ ধারণা (যদি সার্ভারটি জানেন না যে অনুরোধটি কোথা থেকে আসছে)
- ServerInternalException
- ClientInternalException
MessageHandlingException

ব্যতিক্রম শ্রেণিবিন্যাস সংজ্ঞায়িত করার জন্য এটি একটি খুব সাধারণ পদ্ধতি, তবে আমি আশঙ্কা করছি যে আমার কিছু স্পষ্ট মামলা নাও থাকতে পারে। আপনি যে ধারনাগুলি আমি coveringেকে রাখছি না, সেগুলি সম্পর্কে কি আপনি এই পদ্ধতির কোনও ত্রুটিগুলি সম্পর্কে অবগত আছেন বা এই ধরণের প্রশ্নের জন্য আরও সাধারণ পন্থা রয়েছে (পরবর্তী ক্ষেত্রে, আমি এটি কোথায় খুঁজে পাব)?

আগাম ধন্যবাদ

— ডমিনিক
সূত্র

5

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

— রালফ ক্লেবারহফ

2

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

— বেহুদা

1

প্রাসঙ্গিকতা, আমি অনুমান চাই: softwareengineering.stackexchange.com/questions/278949/...

— মার্টিন Ba থেকে

1

আমি এতগুলি বিভিন্ন ব্যতিক্রম প্রকারের ব্যবহারের ইচ্ছাটি সত্যই বুঝতে পারি নি। সাধারণত catchআমি ব্যবহার করি বেশিরভাগ ব্লকের ক্ষেত্রে, এতে কোন ত্রুটি বার্তা রয়েছে তার চেয়ে আমার ব্যাতিক্রমের বেশি কিছু নেই। কোনও ফাইল পড়ার প্রক্রিয়া চলাকালীন মেমরি বরাদ্দ করতে ব্যর্থ হওয়ায় ব্যর্থতার সাথে জড়িত ব্যতিক্রমের জন্য আমার সত্যিই আলাদা কিছু করার দরকার নেই, তাই আমি std::exceptionএতে থাকা ত্রুটি বার্তাটি কেবল ধরা এবং এটির প্রতিবেদন করি, সম্ভবত সাজসজ্জা এটি "Failed to open file: %s", ex.what()মুদ্রণের আগে এটি একটি স্ট্যাক বাফার সহ ।

3

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

5

সাধারণ মন্তব্য

(কিছুটা মতামত ভিত্তিক)

আমি সাধারণত বিস্তারিত ব্যতিক্রম শ্রেণিবিন্যাসের জন্য যাব না।

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

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

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

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

লগিংয়ের (এবং ব্যবহারকারীর ত্রুটির বার্তাগুলির জন্য) একটি গুরুত্বপূর্ণ দিকটি হ'ল ব্যতিক্রমটিকে কিছু স্তরে ধরে, প্রাসঙ্গিক তথ্য যুক্ত করে, যেমন পদ্ধতির পরামিতিগুলি যুক্ত করে পুনরায় নিক্ষেপ করে প্রসঙ্গের তথ্যের সাথে সংশোধন করার ক্ষমতা।

আপনার শ্রেণিবিন্যাস

কে অনুরোধ চালু করছে? আমি মনে করি না যে আপনাকে অনুরোধটি চালু করছিল এমন তথ্য প্রয়োজন হবে need কিছু কল স্ট্যাকের ভিতরে আপনি কীভাবে জানেন তা আমি কল্পনাও করতে পারি না।

বার্তা হ্যান্ডলিং : এটি কোনও ভিন্ন দিক নয়, তবে "কী ভুল হচ্ছে?" এর জন্য কেবল অতিরিক্ত মামলা।

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

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

— রালফ ক্লেবারহফ
সূত্র

আমার অভিজ্ঞতায়, ব্যবহারকারী বান্ধব পাঠ্যের সাথে একত্রিত একটি ত্রুটি কোড খুব ভাল কাজ করে। প্রশাসকরা অতিরিক্ত তথ্য খুঁজতে ত্রুটি কোডটি ব্যবহার করতে পারেন।

— সুজোরড

1

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

— গ্রেগলে 138

2

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

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

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

— মার্ক বেনিংফিল্ড
সূত্র

2

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

— বার্ট ভ্যান ইনজেন শেেনা

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

— মার্ক বেনিংফিল্ড

0

ভাল আমি আপনাকে প্রথমে সুপারিশ করব এবং সর্বাগ্রে Exceptionযাচাই করা সমস্ত ব্যতিক্রম যা আপনার অ্যাপ্লিকেশন দ্বারা ছুঁড়ে দেওয়া যেতে পারে তার জন্য একটি বেস ক্লাস তৈরি করুন। যদি আপনার অ্যাপ্লিকেশন কল করা হয়েছিল DuckType, তবে একটি DuckTypeExceptionবেস ক্লাস করুন।

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

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

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

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

আপনি যদি পছন্দ করেন তবে সাংগঠনিক উদ্দেশ্যে যেমন আপনার DatabaseExceptionডাটাবেস-সম্পর্কিত যে কোনও ব্যতিক্রমগুলি আপনার ব্যতিক্রমগুলিকে উপশ্রেণীতে শ্রেণীবদ্ধ করতে পারেন তবে আমি এখনও এইরকম সাব-ব্যতিক্রমগুলি আপনার বেস ব্যতিক্রম থেকে DuckTypeExceptionপ্রাপ্ত এবং বিমূর্ত হতে উত্সাহিত করব এবং তাই স্পষ্টত বর্ণনামূলক নাম সহ প্রাপ্ত।

একটি সাধারণ নিয়ম হিসাবে, আপনি ব্যতিক্রমগুলি পরিচালনা করার জন্য কলারদের কলস্ট্যাকটি সরিয়ে দেওয়ার সাথে সাথে আপনার চেষ্টা ক্যাচগুলি ক্রমবর্ধমান জেনারেল হওয়া উচিত এবং আবারও, আপনার প্রধান নিয়ামক হিসাবে, আপনি কোনও চেনা ব্যতিক্রমগুলি প্রাপ্ত করে তার DatabaseConnectionExceptionপরিবর্তে এমন একটি সাধারণ পরিচালনা করবেন না DuckTypeException।

— নিল
সূত্র

2

নোট করুন যে প্রশ্নটি "সি ++" ট্যাগ হয়েছে।

— মার্টিন বা

0

এটি সহজ করার চেষ্টা করুন।

প্রথম কৌশল যা আপনাকে অন্য কৌশলতে ভাবতে সহায়তা করবে এটি হ'ল: অনেক ব্যতিক্রম ধরা জাভা থেকে চেক করা ব্যতিক্রমগুলির সাথে খুব মিল (দুঃখিত, আমি সি ++ বিকাশকারী নই)। এটি অনেক কারণেই ভাল নয় তাই আমি সর্বদা সেগুলি ব্যবহার না করার চেষ্টা করি এবং আপনার শ্রেণিবিন্যাস ব্যতিক্রম কৌশল আমাকে সেটির অনেক বেশি মনে রাখে।

সুতরাং, আমি আপনাকে অন্য একটি এবং নমনীয় কৌশল প্রস্তাব দিচ্ছি: চেক করা ব্যতিক্রম এবং কোড ত্রুটি ব্যবহার করুন।

উদাহরণস্বরূপ, এই জাভা কোডটি দেখুন:

public class SystemErrorCode implements ErrorCode {

    INVALID_NAME(101),
    ORDER_NOT_FOUND(102),
    PARAMETER_NOT_FOUND(103),
    VALUE_TOO_SHORT(104);

    private final int number;

    private ErrorCode(int number) {
        this.number = number;
    }

    @Override
    public int getNumber() {
        return number;
    }
}

এবং আপনার অনন্য ব্যতিক্রম:

public class SystemException extends RuntimeException {

    private ErrorCode errorCode;

    public SystemException(ErrorCode errorCode) {
        this.errorCode = errorCode;
    }

}

এই কৌশলটি আমি এই লিঙ্কটিতে পেয়েছি এবং আপনি এখানে জাভা বাস্তবায়ন পেতে পারেন , যেখানে আপনি এটি সম্পর্কে আরও বিশদ দেখতে পারেন, কারণ উপরের কোডটি সরলীকৃত।

আপনার যেমন "ক্লায়েন্ট" এবং "অন্য সার্ভার" অ্যাপ্লিকেশনগুলির মধ্যে পৃথক ব্যতিক্রমগুলি আলাদা করতে হবে, আপনার ইন্টারফেস ত্রুটি কোডটি প্রয়োগ করে একাধিক ত্রুটি কোড শ্রেণি থাকতে পারে।

— Dherik
সূত্র

2

নোট করুন যে প্রশ্নটি "সি ++" ট্যাগ হয়েছে।

— সুজোরড

আমি ধারণাটি মানিয়ে নিতে সম্পাদনা করেছি।

— ধেরিক

0

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

ব্যতিক্রমগুলি ত্রুটি নয়। যখন পরিস্থিতি প্রোগ্রামের কোডের একটি শাখা সম্পূর্ণ করতে বাধা দেয় এবং এটি অনুসরণ করার জন্য অন্য একটি শাখা নির্দেশ করে They

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

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

— shawnhcorey
সূত্র