পরিষেবা স্তরটি কি সমস্ত দাও ব্যতিক্রম ধরা ও পরিষেবা ব্যতিক্রম হিসাবে মোড়ানো উচিত?

Question

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

try {
   daoInstance.someDaoMethod();
} catch(DataAccessException dae) {
   throw new ServiceException("message", dae);
}

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

Answer 1

আমি মনে করি একটি গুরুত্বপূর্ণ বিষয় হ'ল আপনার পরিষেবা ক্লায়েন্টরা।

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

তবে, পাবলিক ফেসিং কোডের জন্য; তৃতীয় পক্ষ বা গ্রাহক দ্বারা গ্রাস করা পরিষেবা, আমি মনে করি যে কোনও মূল লক্ষ্য সুরক্ষা উদ্বেগের জন্য, দ্বিতীয়ত আলগা সংযুক্তির জন্য, এবং পরিষ্কার বিমূর্ততার জন্য কোনও পরিষেবা অলঙ্কৃত ব্যতিক্রমগুলি আবদ্ধ করা পরিষ্কার think

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

একটি বহিরাগত পরিষেবা ক্লায়েন্ট আপনার বাস্তবায়নের বিশদটি নিয়ে উদ্বিগ্ন নয় এবং এটি ত্রুটিযুক্ত বা পরিবেশগত সমস্যা হওয়ায় কোনওভাবেই চেক করা ব্যতিক্রমগুলি পরিচালনা করতে পারে না। সুরক্ষিত অ্যাপ্লিকেশনগুলিতে, ডেটাবেস ত্রুটিগুলি প্রচারের পক্ষে কেবল নিরাপদ নয়, OracleException - ORA-01234 - ...যা tableোকানো তৃতীয় সারণী হতে পারে। ক্লায়েন্টকে যে কোনও চেক / প্রত্যাশিত ব্যতিক্রম যা এটি পরিচালনা করতে পারে তা মোকাবেলা করার অনুমতি দেওয়া উচিত এবং সমস্ত কিছুকে সম্ভাব্য বাগ রিপোর্ট হিসাবে বিবেচনা করা উচিত। আপনার পরিষেবা চুক্তিটি একটি পারমাণবিক, ধারাবাহিক, লেনদেনের বিমূর্ততা হওয়া উচিত। যদি এটি ব্যতিক্রম সম্পর্কে কিছু না করতে পারে তবে কেবলমাত্র কার্যকর জিনিসটি আপনাকে একটি বাগ রিপোর্ট দেবে। আপনার ইতিমধ্যে ব্যতিক্রমটি লগ করার ক্ষমতা রয়েছে, সুতরাং আপনার শেষ ব্যবহারকারীকে বিশদ নিয়ে কেন বোঝা করবেন? আপনার অ্যাপ্লিকেশনটি পর্যবেক্ষণ করতে পারে যাতে ব্যবহারকারীরা তাদের রিপোর্ট করার আগে আপনি চেক করা ব্যতিক্রমগুলি সম্পর্কে ইতিমধ্যে জানতে পারেন।

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

Answer 2

না, আপনার কোনও ওয়েব অ্যাপ্লিকেশনটিতে ডিএও ব্যতিক্রমগুলি মোড়ানো উচিত নয়

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

... এটি শেষ ব্যবহারকারীকে একটি ত্রুটি বার্তা দেখিয়ে একটি জেএসপি দ্বারা ধরা পড়বে।

পুরো কোড বেসটি ক্র্যাপিংয়ের পরিবর্তে এই সমস্যাটি এক জায়গায় স্থির করুন।

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

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

Comments

আপনার উত্তরের জন্য ধন্যবাদ. এবং হ্যাঁ, জেএসপি একটি কাস্টম বার্তা দেখায়: "ওফ, কিছু ভুল হয়েছে"। এটি ব্যতিক্রম সম্পর্কে কোনও তথ্য প্রদর্শন করে না

— অস্কার

Answer 3

ব্যতিক্রম মোড়ানো ব্যবহারের মূল কারণটি হ'ল ব্যবসায়ের স্তরের কোডটিকে সিস্টেমে প্রতিটি সম্ভাব্য ব্যতিক্রম সম্পর্কে জানতে বাধা দেওয়া । এই জন্য দুটি প্রধান কারণ আছে:

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

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

সুতরাং, সংক্ষেপে, উত্তর হ্যাঁ!

Comments

জেপিএ বাস্তবায়ন (যেমন হাইবারনেট) চেক করা ব্যতিক্রমগুলি ফেলে দেয়। তাদের ঘোষিত বা ধরা হবে না।

— কেভিন